Практически во всех компаниях, с которыми работала наша
консалтинговая фирма, программисты считают, что форму и поведение
программного продукта должны определять именно они. Наверное, при
отсутствии интерэкшн-дизайнеров1 так
оно и есть. Программист по опыту знает, что никто не продумает за него,
как именно программа будет предоставлять информацию пользователю.
Остальные тоже не задаются вопросом, почему разработкой поведения
программы занимается программист, так как это считается технической
задачей.
В результате руководители уверены, что интерэкшн-дизайн им бесплатно
сделают программисты. Им кажется, что интерэкшн-дизайнеры вообще не
нужны: если программное приложение получится слишком сложным, они
решат, что программистам нужен соответствующий психологический тренинг.
Однако дизайн поведения программы, разработанный программистами, далеко
не бесплатное приобретение. Такой дизайн не качественен, не эффективен и, к тому же, связан с серьезным риском.
Такой дизайн не качественен, потому что программисты не способны думать как интерэкшн-дизайнеры (или пользователи).
Если вам важно, чтобы пользователи и заказчики были довольны
программным продуктом, то его дизайном должны заниматься люди, которые
понимают чаяния заказчиков и пользователей, и способны смотреть на мир
их глазами. Программисты же не способны думать так, как думают обычные
люди. Их мыслительный процесс настолько отличается от
среднестатистического, будто они относятся к другому биологическому
виду. Алан Купер даже прозвал их "хомо логикус". Он нас, сапиенсов, их
отличает не только пристрастие к кофеину и отвращение к дневному свету;
самое большое различие состоит в мировосприятии. Нам достаточно просто
радоваться тому, что программа делает то, что мы от нее хотим. Нас не
интересует, как именно она это делает. А вот представитель вида хомо
логикус, в отличие от нас, глубоко интересуется как раз тем, как
программа устроена внутри.
Хороший программист одновременно удерживает в голове целую дюжину
переменных и продумывает все возможные граничные условия, которые могут
нарушить работу программы. А вот о чем программист задумывается редко,
так это о том, что "возможное" далеко не всегда означает "вероятное".
Возьмем простой пример: в приложении Apple iPhoto самые важные для
пользователя функции, как например, разворот и обрезка фотографий,
вынесены на самое видное место. Если бы дизайн для iPhoto создавал
программист, то наряду с часто используемыми функциями, "на
поверхности" оказались бы и специфические возможности, например,
изменение глубины цвета изображения. Интерэкшн-дизайнер либо "спрячет"
эту возможность подальше в меню, либо, что еще лучше, вообще откажется
от нее, сэкономив, тем самым, время на разработку и поддержку программы.
Такой дизайн не эффективен, потому что изначально у программиста нет описания поведения программы.
Когда дизайн продукта создается программистом, время работы существенно
увеличивается. Первая, и самая очевидная причина состоит в том, что
программист тратит свое драгоценное время на выбор элементов управления
и расположение их на экране, когда он мог бы писать код. Эта
неэффективность еще больше заметна при итеративной разработке:
представьте себе, что вы пригласили архитектора построить дом, но не
дали ему чертежей. Когда вы отвергаете то, что было построено во время
первой итерации, он говорит: "Прекрасно, второй этаж вам был не нужен.
Нет проблем, сейчас мы его снесем, а в следующий раз постараемся
построить то, что вам понравится больше". Конечно, при разработке
программных продуктов этот процесс не так нагляден, но его последствия
оказывают не менее разрушительный эффект на бюджет и временные рамки
проекта.
"Но ведь мы же дали им спецификации!" - восклицают маркетологи. "Они
просто не делают то, о чем мы их просим!". Если честно, самим
программистам тоже не очень-то нравится постоянно переделывать свою
работу. Однако они не умеют читать мысли, а без этой способности едва
ли можно разобраться в обычной спецификации, которую написали
сотрудники отдела маркетинга. Если бы Стивен Спилберг дал своей команде
такую задачу: показать сцену погони, любовную сцену, взрыв и хэппи энд,
то едва ли в итоге получился бы впечатляющий блокбастер.
Программисты, по идее, должны работать с неким планом и
спецификацией поведения программы, которая описывает внешний вид
каждого экрана и поведение всех находящихся на них элементов. Когда у
программистов есть подобные спецификации, они работают гораздо
эффективнее, заметно сокращая и время, и объем работ, и количество
итераций, что не раз отмечали наши клиенты. Одни говорят, что время
разработки сократилось вдвое, другие утверждают, что сэкономили год
работы.
Этот дизайн связан с риском, потому что руководители проекта не контролируют ситуацию.
У
большинства руководителей - тех, которые не разбираются в технических
вопросах, и даже тех, которые разбираются в них очень хорошо, в глубине
души живет ощущение, что они не контролируют процесс разработки. И они
совершенно правы. Конечно, они могут определять сроки, зато
программисты решают все остальное. В этом нет ничего пред- или
злонамеренного. Если бы это было так, то руководители уже давно приняли
бы меры. Это происходит негласно, потому что вопросы поведения продукта
считаются техническими и автоматически переходят в ведение
программистов.
Проблема усложняется еще и тем, как мыслит разработчик: у него
никогда нет достаточного количества времени - ни на то, чтобы писать
код, ни на то, чтобы следовать процессу, ни на что. Если маркетолог
подойдет к нему с вопросом: "А нельзя ли вот тут сделать поддержку
функции "перетащить и оставить"?", то программист обязательно ответит:
"Нет, это практически невозможно". Однако по-настоящему он имеет в
виду: "Это невозможно сделать за тот ничтожный период времени, который
вы мне отвели. Я не могу выполнить те двадцать запросов, которые вы уже
дали, и еще вот этот". Эта уверенность в нехватке времени приводит к
подспудным решениям относительно функциональности продукта, а
руководители даже не понимают этого. А что если возможность "перетащить
и оставить" сделала бы ваш онлайновый магазин недосягаемым для
конкурентов? Что если бы это позволило сэкономить 20 000 долларов в
месяц на звонках в службу технической поддержки? Абсолютное большинство
руководителей предпочтут выпустить хороший продукт, но на месяц позже,
чем в срок, но плохой.
Включая в команду разработчиков дизайнеров-непрограммистов,
руководители снова обретают контроль над решением важных вопросов,
касающихся функциональности продукта. Вооружившись исследованиями
поведения целевой аудитории, интерэкшн-дизайнеры могут сесть за "стол
переговоров" с маркетологами, техническими специалистами и
руководителями и найти такое решение, которое наилучшим образом
удовлетворяло бы ожидания пользователей и клиентов. Тут же технический
специалист может донести до общего сведения, сколько времени и сил
уйдет на это у программистов, маркетологи оценят влияние такого решения
на количество продаж, а руководитель, получив всю необходимую
информацию, принимает оптимальное для компании решение.
Работа интерэкшн-дизайнера выгодна с точки зрения себестоимости,
потому что в результате у программистов высвобождается время на
написание кода, клиенты получают продукт, который им нравится, и
который они не променяют ни на какой другой. При этом сокращаются
расходы на службу технической поддержки, а весь процесс разработки
становится более предсказуемым и контролируемым. Так почему бы вам
прямо сейчас не набрать номер отдела по найму персонала и не сказать,
что у вас есть вакансия?
Об авторе
Ким Гудвин (Kim Goodwin)
является вице-президентом по дизайну и генеральным менеджером компании
"Cooper". Если у вас есть вопросы, комментарии или предложения, вы
можете написать ей письмо на адрес kim@cooper.com
1) Для термина "interaction designer" пока еще не существует
устоявшегося русского перевода. Именно поэтому здесь этот термин просто
транскрибируется. "Интерэкшн-дизайнер" - возможно, не лучший вариант,
но по крайней мере, звучит привычно в профессиональной среде и не
создает вопросов относительно его значения. Другие варианты перевода:
"дизайнер взаимодействия", "проектировщик взаимодействия", "дизайнер
интерактивных систем".
