– Программист! Нам нужен именно программист. Слушайте, бросайте ваш институт и пошли к нам!

…

А чем вы занимаетесь? — спросил я.

– Как и вся наука, – сказал горбоносый. – Счастьем человеческим.

– Понятно, – сказал я. – Что-нибудь с космосом?

– И с космосом тоже, – сказал горбоносый.

Аркадий и Борис Стругацкие,
«Понедельник начинается в субботу»

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

В действительности все не совсем так.

Как на самом деле

Еще 10-15 лет назад программисты были окружены ореолом романтики и элитарности. Сейчас, когда программирование перестало быть необходимым навыком для пользователей компьютеров, оно стало почти ремеслом. (Справедливости ради стоит заметить, что такие же процессы идут сейчас и в юзабилити-бизнесе. Юзабилити-специалист из гуру превращается в консультанта-поденщика.)

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

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

Какие еще факторы влияют на градус этих отношений?

Способствуют неприятию:

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

Повышают лояльность:

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

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

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

Что еще может и должен делать дизайнер, если хочет, чтобы работа с программистом была приятной и продуктивной?

Уважайте программиста

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

Специфика заключается в том, что кроме «проигрывания» пользовательских сценариев, программист пользуется прототипом как ТЗ непосредственно при разработке — ищет в нем прямые и косвенные указания по реализации той или иной функциональности.

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

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

Учите программиста

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

Волей-неволей программист должен научиться у дизайнера следующему:

• Контрольный список интерфейса. Знание хотя бы некоторых правил из чек-листа — лучше, чем ничего.
• Паттерны взаимодействия. Есть шанс, что правила и приемы, переносимые программистом из прототипа в код, будут им усвоены и использованы в дальнейшем.
• Тестирование. Почти всегда при оценке интерфейсов программисты пользуются критерием «интуитивно понятно», отсылающим к собственному опыту взаимодействия с интерфейсами. Несмотря на то, что у программистов такой опыт богаче, его специфика его же и обесценивает — программист общается с интерфейсами по-програмистски, а не по-пользовательски. Наблюдение программиста за юзабилити-тестированием написанного им продукта или хотя бы знакомство с результатами такого тестирования должно заставить его пересмотреть отношение к своей «интуитивности». Даже тот факт, что дизайнер обосновывает свои решения в прототипе результатами тестирования или полевого исследования, заставляет программиста задуматься о ценности тестирования как единственного метода, способного дать сколько-нибудь достоверную оценку интерфейсу.

Учитесь у программиста

Дизайнеру тоже есть чему поучиться у программиста:

• Проработка крайних ситуаций. Так получается, что бóльшую часть времени дизайнер тратит на проектирование целевого взаимодействия, самые частотные и общие для пользователя сценарии. Редкие случаи иногда и заметить некогда, не говоря уже о том, чтобы их проработать. Для программиста же крайние ситуации — каждодневный хлеб.
• Сложность реализации. Часто случается, что предложенный дизайнером интерфейс реализовать невозможно или слишком дорого. В таких случаях программист, глядя на прототип, обычно говорит либо «это мы точно не сделаем», либо «это будет сложно сделать». Мало того, что дизайнер должен уметь отличать одно от другого; первое чаще всего означает, что ресурсы, требуемые на реализацию этой части интерфейса, действительно слишком велики, второе — что программистам лень делать то, что, по их мнению, можно сделать проще. Дизайнер должен еще уметь оценивать ресурсы, возможности и специфику каждого проекта в сопоставлении с целями этого проекта. Это помогает избежать ненужных переделок и лишних споров с программистами.

Контролируйте программиста

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

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

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

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

О личном

Принципы, по которым меня учили программировать, я использую и сейчас. Один из них — «KISS» (Keep It Simple, Stupid) — очень полезен при проектировании интерфейсов. У программистов и дизайнеров зачастую одни академические основы и уж точно одинаковая цель — сделать продукт, за который им будет не стыдно.

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

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