Розробка орієнтована на користувача

Див. також: Дизайн, орієнтований на людину[en]

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

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

Потреби та емоції

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

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

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

Моделі та підходи

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

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

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

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

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

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

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

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

Призначення

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

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

Елементи

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

Видимість

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

Доступність

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

Чіткість

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

Language

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

Риторична ситуація

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

Аудиторія

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

Призначення

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

Контекст

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

Інструменти аналізу

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

Персона

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

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

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

Сценарій

A сценарій створений в процесі UCD, — це вигадана історія про «повсякденне життя» або послідовність подій з основною групою зацікавлених сторін як головного героя. Як правило, персонаж, створений раніше, використовується як головний персонаж цієї історії. Історія повинна бути специфічною для подій, що відбуваються, які стосуються проблем первинної групи зацікавлених сторін, і, як правило, основних дослідницьких питань, на які спирається процес проектування. Це може виявитися простою історією про повсякденне життя людини, але дрібні деталі з подій повинні містити подробиці про користувачів і можуть містити в собі емоційні або фізичні характеристики. Може бути «найкращий сценарій», де все найкраще підходить для головного героя, «найгірший сценарій», де головний герой переживає все, що відбувається навколо нього, і «середній сценарій», що є типовим життям особистості, де нічого особливого або дійсно пригнічуючого не відбувається, і день просто рухається далі.

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

Сценарій використання

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

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

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


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

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

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

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

Примітки

  1. ↑ Cover – Just Ask: Integrating Accessibility Throughout Design. uiaccess.com. Архів оригіналу за 31 травня 2019. Процитовано 28 травня 2019.
  2. ↑ а б Notes on User Centered Design Process (UCD). www.w3.org. Архів оригіналу за 11 червня 2019. Процитовано 28 травня 2019.
  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. Архів оригіналу за 2 квітня 2017. Процитовано 28 травня 2019.
  4. ↑ Vredenburg, Karel; Mao, Ji-Ye; Smith, Paul; Carey, Tom (2002). A Survey of User-Centered Design Practice (PDF). Архів оригіналу (PDF) за 11 липня 2019.
  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. Архів оригіналу (PDF) за 19 лютого 2018. Процитовано 28 травня 2019.
  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. Архів оригіналу за 28 травня 2019. Процитовано 28 травня 2019.
  11. ↑ Notes on User Centered Design Process (UCD). www.w3.org. Архів оригіналу за 31 березня 2017. Процитовано 30 березня 2017.
  12. ↑ User-Centered Design Basics. www.usability.gov. Архів оригіналу за 31 березня 2017. Процитовано 30 березня 2017.
  13. ↑ Moen, Ron. A Review of the IDEO Process. www.rwjf.org. Архів оригіналу за 7 лютого 2016. Процитовано 30 березня 2017.
  14. ↑ Perfecting your ourufrankline | Cooper Journal. www.cooper.com. Архів оригіналу за 28 травня 2019. Процитовано 6 січня 2016.

Література

Відео