Как придумать интерфейс программы

Для создания у пользователя такого ощущения «внутренней свободы» интер­фейс должен обладать целым рядом свойств (слайд 14.4):

• Естественность интерфейса.
• Согласованность интерфейса.
• Дружественность интерфейса (Принцип «прощения пользователя»)
• Принцип «обратной связи».
• Простота интерфейса.
• Гибкость интерфейса.
• Эстетическая привлекательность.

1. Время, необходимое определенному пользователю для достижения заданногоуровня знаний и навыков по работе с приложением.
2. Сохранение полученных рабочих навыков по истечении некоторого времени(например, после недельного перерыва пользователь должен выполнить определенную последовательность операций за заданное время).
3. Скорость решения задачи с помощью данного приложения; при этом должнооцениваться не быстродействие системы и не скорость ввода данных с клавиатуры, авремя, необходимое для достижения цели решаемой задачи. Исходя из этого, критерий оценки по данному показателю может быть сформулирован, например, так: пользо­ватель должен обработать за час не менее 20 документов с ошибкой не более 1 %.
4. Субъективная удовлетворенность пользователя при работе с системой (которая количественно может быть выражена в процентах или оценкой по n-бальной шкале).

Источник: studfile.net

Этапы дизайна мобильного приложения

Как сделать удобный интерфейс для повседневного инструмента

Принципы проектирования интерфейсов от команды дизайнеров IntelliJ IDEA.

Среда разработки — такой же важный инструмент для разработчиков, как графический редактор для дизайнеров. Это именно то приложение, где можно написать код и собрать из него любое другое приложение или сайт.

IntelliJ IDEA — популярная среда разработки (IDE) для языка программирования Java. Возможно, вы и сами пользуетесь ей или одной из десяти IDE компании JetBrains: WebStorm, PyCharm, GoLand, Rider и так далее. Все эти продукты построены на платформе IntelliJ и имеют общий пользовательский интерфейс.

UX-, UI-дизайнеры в команде разработки IntelliJ IDEA помогают делать интерфейс удобнее для наших пользователей. Чтобы определить, что такое «удобнее» для самих себя, коллег-разработчиков и пользователей, мы используем принципы проектирования.

Главный экран IntelliJ IDEA: слева все файлы проекта, справа код

Откуда берутся принципы

Люди довольны продуктом, если чувствуют, что движутся к своей цели, и не испытывают эстетических противоречий. Попросту, должно быть удобно и красиво.

«Красиво» — это соответствие современным визуальным нормам. Наши IDE десктопные, решения в этой области ограничены интерфейсами операционных систем. Поэтому мы чаще думаем про «удобно».

Думаю, что «удобно» можно сформулировать так: большинство пользователей решает задачу максимально быстро.

ТОП 5 Лучших графических (GUI) фреймворков Python / Графический интерфейс python

Эта формулировка слишком абстрактная, и её сложно применять на практике. Проще использовать конкретные принципы, которые в сумме обеспечивают то же самое. Эти принципы:

• Скорость доступа к элементам интерфейса.
• Экономия внимания.
• Информативность.
• Находимость.
• Привычки.
• Сложность разработки.

В списке нет таких понятий как «соответствие целям и сценариям пользователя», «теория близости» или «скорость работы приложения» — всё это должно работать по умолчанию.

Принципы оставляют пространство для решений. Разберу способы принятия таких решений на примерах пользовательских интерфейсов в IntelliJ IDEA.

Принципы

Скорость доступа к элементам интерфейса

Скорость доступа — насколько быстро можно подвести курсор к элементу, насколько быстро прицелиться. Здесь действует Закон Фиттса: время прицеливания прямо пропорционально расстоянию, обратно пропорционально размеру объекта прицеливания. То есть в большую кнопку рядом с курсором прицелиться быстрее, чем в маленькую кнопку далеко.

Такая маленькая кнопка как раз была на тулбаре в главном окне IntelliJ IDEA — кнопка с треугольником на скриншоте:

Добавили кнопке лейбл «Add Configuration». Кнопка стала большая, и целиться стало удобнее:

Часто для достижения цели нужно прицелиться к нескольким объектам подряд. Чем больше объектов, тем медленнее доступ. Та же кнопка с треугольником сначала открывала меню, в котором нужно было прицелиться в единственный пункт:

В варианте с кнопкой прицелиться нужно только один раз к самой кнопке.

Экономия внимания

Внимание человека — ресурс, не нужно расходовать его зазря. В интерфейсах внимание часто расходуется на переключение контекста.

Например, раньше сообщение о валидации полей отображалось внизу диалога. Часто поле с ошибкой оказывалось далеко от сообщения, пользователю приходилось бегать глазами от одного места к другому:

До: поле с ошибкой наверху диалога, сообщение об ошибке внизу

Исправили, чтобы ошибка показывалась у поля, где она произошла. Теперь внимание не расходуется на переключение между разными областями диалога:

После: поле с проблемой и сообщение об ошибке в одном месте

Переключение контекста ещё часто происходит в модальных диалогах. Модальный диалог заставляет тратить внимание, чтобы сориентироваться в новом интерфейсе. В IntelliJ IDEA обычным подходом было открыть модальный диалог, если нужно увеличить область ввода:

До: кнопка открывает модальный диалог

Чтобы внимание не тратилось, решили расширять само поле:

После: кнопка разворачивает немодальное поле

Ещё внимание можно потратить на слишком заметный элемент интерфейса, когда заметным он быть не должен. Хотели объяснить в нотификации, зачем она появляется, и добавили серый текст:

До: длинный отвлекающий серый текст

Но нотификация появляется часто, зачем каждый раз отвлекать людей подсказкой, которую они уже, возможно, изучили. Можно спрятать ее под менее заметный вопросительный знак и сэкономить внимание:

После: не отвлекающая иконка со знаком вопроса

Информативность

Информативность — это доля полезной информации в общем объеме сообщения, то есть соотношение сигнал/шум. Улучшать информативность можно двумя способами: добавить сигнал или уменьшить шум.

Пример с добавлением сигнала. В IntelliJ IDEA есть возможность перемещаться назад / вперед по местам кода, где находился курсор (действия Navigate Back / Forward). Не всегда легко вспомнить, в каком месте кода каретка была некоторое время назад, и непонятно, нужно ли туда возвращаться. Добавили информацию для решения этой проблемы — показали кусочки кода, где был курсор, в отдельном попапе:

Попап наглядно показывает, в каком месте кода недавно находился курсор

Другой пример, когда убираем шум. Несколько версий назад у нас было много тулбаров с 10–20 иконками. В таком количестве иконок сложно найти нужную. Мы собрали статистику кликов на тулбарах. Те действия, которые использовали меньше 0,1% пользователей (темно-красный), мы убрали с тулбаров, другие действия сгруппировали или переместили, наиболее используемые вынесли в начало тулбара. Теперь шума меньше, найти нужную иконку проще:

Когда иконок меньше, найти нужную проще

Находимость

Фича может быть полезной, но если пользователи про неё не знают — всё равно, что нет фичи.

В IntelliJ IDEA можно искать файлы, классы и другие сущности проекта или действия самой IDE. Раньше было пять похожих интерфейсов поиска: свой для каждой категории и один поиск для всех. Нужно было знать, как вызывать каждый в отдельности.

Пять попапов для поиска разных сущностей, нужно знать про каждый

Чтобы не нужно было находить каждый из попапов, совместили их в один. Теперь достаточно одного шортката (Shift + Shift), чтобы узнать, какие объекты можно искать — все они перечислены в заголовке попапа, и между ними можно легко переключаться клавишей Tab:

Один попап для поиска всех сущностей. Проще найти, чем пять отдельных

Или ещё случай. Одно из самых полезных действий в IntelliJ IDEA — Show Context Actions с шорткатом Alt + Enter. Оно подсказывает, как сделать код правильнее, позволяет запустить его, снавигироваться в связанные сущности и многое другое. Например, можно поставить курсор на код с проблемой, нажать Alt + Enter и увидеть список действий, которые исправят код автоматически:

Контекстные действия в IntelliJ IDEA подсказывают, как исправить код

Но узнать про Show Context Actions можно, но только если заметишь и нажмёшь иконку–лампочку (она открывает это же меню) или откроешь контекстное меню. Оба способа легко пропустить. Зато по наведению курсора мыши на код с проблемой появляется тултип с описанием ошибки, найти его намного проще:

До: тултип с проблемой в коде

Логично связать описание ошибки с действиями для ее исправления. Добавили действия в тултип, и количество использований Show Context Actions в IntelliJ IDEA выросло с 60% до 70%.

После: тултип с проблемой и с контекстными действиями — проблема и как исправить в одном месте

Привычки

Соблюдение привычек пользователей помогает всем предыдущим пунктам — привычные элементы быстрее и найти, и понять. Как мы сохраняем привычку:

1. Используем важные интерфейсные шаблоны из операционных систем. Например, в macOS кнопка «OK» справа, а в Windows — слева.

Кнопки OK и Cancel в разном порядке в macOS и Windows

1. Используем один шаблон взаимодействия для одинаковых задач. Например, раньше клавиатурные раскладки, цветовые схемы редактора кода и профили инспекций кода управлялись тремя разными интерфейсами, хотя для всех действия были почти одинаковые:

До: три разных интерфейса для одного способа взаимодействия

Заменили на одинаковый интерфейс, чтобы пользователям было проще разобраться с управлением новой сущностью, если уже сталкивались с похожей раньше. У всех действия теперь в меню под шестеренкой:

После: одинаковый интерфейс для одного способа взаимодействия»

1. Используем знакомые решения из окружающего мира, если ничего подходящего нет в нашем собственном интерфейсе или операционных системах. Недавно появилась возможность делать плагины к нашим IDE платными. Теперь у платных плагинов есть своя лицензия, и если она не активирована, нужно как-то это показать. Как это сделать?

Можно нарисовать иконки продукта и плагинов неактивными, но тогда выглядит, будто пункт списка целиком недоступен:

Иконка выглядит недоступной (disabled)

Можно сделать иконки полупрозрачными, передать метафору «чего-то не хватает». Но такой прием не используется в IntelliJ IDEA, вид непривычный, и метафору могут не понять:

Метафору полупрозрачной иконки сложно понять

Поэтому решили использовать привычный символ знака «стоп» для значения «стой, что-то не так»:

Дополнительная иконка «стоп» быстрее передает смысл «что-то не так»

Сложность разработки

Дизайнер может придумать интерфейс, разрабатывать который придется год. Все это время проблема пользователей не будет решена. Поэтому лучше придумать что-то проще и принести пользу быстрее.

Пример. Тексты для пользовательского интерфейса удобно записывать в отдельных файлах, а не в файле с кодом. Например, это полезно для перевода на разные языки — всё, что нужно перевести, видно в одном месте:

Пример файла с текстами для пользовательского интерфейса. Тексты — зеленые, их идентификаторы — синие

В файле с кодом, показывающим текст, указываем обращение к идентификатору текста:

Тут идентификатор стал зеленым, это корректное поведение, но для примера неважное

Вместо идентификатора удобно показать превью текста — понятно, что именно будет выведено в интерфейс. Такое превью отображается в IntelliJ IDEA автоматически:

В файле с кодом вместо непонятного идентификатора показываем понятный текст

Иногда сам текст нужно отредактировать. Чтобы не переходить в файл, где хранится текст, дизайнеры предложили редактировать превью текста (раньше редактировать было нельзя):

Удаляем слово Toggle

Но оказалось, что разработать редактирование текста, который на самом деле хранится в другом файле — сложно и долго. Поэтому решили обойтись существующими компонентами: показать поверх кода поле ввода с текстом из другого файла, а в тултипе подсказать, как запустить редактирование.

Нажимаем ссылку Edit Property Value, запускается редактирование

Задача решена, пусть и менее элегантно, но гораздо быстрее.

Все принципы вместе

Чтобы понять, хороший ли интерфейс, нужно оценить, как на нем выполняются все принципы. Возьмем для примера ту же кнопку на тулбаре главного окна и оценим новый вариант по принципам:

• Скорость доступа: как уже говорилось, в большую кнопку прицелиться быстрее, чем в маленькую кнопку, а потом в меню под ней.
• Экономия внимания: кнопка стала заметнее, но это небольшая проблема, потому что кнопка важная — с нее можно начать работу, если требуется запустить код.
• Информативность: теперь на кнопке написано, что она делает — это полезная информация, стало понятно, зачем нужна кнопка.
• Находимость: теперь людям проще найти, как создать run/debug конфигурацию, чтобы запустить код — текст на кнопке явно на это указывает.
• Привычка и сложность разработки: кнопка — стандартный элемент, проблем нет.

Вариант с кнопкой — сравнительно простой. Обычно для такого интерфейса достаточно умозрительной оценки. Для вариантов посложнее не всегда получается оценить в уме.

Рассмотрим вариант посложнее: диалог создания класса, интерфейса или элемента другого типа данных (класс и интерфейс — понятия из программирования). В диалоге можно записать имя элемента и выбрать его тип в списке Kind:

Диалог создания класса и других абстрактных типов данных в коде

По умолчанию список типов скрыт, и может быть сложно понять, какие есть варианты. Если курсор находится в поле Name, то Kind можно переключать кнопками Вверх/Вниз на клавиатуре, на что намекает иконка ↑↓ справа от Name. Но этот способ подсказки непривычный, метафора иконки непонятная, и в результате найти эту функциональность сложно.

В одной из команд предложили вручную вводить тип элемента в поле Name, чтобы не нужно было переключаться в комбобокс Kind и выбирать из длинного списка. Дизайнеры предложили ещё два решения: использовать попап с подсказкой и показывать все типы в списке под полем Name. Все варианты вместе:

Чтобы не забыть ни один из принципов в процессе сравнения, запишем в табличку. Цветом отмечена оценка, насколько хорошо выполняется принцип. Цвет помогает взглядом оценить наиболее удачный вариант:

По табличке видно, что у варианта со всеми типами в списке под полем (4) больше всего зеленого, но он всё равно не идеальный. Это обычная ситуация, потому что примирить все принципы сложно. В таком случае можно выбрать самый выигрышный вариант и отдельно решить его проблемы.

Принципы помогают выбрать лучший вариант интерфейса на этапе проектирования и разработки. Но они не гарантируют, что решение будет идеальным — пользователей много, цели и способы решения задач у них могут быть разными, сложно учесть всё сразу.

Поэтому после разработки мы всегда следим, как наши коллеги и люди за пределами компании пользуются новым интерфейсом, проводим UX-исследования, и дорабатываем, если что-то осталось неудобным.

Опубликовано на сайте издания «vc.ru».

Источник: blog.jetbrains.com

Этапы разработки пользовательского интерфейса

За восемь лет существования «Лайв Тайпинг» выработала подход к дизайну интерфейсов и готова поделиться с вами его версией на текущий день. После прочтения вы сможете построить коммуникацию с дизайнерами любой студии разработки и будете знать, в каких примерно темпах протекает этот процесс и какой результат вы получите.

Пользовательский интерфейс, или UI (User Interface) — это внешний вид продукта, способ общения между пользователем и программой. А ещё интерфейс влияет на то, будет ли продукт приносить деньги и пользоваться уважением и любовью аудитории.

Доказывать важность дизайна как магнита для пользователей удобно на примере соцсетей с миллионами пользователей. Резонансным случаем в рунете стал редизайн «Кинопоиска». 96% негативных отзывов на него говорят сами за себя: владельцы сайта, компания «Яндекс», сделала это без оглядки на мнение пользователей.

Новый дизайн фокусировал внимание пользователей на возможности смотреть фильмы платно через партнёров «Яндекса», и это решало только задачи площадки и партнёров. Но пользователи больше всего ценили сайт за рейтинги, оценки, списки фильмов, топ-250, блоги и всё, что создаётся аудиторией.

В итоге новый сайт просуществовал четыре дня и под напором гнева «Яндекс» вернул старый дизайн. Новый же, по мнению сопричастных, нравился только менеджерам.

Редизайн «Живого журнала» в 2014 году тоже не впечатлял. Его хорошенько почистили от лишних элементов, но в целом он не вызвал восторгов: типографика, модульная сетка, адаптив — всё выглядело сырым и неудобным.

Вы хотите повторить судьбу «Живого журнала» и «Кинопоиска»? Не думаем, поэтому мы и написали эту статью. Вам как клиенту будет полезно знать, как именно создаётся дизайн сайтов и приложений, из каких этапов состоит работа и что вы должны получить. Чувство контроля над этими этапами приблизит ваш проект к успеху.

Итак, разберём особенности разработки пользовательского интерфейса пошагово.

Проектирование

На этом этапе вас ждёт много теории, гипотез и умозрительных заключений, которые предстоит подтвердить или опровергнуть. Эти заключения касаются функциональности продукта и проистекают из вопросов: «Зачем нужен этот продукт?», «Кому он нужен?», «Как с ним будут работать и решать задачи пользователи?» и «Как он будет зарабатывать для своих владельцев?».

Вложить время и деньги в проектирование — это вложить время и деньги в понимание того, что получится на выходе.

Ответить на большую часть этих вопросов поможет составление портрета целевой аудитории (ЦА) — тех самых людей, для которых делается продукт.

Главная задача дизайнеров при изучении аудитории — включить эмпатию на максимум и понять, как эта аудитория думает, дышит, видит, слышит и действует. Этому способствуют следующие методы:

• Коридорный метод. Обратная связь поступает от родных, друзей и коллег дизайнеров. Собрать её легко, но этого недостаточно.
• Разговор с вами. Справедливо предполагается, что вы как никто знаете, что нужно вашей аудитории.
• Полевые исследования. В рамках метода дизайнеры идут в народ: общаются с людьми напрямую, если делают продукт для местного рынка, или читают форумы, если для зарубежного;
• Проблемное интервью. Задавая пользователям вопросы про их жизнь и место проблемы в ней, дизайнеры узнают, как эта проблема решается сейчас и насколько полезным окажется их продукт. То, что он может оказаться бесполезным — тоже ценный результат: не придётся тратить деньги на приложение, которым никто не будет пользоваться.

Собранную информацию дизайнеры перерабатывают и получают, во-первых, ключевые персоны, а во-вторых, пользовательские маршруты.

Ключевые персоны — это характерные представители ЦА. Они могут быть разными по профессии, уровню жизни, мотивации пользоваться приложением и прочим параметрам, но опыт, ожидания и страхи каждой персоны ложатся в основу внешнего вида продукта и его функциональности. Например, типичному пользователю приложения «Киноголик» для покупки абонементов в кино 23 года, он работает в ИТ-компании и любит смотреть фильмы на английском.

Такая персона становится центром user story, или пользовательской истории. Это краткий, в несколько строк, рассказ про персону и то, как она работает с функциональностью приложения и какой цели достигает. User story строится по шаблону:

Поместив нашего 23-летнего фаната оригинальных версий в этот шаблон, получим:

Компания Intercom славится не только комплексным решением по внедрению чатов в сайты и мобильные приложения, но и изобретением подхода Jobs To Be Done. В основе подхода лежит не личное качество ключевой персоны, а обстоятельства и мотивация, которые толкают персону пользоваться продуктом. «Размышления» персоны называются Job story, а шаблон выглядит так:

Ситуация с кинолюбом в рамках такого подхода выглядит иначе:

Подробнее про подход Jobs To Be Done написала в своём блоге платформа Tilda.

От User story и Job story мы переходим к User scenario. Это маршрут взаимодействия пользователя с продуктом и достижения цели.

В погоне за основной целью (покупка, добавление фотографии) пользователь может решать вспомогательные задачи (выбирает способ доставки заказа, редактирует фото) и достигать вторичных целей (удобное получение заказа, фото с контрастирующими деталями); эти дополнительные маршруты дизайнеру тоже необходимо учесть.

Прототипирование

Прототип — это набросок продукта, в котором заключены его внешний вид, логика работы и основная функциональность.

Работа над ним начинается с создания макета. Одним из вариантов макета является вайрфрейм (от английского wireframe — «каркасный»). Внешне он выглядит как куча прямоугольных блоков, опоясанных линиями и стрелочками. В этих блоках и стрелочках заложена структура продукта и порядок взаимодействия пользователя с ним.

Будет ли вайрфрейм грубым наброском, который вы сделали с коллегами ручкой на бумаге для принтера, или созданной в графическом редакторе организованной картой экранов — решать вам. Единственное: готовьтесь объяснить клиенту, что визуально вайрфрейм не имеет отношения к финальному продукту.

Пользуясь терминами электротехнического черчения, все кнопки, тексты, медиафайлы и прочие элементы заменены в вайрфрейме на условно-графические обозначения. Это ещё не интерфейс, но уже что-то близкое — как ёлка, которая станет новогодним деревом, когда её нарядят.

Детализированный прототип — следующий шаг вайрфрейма по лестнице эволюции пользовательского интерфейса. Как и вайрфрейм, это макет, но чуть более конкретный: если в вайрфрейме экран с чатом состоит из окружностей и прямоугольников, только намекающих на свои назначения, то в детализированном прототипе окружность — это ТОЧНО фото пользователя, а прямоугольник — ТОЧНО текст сообщения c прикреплёнными файлами, аудиозаписями и стикерами.

Для презентации прототипа мало показать экраны. Нужно показать, к чему и куда приводит взаимодействие будущего пользователя с элементами интерфейса. Связав элементы линиями с другими экранами, на которые попадёт пользователь, вы получите пользовательские сценарии использования приложения, или user flow.

User flow — карта навигации, по которой видно поведение пользователя мобильного приложения, как он достигает цели и как легко ему это удаётся. Внешне User flow выглядит как логически связанные друг с другом прямоугольники, акцент в которых сделан на действиях пользователя.

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

В качестве софта для этой задачи мы используем Overflow, чей слоган “User flows done right” даёт понять, что время за этой работой пройдёт продуктивно и с пользой. В Overflow легко импортируются экраны из Sketch или Figma, а сделать flow для 100 экранов можно за час — гораздо быстрее, чем рисовать стрелочки самому.

Нужен дополнительный уровень понимания, как продукт будет работать? С помощью таких сервисов, как Marvel, InVision, POP App и Origami Studio детализированный прототип можно превратить в интерактивный. Его польза в том, что он даёт прокликать (а в случае, если у нас мобильное приложение — прокликать прямо в телефоне) все элементы интерфейса и оценить логику работы продукта до того, как он попадёт в руки конечного пользователя.

Его создание — этап необязательный, так как с презентацией будущей работы справляются макеты и user flow. Но когда нужно показать возможности мобильного приложения и раскрыть перед клиентом предстоящий объём работ в деталях, используйте его.

После утверждения логики и функциональности продукта этап прототипирования можно считать завершённым.

Резюмируем: вы получаете детальный прототип, его кликабельную версию (опционально) и карту экранов. Они соответствуют выработанным и согласованным в рамках этого этапа гипотезам продукта.

Чаще всего также формируется пул пользовательских кейсов, описываются целевые сегменты и моделируется поведение пользователей в системе. Помимо этого, этап сопровождается техническим проектированием, синхронизированный с процессами выше.

Всё оформляется в документы-артефакты: техническое задание, функциональное задание, описание архитектуры и так далее. С помощью этого мы убеждаемся, что то, что мы спроектировали, не только имеет под собой аргументацию со стороны рынка и пользователей, но и технически поддаётся воплощению, и мы имеем представление о том, как именно это сделать и какие могут быть риски.

Разработчики получают от дизайнеров прототип и user flow, чтобы максимально точно оценить этап разработки и ориентироваться в логике продукта. Затем на будущий продукт начинают накатывать стиль.

Стилизация

У прототипа есть логика, но нет своего лица, которое продукт явит пользователям, и голоса, которым он будет с ними говорить. Под лицом и голосом имеется в виду фирменный стиль, который складывается из цветовой палитры, шрифта, иконок и иллюстраций.

В этом месте начинается мини-этап дизайн-концепции, о котором мы говорили выше. Суть его в том, чтобы взять несколько голых экранов прототипа и примерить на них фирменный стиль. Если клиенту понравится то, что он увидит, то команда дизайнеров работает с остальной частью прототипа в том же направлении.

Уважающий дисциплину дизайнер уже давно оценил прелести работы в Sketch — ведь здесь так удобно вести макеты для iOS и Android в отдельных файлах, превращать в легко читаемые символы повторяющиеся элементы интерфейса, заранее присваивать таким элементам стили и отступы от краёв экрана и делать много чего ещё. Всё это складывается в дизайн-систему.

Как и в случае прототипа, готовый дизайн согласовывается с клиентом. Когда всех всё устраивает, дизайн готовится для передачи разработчикам. Сколько времени и сил можно сэкономить, сделав это грамотно посредством Zeplin (спойлер: очень много), можно узнать из нашей статьи.

Вывод

Пользоваться продуктом в первую очередь будут простые люди, а не его создатели. Будучи людьми простыми, во время работы с продуктом они прогонят его через фильтр из трёх вопросов: «Что делать?», «Куда идти?» и «Куда нажимать?». Если вы серьёзно отнесётесь к этапам работы над интерфейсом, ваши пользователи получат ясный ответ на эти вопросы и останутся довольны продуктом.

«Что делать?»

Это вопрос о том, насколько пользователю понятна основная функция продукта. Обозначить её нужно на этапе проектирования — тогда же, когда определяется целевая аудитория.

«Куда идти?»

Путь к цели лежит через взаимодействие пользователя с интерфейсом. Кнопка за кнопкой, поле ввода за полем ввода, экран за экраном — и так до заветной покупки или публикации поста. Грамотно составленный user scenario, отрепетированный на прототипе, уберёт с этого пути все ухабы.

«Куда нажимать?»

Кнопка с целевым действием отличается от остальных элементов на экране. Чем подчеркнуть отличие — цветом, размером или формой — решать дизайнеру на этапе дизайна.

Не менее важно выбрать подходящее слово, которым нужно подписать кнопку. Будет ли это слово глаголом, существительным, прилагательным или другой частью речи, зависит от функции кнопки. Об этом писал в своём блоге Илья Бирман, а на сайте «Бюро Горбунова» он даёт общий совет.

Источник: infogra.ru