RockBee

Иван RockBee Васильев

E-mail, jabber: rockbee@rockbee.com

Cell phone: +7 985 295-80-42

Skype: rockbee.mobile

29 июня 2013 г.

С чего начать изучение интерфейсов

Не так давно мне позвонил мой друг, и попросил вкратце рассказать, с чего начать изучать тему про проектирование/создание интерфейсов.

Так как это был все-таки мой друг, я задумался всерьез, и не стал отвечать что-то в духе «это тема большая, я сходу не отвечу» :-)

Хотя тема про создание интерфейсов действительно большая, но «с чего начать» — вполне себе понятная и приемлемая, чтобы обдумать её за пару дней. Я обдумал, и пока обдумывал, сделал несколько заметок. Может быть кому-то пригодится, почитайте.

Отвечая на вопрос, с чего начать изучение темы создания интерфейсов, я бы условно выделили четыре темы:

  1. Семантика (см. определение семантики в Википедии, если не в курсе).
  2. Тестирование.
  3. Управление разработками/менеджмент.
  4. Прототипирование как способ разработки и инструменты прототипирования.

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

Нумерация тем мною создана сознательно.

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

Трудно себе представить хорошего программиста, который не может/не умеет формулировать задачи и, например, не учитывать при этом контекст. У него просто не будет выполняться программа. Точно так же можно программировать поведение людей, когда они взаимодействуют с интерфейсом — они понимают или не понимают то, что им сообщается, и либо программа выполняется (они решают свою задачу так, как было предусмотрено дизайнером), либо фейл (Something went wrong), ошибка в выполнении программы (они закрывают окно с мыслью «я чего-то не понимаю» в лучшем случае и с мыслью «какой идиот 6№@Tь это сделал!?»).

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

Итак, программисты, чтобы создать программы, описали язык и придерживаются созданных правил. От точности формулировок будет зависеть работоспособность программы. Точно так же и люди, для взаимодействия друг с другом, и, отчасти для программирования поведения других людей, договорились о значении комбинаций звуков и букв и форматах их записи. Я не подразумеваю всякие заумные штуки вроде НЛП (я не сталкивался с этим никогда), говорю только о том, что один человек может сказать/написать другому, чтобы тот как можно более однозначно понял смысл сказанного и выполнил то, что требуется. Требоваться это может как тому, кто сообщает мысль, так и тому, кто её получает: дизайнер сообщает, как и что следует сделать, чтобы получить нужный пользователю результат, а пользователь соглашается на выполнение этих задач, чтобы получить нужный опять же пользователю результат.

Кстати, это объясняет, почему все программисты, которые со мной работали, оказывались либо лингвистами и ярко выраженными grammar-nazi, а дизайнеров они уважали только тех, которые могли грамотно и красиво сформулировать мысли на макетах, которые им приходилось «оживлять». И именно исходя из соображений грамотности и знания языка я отбирал дизайнеров: если они могут сформулировать мысль, то выразить её в фотошопе — это уже задача второстепенного уровня (та самая «базовая» для дизайнера: инструментарий надо знать).

Итак, с семантикой вроде как всё понятно. Интерфейсы — это программирование пользовательского поведения. Как в любом программировании, язык (его знание и умение применять) — это 75% знаний.

Остальное — более простые и понятные, инструментальные, а не понятийные знания.

Про менеджмент (управление людьми и проектами) я здесь писать точно не буду, — много написано другими людьми. Про разработку интерфейсов в частности — тоже. Это и статьи Якоба Нильсена, и подходы к программированию — типа XP/Agile/Kanban/etc., в зависимости от компании и/или проекта и команды — выбирай любой подходящий.

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

Замечу только, что прототипирование — это не просто веха в создании интерфейсов. В нем есть смысл только в совокупности с тестированием и экономичностью: 

1) выдвинули гипотезу, что такая задумка будет работать;

2) проверили, без подключения дорогостоящих оформителей с фотошопом, что такая задумка работает не совсем так, как мы себе планировали;

3) внесли несколько изменений и снова всё проверили;

4) мы получили достаточно удовлетворительный результат (люди стали понимать, чего мы от них хотим, и всё это пока что без подключения дорогостоящих фотошопперов);

5) решили оформить прототипы — посмотреть на цвета, на их значение, на иллюстрации, на то, как они отвлекают пользователей от решения задач;

6) поняли, что картинки отвлекают людей от смысла сообщения, но не все: некоторые наоборот, помогают (а выявили мы это в ходе A/B тестирования, например);

7) Сделали выводы, зафиксировали их, отдали дизайнерам с фотошопом, чтобы те привели всё это в порядок и превратили в сайт/сервис по готовым, протестированным шаблонам.

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

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

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

Если абстрагироваться от конкретных применений (доработка сервиса, создание нового, создание сайта, создание формы чего-угодно и так далее), то работа с задачами может (я не настаиваю, просто размышляю) происходить следующим образом:

  1. Как в потребностях пользователей выявить решения для бизнеса? Это самая ранняя стадия, которую мы здесь совсем не будем рассматривать, но которая обычно определяет смысл вообще всей работы дизайнеров :-)
  2. Фиксирование задач бизнеса (заказчика). Допустим, бизнес (это такой абстрактный бизнес — менеджеры, заказчики, подразделения и так далее) уже принял решение о своих задачах, и теперь ищет оптимальные пути их решения.
  3. Определение задач пользователя. Грубо говоря, зачем ему всё это может быть нужно и как он должен прийти к этому решению.
  4. Выявление пересечений этих задач: как, решая задачи пользователей, решаются задачи бизнеса?
  5. Создание прототипов.
  6. Тестирование выполнения пользовательских задач. Здесь всё просто: подопытному пользователю ставится задача, которая была определена ранее, и в ходе эксперимента мы наблюдаем, справляется он с выполнением задания или нет, как быстро у него это получается, что можно изменить/улучшить и так далее.
  7. Тестирование выполнения задач бизнеса: даже если пользователь быстро удовлетворил свои потребности, это еще не значит, что у дизайнера получилось решить задачи бизнеса. Здесь начинается (или продолжается, у кого как) процесс итеративного тестирования, тестирования изменений, и оценка проводится уже не по только по качественным показателям (время, скорость, конверсия), но и по количественным (для упрощения будем считать только деньги).

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

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

В интерфейсах мелочей не бывает.