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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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