Вся правда об Agile-дизайне

Концепция Agile никуда не исчезнет. Экономические трудности последних месяцев наконец добили каскадную модель; теперь, больше, чем когда-либо, неприемлемы долгие этапы определения требований и предварительная подготовка приблизительной документации. Программный продукт должен быть с самого начала доступен для осмотра и оценки.

Концепция Agile уже вошла в жизнь многих дизайнеров (а для непосвященных после статьи приведен список источников). Мы достигли того момента, когда приходится либо адаптироваться, либо подвергнуть себя риску отстать от жизни. Однако можно порадоваться тому, что Agile не мешает привычному ходу вещей - не мешает исследовать, развивать замысел, тестировать и улучшать дизайн - требуется лишь использовать новые приемы. Настало время посмотреть правде в лицо и доказать, что дизайн может меняться и оставаться актуальным даже в такие невообразимо изменчивые времена.

Текущее положение вещей

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

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

Целью Agile, однако, является оперативность создания программного продукта и легкость внесения изменений. Приведенные системы основываются на отличных друг от друга идеологиях: изменчивость - вместо предсказуемости, приспосабливаемость - вместо предвидения. Несмотря на эти отличия, многое из Манифеста Agile было всегда присуще дизайнерам. Отношения, а не процессы. Сотрудничество, а не переговоры. Обратная связь. Простота. Звучит, как музыка.

Исследование Философия Agile утверждает, что "рабочий программный продукт является первейшим показателем успеха", не оставляя тем самым места для детальных исследований. И хотя Agile-продукты функционируют и без помощи пользователей (что исключает интуицию и "дизайн-приманку"), результат часто не радует глаз. Операция, может, и удалась, но пациент умер.

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

Так как исследование не должно быть громоздким, это влияет на его тщательность. К счастью, достаточно будет одного или двух коротких перерывов на итерацию. Было бы разумно найти потенциальных пользователей через социальные сети (друзья друзей, Twitter) и устраивать короткие сеансы, имеющие своей целью сбор информации для будущих этапов и дешевое (т.н. партизанское) тестирование уже готовых частей. Если вам не удалось раздобыть "настоящих" пользователей, это не значит, что все потеряно. Команды маркетологов часто обладают массой демографической информации, логи с серверов содержат статистику поиска и т.д. Не самые точные методы, но даже они могут помочь дизайнерам заполнить лакуны.

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

К счастью, нам доступен опыт из других сфер деятельности. Съемочные группы работают почти в соответствии с концепцией Agile, снимая эпизоды в том порядке, который диктуется материально-техническими обстоятельствами. Чтобы обеспечить правильность общего видения проекта, его согласованность и последовательность, приглашаются специалисты: сценаристы и режиссеры. В веб-сфере дизайнеры могут играть похожие роли, но они должны взять их на себя добровольно. Это означает отслеживание реакций пользователей и удерживание заказчиков от поспешных решений.

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

"Золотое правило" гласит, что дизайнеры должны исследовать (n+2)-ю итерацию, разрабатывать дизайн для (n+1)-й, поддерживать n-ю и присматривать за (n-1)-й. Но не стоит следовать этому доброму совету буквально. некоторые этапы потребуют больше времени, чем отведено условными рамками. Прислушиваясь к собственной интуиции и опыту, дизайнеры должны заранее отмечать потенциально сложные этапы, чтобы отвести достаточно времени на разработку. Это против Agile-правил, однако пойдет на пользу продукту.

Замысел

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

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

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

Отчетность

Agile нарочито легко относится к документации. Замечательно - больше времени останется на размышление и планирование. Эта особенность делает бессмысленной разработку каркасов и статических страниц. Они слишком неповоротливые для Agile, особенно сейчас, когда страница уже не является наименьшей неделимой частицей Интернета. Вместо них мы предпочитаем "отношения, а не процессы", начиная с разговоров, а не с шаблонов, выбирая интерактивные прототипы, а не статические каркасы.

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

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

Прототипирование в HTML с помощью Axure или iRise может стать хорошей альтернативой. Зная, на чем можно споткнуться, их разработчики позаботились о полной ясности схем. Также они достаточно гибки, чтобы работать в условиях изменяющихся требований, но достаточно последовательны, чтобы проверять полный путь разработки. Развитие ролей

Говорят, что современные организационные схемы перегружены ссылками, но в некоторых компаниях на подобной схеме дизайн до сих пор является отдельно лежащей точкой пространства. Дизайнеры должны оставить стремление к совершенству ради быстрой поэтапной работы. 90% верных решений - нормальный ход дел для концепции Agile. Хоть такие действия и противоречат интуиции, к худу или к добру, Agile выше ценит время, чем искусство. Создавать такой дизайн, чтобы коллеги позеленели, в данных условиях будет тяжело. Невелика потеря.

Но вот по следующему вопросу уже сложнее придти к компромиссу. Цитируя Алана Купера: "Не надейтесь, что на улице ждет толпа пользователей, обуреваемых желанием купить ваш вшивый продукт. " На рынке лучше быть лучшим, чем первым, поэтому дизайнеры естественным образом становятся блюстителями качества, выбивая из клиента средства под тщательную разработку.

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

Перспективы Вне зависимости от ярлыков, дизайнерскому сообществу и Agile уже пора встретиться и обсудить общее будущее. Мы нужны друг другу, но для этого надо выпустить из рук шпаги и покинуть свои башни из слоновой кости. В конце концов, нас объединяет общая цель: предоставить клиентам и пользователям как можно лучший продукт.