Заметки о проектировании интерфейсов информационных систем

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

Временные решения

При проектировании интерфейса (и программ вообще) достаточно часто сталкиваешься с ситуацией: «А давайте сделаем кнопку (окно, диалог и т.п.) пока такой (пусть и не очень подходящей), а потом при необходимости переделаем…». Так часто происходит, когда время поджимает, красивое решение сразу не находится и, вообще, «Мы же гибко разрабатываем - потом вернёмся и доделаем».

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

Диалоги

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

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

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

Объект с таким наименованием существует.

[да]     [нет]

(Тут кроме неадекватного диалога ещё и добавился баг некорректной проверки уникальности наименования).

Господа разработчики, чаще ставьте себя на место пользователя и задавайте себе вопросы: А зачем я делаю такой диалог? А поймёт ли меня пользователь? А что я хочу от пользователя в этом диалоге получить?

Быстродействие глазами пользователя

Быстродействие глазами пользователя ≠ быстродействие глазами разработчика. Почему спросите вы? А вот почему.

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

Т.е. все фичи в программе могут работать быстро, но для того чтобы пользователь получил результат, надо использовать, например, 20 таких фич, 30 раз кликнуть – и всё вместе это займёт очень приличное время.

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

Простота vs Сложность

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

Хороший пример реализации простоты интерфейса – продукция Apple - колесо для iPod (в iPod Shuffle даже дисплея нет, но им пользоваться очень просто); минимализм кнопок практически в любом продукте Apple; мультитач-интерфейсы под естественные движения пальцев и многое другое. Дизайну и интерфейсу Apple уделяло огромное внимание, очень тщательно его проектировало, Стив Джобс был ужасным перфекционистом. Рекомендую прочитать книгу Уолтера Айзексона «Стив Джобс».

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

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

Роль интерфейса при продаже ИС

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

Но интерфейс ИС в процессе продажи и в процессе реального использования может играть совершенно разные роли. Обычно мы продаём лицам, принимающим решения, а систему потом используют совершенно другие люди. И у них могут быть совершенно разные цели и потребности!

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

Т.е. при проектировании интерфейса надо учитывать и его реальное использование, и его использование в процессе продажи ИС.

Минимально функциональный продукт

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

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

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

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

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

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

А какие у вас есть заметки и подходы к проектированию интерфейсов?