Користувач:Ігор Гулей/Чернетка

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Див. також: Дизайн, орієнтований на людину[en]

Дизайн, орієнтований на користувача (UCD) або розробку, керовану користувачем (UDD), - це структура процесів (не обмежується інтерфейсами або технологіями), в яких наводяться цілі використання, характеристики користувача, середовище[en], завдання та робочий процес продукту, sпослуги або процесу, яким приділяється багато уваги на кожному етапі процесу проектування. Дизайн, орієнтований на користувача, може бути охарактеризований як багатоетапний процес вирішення проблем, який вимагає не тільки від розробників аналізувати і уявляти, як користувачі можуть споживати продукт, але й перевіряти свої припущення щодо поведінки користувачів у тестах у реальному часі. Ці тести проводяться з / без фактичних користувачів під час кожної стадії процесу, починаючи від вимог[en], , попередніх виробничих моделей і постпродукції, завершуючи коло доказів і забезпечуючи, щоб "розвиток йшов разом з користувачем у центрі уваги". [1][2] Таке тестування[3] необхідно, оскільки для розробників продукту часто дуже важко зрозуміти, якого досвіду перший користувач набув та те, як може виглядати крива навчання[en] кожного користувача. Дизайн, орієнтований на користувача, поширений в індустрії дизайну, і коли він використовується, це призводить до збільшення корисності та зручності використання продукту.[4]

Головна відмінність від інших тлумачень дизайну продукту полягає в тому, що дизайн, орієнтований на користувача, намагається оптимізувати продукт навколо того, як користувачі можуть, хочуть або потребують використання продукту, а не змушують користувачів змінювати свою поведінку для розміщення продукту. Користувачі таким чином стоять в центрі двох концентричних кіл. Внутрішнє коло включає контекст продукту, цілі його розробки та середовище, в якому він буде працювати. Зовнішнє коло передбачає більш точне зображення деталей завдання, організації завдань і потоку завдань.[2]

Потреби та емоції[ред. | ред. код]

Термін дизайну, орієнтованого на користувача, був введений в дослідницьку лабораторію Дональда А. Нормана в Каліфорнійському університеті у Сан-Дієго. Концепція стала широко популярною після видання книги "Проектування систем, орієнтованих на користувачів: нові перспективи взаємодії людини з комп'ютером" у 1986 році.[5] TЦя концепція отримала подальшу увагу і прийняття у своїй головній книзі "Дизайн повсякденних речей[en]" (спочатку під назвою "Психологія повсякденних речей"). У книзі Норман описує психологію за те, що він вважає «хорошим» і «поганим» дизайном за допомогою прикладів. Він піднімає важливість дизайну в нашому повсякденному житті, і наслідки помилок, викликаних поганими проектами. Книги також містять принципи побудови добре продуманих виробів. Його рекомендації ґрунтуються на потребах користувача, залишивши осторонь те, що він вважає вторинними питаннями, як естетика. Головними з них є:

  1. Спрощення структури завдань таким чином, що можливі інтуїтивні дії в будь-який момент.
  2. Зробити речі видимими, включаючи концептуальну модель системи, дії, результати дій та зворотний зв'язок.
  3. Отримання відображень між запланованими результатами та необхідними діями.
  4. Охоплення та використання обмежень систем


Надмірно відновний підхід Нормана в попередніх текстах був переадресований ним пізніше в його власній публікації "Емоційний дизайн[en]"..[6]:p.5 onwards.

Моделі та підходи[ред. | ред. код]

Наприклад, процес проектування, орієнтований на користувача, може допомогти розробникам програмного забезпечення досягти мети продукту, розробленого для своїх користувачів. Вимоги користувача розглядаються з самого початку і включаються до всього циклу виробництва продукції. Ці вимоги відзначаються і уточнюються методами розслідування, включаючи:етнографічне дослідження, контекстне дослідження[en], тестування прототипу, юзабіліті-тестування та інші методи. Generative methods may also be used including: card sorting, affinity diagramming and participatory design sessions. In addition, user requirements can be inferred by careful analysis of usable products similar to the product being designed.

  • Кооперативний дизайн[en]: : залучення дизайнерів та користувачів на рівних умовах. Це скандинавська традиція розробки продукції ІТ-сфери, і вона розвивається з 1970 року.[7]
  • Дизайн участі[en] (PD)), північноамериканський термін для тієї ж концепції, натхненний кооперативним дизайном, орієнтований на участь користувачів. З 1990 року відбувається достороння конференція з проектування.[8]
  • Контекстний дизайн[en], "дизайн, орієнтований на клієнта" в реальному контексті, включаючи деякі ідеї з дизайну "Participatory" [9]

Ось принципи, які забезпечать, щоб дизайн націлений на користувача:[10]

  1. Дизайн базується на чіткому розумінні користувачів, завдань і середовищ.
  2. Користувачі задіяні в процесі проектування та розробки.
  3. Конструкція керується та вдосконалюється оцінкою користувача.
  4. Процес ітеративний.
  5. Конструкція відповідає досвіду користувача.
  6. Команда дизайнерів включає мультидисциплінарні навички та перспективи.

Процес проектування, орієнтований на користувача[ред. | ред. код]

Метою дизайну, орієнтованого на користувача, є створення продуктів, які мають дуже високу зручність у використанні. Це включає в себе, наскільки зручно продукт в плані його використання, керованості, ефективності і наскільки добре продукт відповідає вимогам користувача. Нижче наведено загальні фази процесу проектування, орієнтованого на користувача: [11][12]

  1. Визначення контексту використання: Визначте, хто основний користувач продукту, чому вони будуть використовувати продукт, які їх вимоги і в якому середовищі вони будуть використовувати його.
  2. Зазначення вимог: Після того, як контекст буде вказано, час для визначати вимог до продукту. Це важливий процес, який може ще більше полегшити дизайнерам створення розкадровки і встановити важливі цілі, щоб зробити продукт успішним.процес проектування та розробки продукту.
  3. 4. Оцінка продукту: розробники продукту використовують тестування на зручність для отримання відгуку користувачів про продукт. Оцінка продукції є важливим кроком у розробці продукту, яка дає критичний відгук про продукт.[13]

На наступних етапах описану вище процедуру повторюють для подальшого закінчення продукту. Ці етапи є загальними підходами та факторами, такими як цілі проектування, команда та їх терміни, а також середовище, в якому розробляється продукт, визначають відповідні фази для проекту та їх порядок. Ви можете дотримуватися водоспадної моделі, гнучкої моделі або будь-якої іншої практики розробки програмного забеспечення.

Призначення[ред. | ред. код]

UCD ставить питання про користувачів[en] їх завдання та цілі, а потім використовує висновки для прийняття рішень щодо розробки та проектування. UCD веб-сайту, наприклад, прагне відповісти на наступні питання:

  • Хто є користувачами документа?
  • Які завдання та цілі користувачів?
  • Який досвід користувачів у роботі з цими та подібним документами?
  • Які функції потрібні користувачам документом?
  • Яка інформація потрібна користувачам і в якій формі вона потрібна?
  • Як користувачі вважають, документ повинен працювати?
  • Які є екстремальні середовища?
  • Чи потребує користувач багатозадачності?
  • Чи використовує інтерфейс різні режими введення, такі як дотик, розмова, жести або орієнтація?

Елементи[ред. | ред. код]

Як приклади точок зору UCD, суттєвими елементами UCD веб-сайту є міркування про видимість, доступність, розбірливість та мову.

Видимість[ред. | ред. код]

Видимість допомагає користувачеві побудувати розумову модель документа. Моделі допомагають користувачеві прогнозувати вплив (-и) їх дій під час використання документа. Важливі елементи (наприклад, ті, що допомагають навігації) мають бути категоричними. Користувачі повинні мати змогу з першого погляду сказати, що вони можуть і не можуть робити з документом.

Доступність[ред. | ред. код]

Користувачі повинні мати можливість швидко та легко знаходити інформацію в усьому документі, незалежно від його довжини. Користувачам слід запропонувати різні способи пошуку інформації (наприклад, навігаційні елементи, функції пошуку, Зміст[en], чітко позначені розділи, номери сторінок, кодування кольорів[en], тощо). Навігаційні елементи повинні відповідати жанру документа. ‘Фрагментація[en]' - корисна стратегія, яка включає розбиття інформації на дрібні фрагменти, які можуть бути організовані в певний тип значущого порядку або ієрархії. Можливість пропускати дозволяє користувачам знаходити свою частину інформації шляхом сканування, а не читання. Часто використовуються напівжирні[en] та курсивні слова.

Чіткість[ред. | ред. код]

Текст повинен бути легким для читання: через аналіз риторичної ситуації, дизайнер повинен мати можливість визначити корисний стиль шрифту. Декоративні шрифти і текст у всіх великих літерах[en]важко читати, але курсив і напівжирний шрифт можуть бути корисними при правильному використанні. Великий або малий текст також важко читати. (Рекомендується розмір екрану 10-12 пікселів без засічок та 12-16 пікселів). Високий контраст між текстом і фоном збільшує чіткість. Темний текст на світлому фоні є найбільш розбірливим.

Language[ред. | ред. код]

Залежно від риторичної ситуації необхідні певні типи мов. Короткі речення є корисними, так само як і добре написані тексти, що використовуються в поясненнях і подібних ситуаціях у великому тексті. Якщо ситуація не вимагає цього, жаргон чи технічні терміни не повинні використовуватися. Багато письменників вирішать використовувати активний стан[en], дієслова (замість іменних рядків[en] або номіналів[en]), і просту структуру речення.

Риторична ситуація[ред. | ред. код]

Дизайн, орієнтований на користувача, зосереджений навколо риторичної ситуації[en]. Риторична ситуація формує дизайн інформаційного середовища. У риторичній ситуації слід розглянути три елементи: аудиторія, мета і контекст.

Аудиторія[ред. | ред. код]

Аудиторія - це люди, які будуть використовувати цей документ. Дизайнер повинен враховувати їхній вік, географічне положення, етнічну приналежність, стать, освіту тощо.

Призначення[ред. | ред. код]

Мета полягає в тому, на що документ орієнтується або яку проблему намагається вирішити.

Контекст[ред. | ред. код]

Контекст - обставини, що оточують ситуацію. Контекст часто відповідає на питання: Яка ситуація викликала необхідність цього документа? Контекст також включає будь-які соціальні або культурні питання, які можуть оточувати ситуацію.

Інструменти аналізу[ред. | ред. код]

Існує цілий ряд інструментів, які використовуються при аналізі орієнтованого на користувача дизайну, головним чином: персони, сценарії та важливі випадки використання.

Персона[ред. | ред. код]

Під час процесу UCD може бути створена персона[en] що представляє користувачаПерсонаж - це архетип користувача, який використовується для допомоги у прийнятті рішень щодо функцій продукту, навігації, взаємодії та навіть візуального дизайну. У більшості випадків персони синтезуються з серії етнографічних інтерв'ю з реальними людьми, а потім зафіксовані в описах 1-2 сторінок, які включають моделі поведінки, цілі, навички, погляди та навколишнє середовище. життя. [14]

Для кожного продукту, або іноді для кожного набору інструментів у межах продукту, є невеликий набір персон, один з яких є основним фокусом для дизайну. Є також те, що називається вторинною персоною, де характер не є головною метою дизайну, але їхні потреби повинні бути задоволені і, якщо це можливо, вирішені проблеми. Вони існують, щоб допомогти пояснити подальші можливі проблеми та труднощі, які можуть виникнути, навіть якщо первинна особа задоволена своїм рішенням. Існує також анти-персона – особа, на яку дизайн спеціально не орієнтований. Персони є корисними в тому сенсі, що вони створюють загальне спільне розуміння групи користувачів, для якої побудований процес проектування. Крім того, вони допомагають розставити пріоритети при розробці проектів, надаючи контекст того, що потрібно користувачеві, і які функції просто приємно додати й мати. Вони також можуть забезпечити людське бачення і пріоритети для різноманітної і розсіяної групи користувачів, а також можуть створити певну емпатію і додати емоції при зверненні до користувачів. Однак, оскільки персони є узагальненим сприйняттям первинної групи зацікавлених сторін з зібраних даних, характеристики можуть бути занадто широкими і типовими, або занадто великою кількістю "середнього Джо". Іноді персони також можуть мати стереотипні властивості, які можуть завдати шкоди процесу проектування. В цілому, персони можуть бути корисним інструментом, який можуть використовувати дизайнери для прийняття обґрунтованих дизайнерських рішень, на відміну від звернення до набору даних або широкого кола осіб.

Сценарій[ред. | ред. код]

A сценарій створений в процесі UCD, - це вигадана історія про "повсякденне життя" або послідовність подій з основною групою зацікавлених сторін як головного героя. Як правило, персонаж, створений раніше, використовується як головний персонаж цієї історії. Історія повинна бути специфічною для подій, що відбуваються, які стосуються проблем первинної групи зацікавлених сторін, і, як правило, основних дослідницьких питань, на які спирається процес проектування. Це може виявитися простою історією про повсякденне життя людини, але дрібні деталі з подій повинні містити подробиці про користувачів і можуть включати в себе емоційні або фізичні характеристики. Може бути "найкращий сценарій", де все найкраще підходить для головного героя, "найгірший сценарій", де головний герой переживає все, що відбувається навколо нього, і "середній сценарій". , що є типовим життям особистості, де нічого особливого або дійсно пригнічуючого не відбувається, і день просто рухається далі. Сценарії створюють соціальний контекст, в якому існують особи, а також створюють реальний фізичний світ, замість того, щоб уявляти персонажа з внутрішніми характеристиками з зібраних даних і нічого іншого; існує більше дій, пов'язаних з існуванням особи. Сценарій також легше зрозумілий людям, оскільки він має форму історії, і за ним легше спостерігати. Однак, як і особи, ці сценарії є припущеннями, зробленими дослідником і дизайнером, а також створюються з набору організованих даних. Деякі навіть кажуть, що такі сценарії є нереалістичними для реальних подій. Крім того, важко пояснити і повідомити про завдання, що виникають на найнижчому рівні, як, наприклад, процес мислення персони перед тим, як діяти.

Сценарій використання[ред. | ред. код]

Коротко кажучи, сценарій використання описує взаємодію між людиною та рештою світу. Кожен варіант використання описує подію, яка може відбуватися протягом короткого періоду часу в реальному житті, але може складатися з складних деталей і взаємодій між актором і світом. Вона представлена у вигляді серії простих кроків для персони для досягнення своєї мети у формі причинно-наслідкової схеми. Випадки використання зазвичай записуються у вигляді діаграми з двома стовпцями: перший стовпчик, актор, другий стовпчик позначений світ, і дії, що виконуються кожною стороною, написані в порядку у відповідних колонках. Нижче наводиться приклад використання для виконання пісні на гітарі перед аудиторією.

Актор Світ
Вибір музики для виконання
Вибір гітари
Демонстрація нотних листів
Програвання кожної ноти з листа на гітарі
Передача нот аудиторії за допомогою звуків
Забезпечення зворотнього зв’язку до виконавця
Оцінити виставу та пристосуватися відповідно до віддачі аудиторії
Продовжити пісню з відповідними правками
Оплески публіки

Взаємодія між актором і світом - це дія, яку можна побачити в повсякденному житті, і ми приймаємо їх як належне і не думаємо надто багато про дрібниці, які повинні відбутися для того, щоб діяти, як виконувати музику існувати. Це схоже на той факт, що, говорячи на рідній мові, ми не думаємо занадто багато про граматику і про фрази; вони просто виходять, оскільки ми так звикли говорити. Дії між актором і світом, зокрема, первинним учасником (користувачем) і світом у цьому випадку, слід продумувати детально, і, отже, створюються випадки використання, щоб зрозуміти, як відбуваються ці крихітні взаємодії. Важливим випадком використання є спеціальний вигляд використання, який також називають "абстрактним випадком використання". Основні випадки використання описують суть проблеми, а також розглядають природу самої проблеми. При написанні випадків використання не слід робити жодних припущень щодо незв'язаних деталей. Крім того, цілі суб'єкта повинні бути відокремлені від процесу та реалізації для досягнення цієї конкретної мети. Нижче наводиться приклад істотного випадку використання з тією ж метою, як і перший приклад.


Актор Світ
Вибір нотних листів для виконання
Забезпечення доступу до ресурсів
Послідовне програвання шматочків
Передача та інтерпретація вистави
Забезпечення зворотнього зв’язку
Продовження вистави

Варіанти використання корисні, оскільки вони допомагають визначити корисні рівні дизайнерської роботи. Вони дозволяють розробникам бачити фактичні процеси низького рівня, які беруть участь у певній проблемі, що робить проблему легшою, оскільки виявляються деякі незначні кроки та деталі, які робить користувач. Робота дизайнерів повинна враховувати ці невеликі проблеми, щоб отримати остаточне рішення, яке працює. Інакше кажучи, випадки використання розбивають складне завдання на менші біти, де ці біти є корисними одиницями. Кожен біт завершує невелике завдання, яке потім входить до останнього великого завдання. Подібно до того, як писати код на комп'ютері, легше писати основні дрібні частини і робити їх спочатку робочими, а потім ставити їх разом, щоб закінчити більш складний код, а не вирішувати весь код з самого початку. Перше рішення менш ризиковане, тому що якщо щось піде не так з кодом, то легше шукати проблему в менших бітах, оскільки сегмент з проблемою буде той, який не працює, а в останньому рішенні програмісту, можливо, доведеться шукати весь код для пошуку однієї помилки, що виявляється трудомістким. Подібні міркування йдуть для написання випадків використання в UCD. Нарешті, випадки використання передають корисні і важливі завдання, де дизайнер може побачити, які з них мають вищу важливість, ніж інші. Деякі недоліки написання випадків використання включають в себе той факт, що кожна дія, актор чи світ, складається з маленьких деталей і просто невеликих дій. Це може призвести до подальшої уяви та різної інтерпретації дій від різних дизайнерів. Крім того, під час процесу дуже легко спростити завдання, оскільки невелике завдання з більшого завдання може складатися з ще менших завдань. Вибір гітари може включати в себе думку про те, яку гітару підібрати, яку вибрати, і подумати, де знаходиться гітара. Потім ці завдання можна розділити на дрібніші завдання, такі як перше уявлення про те, який колір гітари підходить до місця для виконання твору, та інші пов'язані з цим деталі. Завдання можуть бути розділені далі на ще більш дрібні завдання, і від дизайнера залежить, щоб визначити, що є відповідним місцем для припинення розщеплення завдань. Завдання можуть бути не тільки спрощені, вони також можуть бути опущені в цілому, таким чином дизайнер повинен знати всі деталі і всі ключові кроки, які беруть участь у події або дії при написанні випадків використання.


Посилання[ред. | ред. код]

  1. ↑ Cover – Just Ask: Integrating Accessibility Throughout Design. uiaccess.com.
  2. ↑ а б Notes on User Centered Design Process (UCD). www.w3.org.
  3. ↑ Rubin, Jeffrey; Chisnell, Dana. Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests (англ.). John Wiley & Sons. ISBN 978-1-118-08040-5.
  4. ↑ Vredenburg, Karel; Mao, Ji-Ye; Smith, Paul; Carey, Tom (2002). A Survey of User-Centered Design Practice (PDF).
  5. ↑ Norman, D. A. (1986). User-Centered System Design: New Perspectives on Human-Computer Interaction.
  6. ↑ Don Norman (2003) Emotional Design, Prolog-- Three Teapots (PDF). jnd.org.
  7. ↑ Greenbaum&Kyng (eds): Design At Work – Cooperative design of Computer Systems, Lawrence Erlbaum 1991
  8. ↑ Schuler&Namioka: Participatory Design, Lawrence Erlbaum 1993 and chapter 11 in Helander's Handbook of HCI, Elsevier 1997
  9. ↑ Beyer&Holtzblatt, Contextual Design, Kaufmann 1998
  10. ↑ User-Centered Design Basics. www.usability.gov.
  11. ↑ Notes on User Centered Design Process (UCD). www.w3.org. Процитовано 30 March 2017.
  12. ↑ User-Centered Design Basics. www.usability.gov. Процитовано 30 March 2017.
  13. ↑ Moen, Ron. A Review of the IDEO Process. www.rwjf.org. Процитовано 30 March 2017.
  14. ↑ Perfecting your ourufrankline | Cooper Journal. www.cooper.com. Процитовано 6 січня 2016.

Література[ред. | ред. код]

Відео[ред. | ред. код]

Шаблон:Design Шаблон:Engineering approaches


Отримано з https://uk.wikipedia.org/w/index.php?title=Користувач:Ігор_Гулей/Чернетка&oldid=38715829