Помним, любим, проектируем

Есть ряд вещей, о которых забывают при проектировании интерфейса /визуальном дизайне, чаще всего – еще на этапе оценки, затем – не включают их в проектный план, и в лучшем случае – вспоминают в последний момент во время разработки и проектируют «как попало» в сжатые сроки. И если нарисовать вечно забываемую фавиконку – это 5 минут работы, то некоторые вещи заслуживают гораздо большего внимания.

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

1) Обратная связь при успешных операциях

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

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

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

  

Итак, проверочные вопросы:

1.1. Уведомляем ли мы пользователя об успешной операции (например, создание объекта)?
1.2. Есть ли на форме подсказки при заполнении полей, где это уместно?
1.3. Как будет выглядеть индикатор прогресса?
1.4. Как будет выглядеть и где будет располагаться троббер (в народе «крутилка»)?

2) Обратная связь при неуспешных операциях

Об ошибках забывают немного реже, но тоже забывают. А ведь остроумная обработка ошибки может даже повысить лояльность пользователей!

2.1. Уведомляем ли мы пользователя о неуспешных операциях?
2.2. Где на формах будут отображаться валидационные сообщения, и что в них будет написано?
2.3. Как будет выглядеть сообщение об ошибке?
2.4. Есть ли страница 404 (для веба)?

3) Пустые состояния

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

Мне крайне нравится статья Designing For The Empty States (несмотря на то, что она посвящена в первую очередь мобильным приложениям), в которой есть несколько замечательных примеров того, как могут выглядеть пустые страницы. Пустая страница, помимо прочего, это возможность мотивировать пользователя выполнить определенные действия, и упускать ее было бы расточительством.

  

И да, пустая корзина – тоже заслуживает проектирования.

3.1. Понятно ли, как будет выглядеть страница, если на ней нет ни одного объекта?
3.2. Продумано ли информативное сообщение для таких случаев?

4) Страницы с множеством элементов

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

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

4.1. Сколько объектов в среднем будет отображаться на странице/в блоке?
4.2. Предусмотрены ли вспомогательные элементы для работы с большим количеством объектов?
4.3. Может ли пользователь оценить количество элементов (в том числе с учетом видимой области экрана)?
4.4. Предусмотрены ли разные виды (табличный/списочный и т.п.) для большого количества элементов, где это уместно?

5) Регистрация/вход/восстановление пароля

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

5.1. Есть ли в системе форма регистрации/авторизации?
5.2. Понятно ли, как попасть на форму регистрации/авторизации?
5.3. Как восстановить потерянный пароль?
5.4. Что происходит после заполнения формы регистрации?
5.5. Может ли пользователь выйти из системы?

6) Первый запуск/первое использование

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

И вроде все про это знают, но, тем не менее, в редком прототипе предусмотрен вид и поведение приложения во время первого запуска (FTUE, или First time user experience).

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

Целая подборка примеров первого использования, хороших и плохих, есть на сайте http://firsttimeux.tumblr.com/.

Вопросы для проверки:
6.1. Если это возможно, интегрирована ли регистрация/заполнение профиля в первое использование?
6.2. Предоставляются ли пользователю во время первого взаимодействия с системой инструкция, пошаговое руководство, подсказки или обучающее видео об интерфейсе?
6.3. Используются ли для обучения реальные взаимодействия вместо текста?
6.4. Есть ли у пользователя возможность пропустить обучение?

7) Состояния элементов

Простые элементы типа кнопка/ссылка, как правило, не представляют особого интереса. Дизайнеры составляют стайлгайд, в котором элементы показаны во всех основных состояниях – нормальное, в фокусе, при наведении курсора и т.д.

Однако для сложных взаимодействий (как, например, drag and drop), необходимо больше деталей. В книге «Проектирование веб-интерфейсов» приводится шаблон, который можно использовать для описания сложных взаимодействий:

Итак, еще несколько вопросов для затравки:

7.1. Какой будет обратная связь, позволяющая понять пользователю, что можно делать с объектом?
7.2. Как будет меняться сам объект, с которым производятся манипуляции, и окружающие его области/объекты?
7.3. Как в каждый момент времени будет выглядеть курсор?
7.4. Будут ли отображаться всплывающие подсказки, как они будут выглядеть и что на них будет написано?
7.5. Какой будет обратная связь, сообщающая об успешности/не успешности операции?

8) Этапы жизни объектов

Есть весьма полезный подход, который, тем не менее, чаще используют аналитики, чем проектировщики — (S)CRUD(L) (Search, Create, Update, Delete, List).

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

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

Но если совсем лень, вот вместо этого несколько вопросов для самопроверки:

8.1. Каждый ли объект в системе можно искать, создать, посмотреть и отредактировать (если это не противоречит бизнес-правилам)?
8.2. Может ли пользователь отредактировать тот объект, который создал?
8.3. Может ли пользователь удалить объект, который создал по ошибке (есть ли в системе замена удалению, если само удаление запрещено)?
8.4. Для каждого ли объекта, представленного списком, есть страница просмотра?

9) Поиск и результаты поиска

Само поле для поиска забывают редко, но бывает и такое. А вот страницу с результатами поиска иногда упускают из вида.

9.1. Как будет выглядеть поисковая выдача?
9.2. Как в результатах поиска будут выделяться слова из поискового запроса?
9.3. Какую информацию выводить в результатах поиска?
9.4. Откуда будет доступен поиск, и как он будет выглядеть?
9.5. Можно ли со страницы с результатами вернуться на страницу поиска?
9.6. Есть ли у пользователя инструменты для уточнения поискового запроса, если он возвращает слишком большое количество результатов?

10) Сообщения и нотификации на email

Там, где есть регистрация и восстановление пароля, как правило, есть и сообщения. А для сообщений нужен не только текст и тема письма, но и шаблон. И кто же этим будет заниматься, если не вы?

10.1. В какие моменты система будет отправлять сообщения пользователям?
10.2. Для всех ли сообщений есть текст и дизайн?

11) Интерфейс администратора

Или веб-интерфейс для редактирования контента в мобильных приложениях. Собственно вопросов тут только два:
11.1. Будет ли интерфейс администратора в системе в принципе?
11.2. Нужно ли его проектировать?

12) Вид интерфейса при смене языка

Если ваше приложение будет доступно в нескольких языковых версиях, не забудьте предусмотреть время на проверку, как интерфейс будет выглядеть при переводе на другой язык. Бывает, что слово/фраза/предложение занимает в 2-3 раза больше места, и все аккуратное выравнивание сразу расползается.

А о чем чаще забывают по вашим наблюдениям?