Дизайн пользовательского интерфейса. Искусство мыть слона

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

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

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

2 Начать интерфейсы тестировать.

Я делаю фигню

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

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

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

Тестировать, тестировать и ещё раз тестировать!

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

Без тестирования сделать действительно хороший интерфейс можно только случайно и только если интерфейс маленький.

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

Тестировать?

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

У этого подхода, впрочем, есть два недостатка:

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

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

Так что лучше уж тестировать.

Как тестировать

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

Часть 2 Что такое хороший интерфейс

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

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

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

Например, будет невозможно:

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

♦ …понять, когда работа уже закончена и можно заняться чем-то другим. Слона можно мыть вечно, но зачем?