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

UI Design Process

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

Глобальная задача при создании профессионального интерфейса — взять возможности системы, бизнес-процессы и прочие регламенты и связать их с миром человека. Помочь оператору рулить «ядром» и сделать его действия предельно рациональными. Хороший интерфейс — как хороший дизайн. Его не замечаешь, он не мешает и не допускает двусмысленности. Разные сервисы, разные дизайны, но сразу понятно, где вы находитесь и что тут можно сделать.

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

Проектирование идет рука об руку с дизайном. При создании интерфейса работу над дизайном стоит оставить напоследок и сосредоточиться на проработке прототипа и историй.

Пошаговый процесс проектирования пользовательского интерфейса (форма регистрации)

  1. Интервьюирование. Аналитическая работа. Исследование. Сбор требований по системе. Заказчик сообщает что должна быть регистрация на базе пароля и возможность регистрации через facebook. Цель исследователя — раскопать опыт пользователя и его ментальные модели со всеми вытекающими. Проектировщик пытается выстроить будущее взаимодействие пользователя с системой так, чтобы оно удачно объединилось с пользовательской ментальной моделью, сформировав позитивный опыт. На этапе исследования надо уделить самое пристальное внимание условиям, в которых работает оператор. Это не только физическая среда, но и внешние рамки: служебные требования, специфика деятельности, регламенты и т. п. Нам нужно досконально разобраться в контексте, не ограничиваясь взаимодействием оператора с системой. Помните, что мы проектируем интерфейсы, чтобы они соответствовали ожиданиям пользователей (решали проблему), второй критерий это скорость с которой они могут решить свою задачу. Кстати не забудьте спросить заказчика о прошлом опыте взаимодействия с интерфейсами.

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

    2. Структура интервью:

      • исследователь наблюдает за действиями пользователя;

      • исследователь слушает комментарии пользователя;

      • исследователь задает уточняющие вопросы;

      • пользователь отвечает на эти вопросы;

      • исследователь предлагает свою интерпретацию действий пользователя;

      • пользователь комментирует эту интерпретацию;

      • исследователь вносит коррективы в свою интерпретацию.

    3. Вопросы к интервью: Какую проблему мы решаем? Кто наши пользователи? Какая информация нужна нам для работы над продуктом? Какие действия и задачи пользователей нас интересуют? Где и когда пользователь совершает интересующие нас действия? Избегайте излишней самоуверенности (я отлично понимаю, что вы имеете в виду). Секрет хорошего интервью - умение слышать.

  2. Определяемся со всеми элементами которые могут присутствовать на странице (никнейм пользователя, e-mail, пароль и поле для его подтверждение, фамилия и имя пользователя, кнопка регистрации через FB, кнопка регистрации, ссылка на страницу логина). Любой элемент в прототипе появляется не просто так. Его место и функции определяются той или иной логикой. И тут есть тонкий момент. Нет абсолютно правильных или неправильных решений. Каждое решение — результат определенной цепочки рассуждений.

  3. Группируем все элементы в логические группы, группы также выстраиваем в порядке приоритетов для отображения. Если группы нуждаются в заголовках добавляем их (например названия модальных форм или группы полей). Для упрощения приоритезиования можно использовать табличку вида Объект (например, заголовок таблицы), На какие вопросы отвечает (информирует о том где находится пользователь), Польза (средняя). Ваш подход к проектированию: убрать бесполезные элементы и максимизировать пользу оставшихся. Обращайте особое внимание акцентам на странице и вертикальному ритму. Акценты — это функциональные элементы, важные для работы интерфейса, точки, где реализуются основные сценарии, которые выполняют сразу много задач или «хотелок» пользователя или бизнеса.

  4. Делаем набросок формы (скетч). Идеально подойдет листочек и карандаш. Схематически набрасываем поля формы. Делаем еще десяток альтернативных вариантов расположения и группировки полей (это же быстро делается карандашом). Рисуйте много. Проверяйте поведение на бумаге. Потом, когда уже за компьютер сядете, подправите, если что. Но пока вы не начнете рисовать на бумаге, вы ничего не увидите. Не ведитесь на попытки мозга пойти по короткой дорожке, подтолкнуть вас на путь наименьшего сопротивления.

  5. Оцениваем наш скетч. Возвращаемся к предыдущим шагам чтобы проверить что все требования нами учтены, если необходимо вносим коррективы. Идентифицируйте где могут возникать проблемы у пользователя в прохождении основных сценариев, какие неясности сбивают пользователя с толку и вызывают отторжение, где не хватает каких-то важных сущностей, какие работы надо сделать и что можно улучшить. Ищите непонятные элементы и сложные процедура решения базовых задач пользователя. Обращаем также внимание на взаимное расположение полей, отсутствие "дырок" в нашей форме. Количество элементов и способ их отображения (в колонку или в строку). Убеждаемся что форма консистентна нашей системе (общей дизайн концепции. Часто бывает что дизайн одной формы приносит новые решения которые нужно применить для всей системы) и элементы на самой формы консистентны (тоесть, шрифты, стили, размеры, отступы и другие элементы визуальной коммуникации соответствуют друг другу в пределах вашей формы). Оцениваем все ли будет понятно пользователю на форме, понимает ли он что от него требует система, если необходимо добавляем текстовые или графические подсказки (например какие поля обязательны к заполнению, а какие опциональны). Рассматриваем исключительные ситуации в которых что то может пойти не так (выбран уже существующий в системе e-mail или его формат не соответствует валидному адресу, не заполнено обязательное поле и тп.

  6. Отрисовываем форму (например в Figma).

  7. Оцениваем финальный вариант формы, проходим по всем предыдущим шагам проверяя все ли условия нами соблюдены. Кроме того:

    1. Пронумеровать, подписать и прокомментировать все экраны

    2. Логически организовать их послеждовательность

    3. Проработать возможные сценарии в том числе ошибки и граничные значения

  8. Протестировать пользовательские сценарии

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

Рекомендации по дизайну формы логина (например)

  • Емейл=логин, без капчи и сложных требований к паролю.

  • Регистрация и логин через соцсети.

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

  • Разумные требования к безопасности. Одно дело — платежный сервис, другое — игрушка на пару раз.

  • Правильная отработка ошибок пользователя — подсказки, парсинг введенных данных.

  • Форма логина на видном месте, чтобы не приходилось искать ее по всему экрану.

Рекомендации по дизайну форм

  • Объяснить, зачем нужно заполнять то или иное поле. Предупредить страхи пользователя (например, про спам и сохранность личных данных).

  • Парсить введенные значения, чтобы пользователь не мучился вопросами, в каком формате вводить номер телефона.

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

  • Показывать, какие поля осталось заполнить (реализовать это можно по-разному).

  • Не давать отправить форму — очевидно. Только не выводить ошибку во всплывающем окне, а давать подсказку на том же экране.

  • Делать кнопку неактивной можно, но только в том случае, если тут же рядом однозначно понятно, почему она неактивна и что нужно сделать.

  • Избавиться от лишних полей, если это возможно

  • Разбить форму на шаги, этапы, блоки, если она большая

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

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

  • Рациональное использование пространства формы

  • Проработка ошибочных сценариев.

    • Разместите сообщение в фокусе внимания

    • Показывайте, где именно произошла ошибка

    • Используйте понятные и короткие формулировки

    • Подскажите, как исправить ошибку

    • Сохраняйте работу пользователя

    • Проверяйте, насколько ваши сообщения об ошибках полезны пользователям.

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

Советы по дизайнеру интерфейсов

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

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

Дизайн никогда не будет готов на сто процентов. Особенно если это UX-дизайн. Тем более дизайн сложных интерфейсов. После двух-трех итераций по каждому разделу интерфейса дизайн готов на 85 процентов. А после еще двух-трех подходов можно дотянуть до 87 или откатиться на 82. Это уж как повезет. И значит, надо решить, где поставить точку.

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

Last updated