Клиент – это не пользователь

Клиент может думать, что он знает, что нужно его пользователям, но это не так. Все дело в том, что клиент не является пользователем.

Не спрашивайте клиента, что он думает по поводу того, что нужно пользователям

Если клиент не знает, что пользователям на самом деле нужно, а вы делаете то, что говорит клиент, то все закончится печально. Вы создадите приложение, которое не будет удовлетворять потребности пользователей. Ваш клиент сначала будет счастлив, ведь вы все делаете так, как он говорит, но останется ли он довольным, когда пользователи отторгнут продукт?

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

Вы тоже не знаете, что нужно пользователям

Вы можете быть дизайнером или разработчиком с многолетним опытом, но и вы не знаете, что нужно пользователям. Именно тем пользователям, которые будут пользоваться разрабатываемым приложением. Почему? Каждое приложение уникально. Может быть, вы создавали подобное приложение в прошлом, но если вы не делали в точности такого же, вы не знаете, что может потребоваться пользователям.

Так кто же знает, что нужно пользователям?

Только пользователи знают, что им нужно

Это базовое понятие в нашей отрасли. Только пользователи вашего приложения знают, что нужно, а что – нет. Что работает, а что — нет. Обычно, наиболее простой решение при возникновении сложностей – спросить пользователей, что они об этом думают.

Тестируйте, тестируйте и еще раз тестируйте

Юзабилити-тестирование – это не строительство ракеты. На самом деле это очень простая процедура. Вам нужно:

Две комнаты;
Один или несколько репрезентативных пользователей;
Компьютер с запущенной программой;
Тестер;
Видеокамера;
Экран;

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

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

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

Говорите на одном языке

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

Улучшайте отношения с пользователями

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

Принимайте трудные решения

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

Не мешайте пользователям работать

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

Оберегайте, но не ругайте

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

Обеспечивайте обратную связь

Интерфейс должен обеспечивать достаточную обратную связь – пользователь должен получать реакцию от программы на свои действия. Пользователь никогда не должен задумываться, сработало его действие или нет (Стивен Круг, «Не заставляйте меня думать»).

Показывайте, а не рассказывайте

По возможности используйте понятные визуальные образы вместо длительных описаний.

Не дайте пользователю потеряться

Интерфейс должен давать пользователю возможность определить свое текущее положение. Пользователь не должен «заблудиться» в приложении.

Не продавайте то, что вы не сможете сделать

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

Не заставляйте пользователя ждать

Приложение должно выполняться достаточно быстро, чтобы пользователи сочли его пригодным к использованию.

Презумпция невиновности

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

Сделайте приложение доступным

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

Принципы дизайна пользовательского интерфейса web-приложений