Перед тем, как приступать к работе, узнайте, что хуже всего сейчас и начните с решения именно этой проблемы.
У меня богатая практика в этом плане — полтора десятка дизайнеров, прошедших через нашу компанию, в своих первых проектах всегда начинали с того, что, вооружившись отвагой, бросались лечить то, что не болело вовсе или же болело совсем не сильно. Вероятно, в начале моей карьеры был таким же и я. Возможно, так же действуете и вы.
Поймите меня правильно — я не берусь утверждать, что гг. дизайнеры делали то, что делать было вовсе не нужно. Может, и нужно. Но первое впечатление заказчика, который приходит к дизайнеру именно потому, что у него что-то болит, было резко отрицательным. Вам бы тоже не понравилось, если бы вы пришли к хирургу вырезать болезненный нарыв, а он бы сначала отправил вас к окулисту выписывать очки (даже если бы вы действительно в них нуждались).
Соответственно, каждый проект надо начинать с определения того, что у интерфейса болит. Нужно как минимум расспрашивать заказчика, как максимум — тестировать, опрашивать пользователей и т. п. А затем формулировать список проблем, которые вы собираетесь решить своей работой. Если вы этого не сделаете, а сразу приступите к работе над интерфейсом, вы, несомненно, обидите заказчика, что непрофессионально.[8]
Не ведите себя как эксперт
Всем известно, что «в грязи обитают мелкобы» и что они вредны для здоровья. Но это знание никак не коррелирует с количеством людей, моющих руки после посещения туалета (и тем более с количеством людей, моющих руки перед посещением). Знание есть у всех, а руки моет только малая часть людей.
Видно, что-то не так с этим знанием.
И я скажу, что именно не так — само по себе знание
Интеллектуальная ловушка здесь в том, что многие знания дают ощущение компетентности; кажется, что если я много знаю про дизайн интерфейсов, я могу расслабиться и всё равно получится хорошо.
Увы, не получится. В действительности многие знания
Поэтому гораздо продуктивнее постоянно говорить себе, что «я ничего не знаю о дизайне интерфейсов». Эта установка ничего не сделает дурного с уже имеющимися у вас знаниями, но поможет избежать шапкозакидательства и в придачу откроет ваш разум для новых знаний (труднее учиться, если уже считаешь себя ученым).
И главное — надо делать, а не просто пассивно знать. Например, практически общеизвестно т. н. «правило 7±2», гласящее, что раз емкость кратковременной памяти человека редко бывает большей девяти элементов, делать меню большего размера неэффективно.[9] Трудно прочесть хоть одну книгу о дизайне интерфейсов и не наткнуться на него. Но вот вы его узнали, и что же? Станут ваши интерфейсы теперь самопроизвольно лучше или нет? Нет, не станут. Чтобы это правило действительно помогало, вам понадобится включить правило «Ни в одном меню не более семи элементов» в свой контрольный список проверки интерфейсов и в дальнейшем не лениться проверять свои интерфейсы по этому контрольному списку. И без этой работы ваше абстрактное знание не стоит и гроша.
Если вы не превращаете свои знания в конкретные проектные шаги — это бесполезные знания.
Не философствуйте; общих ответов на общие вопросы всё равно нет
Мне регулярно задают вопросы класса «что лучше, интерфейсное решение А или интерфейсное решение Б?», например, «где лучше располагать корзину в интернет-магазине, сверху справа или в каком-либо другом месте страницы?». Каждый раз я страшно теряюсь, поскольку (печальный) опыт убедил меня, что:
♦ Универсальных решений, работающих всегда, почти нет. Существуют общие законы, следование которым в интерфейсе всегда продуктивно (например, законы Фиттса и Хика).[10] К сожалению, открыта (и тем более доказана) только малая часть из них (собственно, только законы Фиттса и Хика), так что не будет преувеличением сказать, что мы, собственно, ничего про них и не знаем. Интересно при этом то, что все эти законы не говорят про конкретный интерфейс ничего — они описывают человека и особенности его восприятия/поведения, а не сами интерфейсы. Уверен, что так и будет продолжаться; что никогда человеческий разум не создаст, например, Общей Теории Корзины Покупок или Универсальной Парадигмы Чекбокса. А значит, не может быть и веры в возможность общих ответов на общие вопросы про интерфейс.
8
Справедливости ради должен сказать, что иногда приходится начинать сразу с разработки, не выясняя сначала проблемы — если предметная область слишком сложна, лучше сразу бросаться делать интерфейс, поскольку при этом изучить задачу можно более предметно и быстро, а значит — дешевле для заказчика. Но опять-таки — при этом вы обидите заказчика, хотя и сэкономите его деньги.
9
Симптоматично, что даже я о нём написал, хотя, говоря откровенно, считаю это правило совершенно бесполезным для работы дизайнера интерфейсов.
10
См. http://en.wikipedia.org/wiki/Fitts%27_law
и http://en.wikipedia.org/wiki/Hick%27_law
соответственно.