Итеративный дизайн на самом деле не только про дизайн, но и про подход к созданию продукта. Он связывает дизайнеров, команду разработки, PO (product owner), PM (project manager) и пользователей в систему, где каждый влияет на то, каким становится продукт.

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

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

Навигация по статье

• Тип проектов и состав команды

• Как мы делали раньше

• Какие были проблемы

• Чего хотели достичь

• Итеративный дизайн

• Итерации продукта + прототипов

• Короткие итерации спринтами

• Общие практики

• В каких ещё случаях полезен итеративный дизайн?

• От общей картины к деталям

• Итог

Тип проектов и состав команды

Сначала хочется рассказать, что за проекты мы вообще делаем и кому могут подойти такие процессы. Мы делаем R&D-проекты, сложные корпоративные сервисы и сайты. Очень часто мы делаем MVP-проекты за короткие сроки, чтобы протестировать идеи. Часто проекты довольно большие и с расплывчатым функционалом, в таких проектах сложно спрогнозировать детально, что нужно сделать. Тут на помощь как раз приходит итеративный процесс. Также в наших проектах важно тестировать решения как можно раньше и дешевле.

Обычный состав команды на проекте: архитектор, PO, PM, 1–2 дизайнера, 2–4 фулстек-разработчика (или 1–2 фронтенд + 1–2 бекенд), DevOps, ML-инженер. На начальных этапах дизайнер больше взаимодействует с PO и PM, чтобы выяснить детали проекта, ценности, что нужно сделать. На этапе прототипов точечно подключаются разработчики и архитектор. Когда прототипы закончены, они полноценно просматриваются и обсуждаются с командой.

Кому может быть полезен итеративный дизайн

1. Командам, которые работают над MVP- и R&D-проектами с нуля.

2. Командам, которые делают новый продукт без родительской дизайн-системы.

3. Командам, которые работают с проектами в условиях высокой неопределённости.

4. Дизайнерам, которым тяжело отдавать незавершённый результат.

5. Командам, которые только выстраивают процесс работы.

6. Менеджерам и тимлидам, которые ищут новые практики для быстрых поставок функционала пользователям.

Кому, скорее всего, не подойдёт

1. Командам, которые работают с большим существующим продуктом и зрелой дизайн-системой.

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

Как мы делали раньше

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

Какие были проблемы

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

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

3. Детальный прототип не сильно отличался от финального дизайна, на него уходило много времени.

   

4. Разный контекст у дизайнеров и разработчиков. Пока дизайнеры работали над интерфейсом, разработчики были заняты другими задачами и не могли вникнуть в контекст проекта. После передачи проекта в разработку дизайнеры переключались на другие задачи и теряли контекст, а у разработчиков появлялись вопросы по тому, как работает интерфейс.

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

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

Чего хотели достичь

1. Побороть перфекционизм.

2. Быстрее отдавать результат в разработку.

3. Как можно раньше тестировать гипотезы и решения. 

4. Как можно раньше подключать разработчиков к обсуждению.

5. Как можно раньше и дешевле вносить изменения.

6. Не верстать прототип pixel-perfect.

7. Благодаря постоянной обратной связи сделать то, что действительно нужно пользователю.

Итеративный дизайн

Итеративность — это процесс работы, при котором проект делится на небольшие итерации. Результатом итерации является рабочий продукт, который можно протестировать, оценить и улучшить. Мы начинаем с чего-то простого, собираем обратную связь, вносим изменения. И так несколько раз, пока не получим достаточный результат.

Итеративная разработка

Процесс итеративного дизайна, описанный Uprock

Метод прогрессивного джипега Лебедева

Из итеративного процесса для нас особенно важными оказались две идеи:

1. Циклы обратной связи. Сделать что-то простое, показать, протестировать, улучшить, пока результат не станет достаточным.

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

Итерации продукта + прототипов

У нас есть продуктовые итерации. Мы составляем USM (User Story Map) для сервиса, где описываем примерные требования и ценности по функционалу, а потом определяем приоритеты этого функционала и решаем, что пойдёт в первую итерацию.

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

Работу над дизайном одной продуктовой итерации мы поделили на следующие этапы:

1. Прототип 0. На этом этапе активно работаем с заказчиком/PO и PM. Тут важно понять, какие проблемы нужно решить. Также нужно представить общую картину, понять верхнеуровнево, как будет работать система, проверить логику, порисовать User Flow и схемы работы. Тут мы рисуем прототипы от руки, чтобы их было не жалко выбросить, быстро перебираем идеи, гипотезы и возможный функционал.

   

   

2. Прототип 1. Детализируем Прототип 0, добавляем интерактивные элементы, проверяем функционал, сценарии использования, гипотезы. На этом этапе уже проводим быстрые и простые тесты, интервью, юзабилити-тестирование с пользователями, подключаем разработчиков к обсуждениям, проговариваем работу интерфейса и возможные вопросы. На этом этапе разработчики и архитектор уже начинают проектировать архитектуру системы.

   

3. Прототип 2. Прорабатываем пошаговый интерактивный прототип, добавляем краевые кейсы интерфейса, валидацию, ошибки, пустые состояния и т.д. На этом этапе полноценно тестируем прототип с пользователями и проходим сценарии. После тестов вносим правки или записываем идеи по функционалу на следующую итерацию, фиксируем гипотезы, идеи и решения в документации. Так как разработчики используют подход Mobile First, последним шагом делаем мобильную версию уникальных экранов сервиса и отдаём прототип разработчикам.

   

4. Дизайн. Параллельно с разработкой функционала делаем дизайн сервиса. На этом этапе прорабатываются дизайн интерфейса, состояния компонентов, подготовка к вёрстке, UI-kit и т.д.

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

Преимущества

1. Совместная работа дизайнеров и разработчиков. Раньше зона ответственности дизайнера заканчивалась на передаче макетов, а в процессе разработки всплывали детали, которые остались без внимания. Совместная работа помогла увидеть, какие вопросы могут возникнуть, какие edge-кейсы нужно продумать.

2. Важные вопросы по функционалу решаются на самых ранних этапах.

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

4. Разработчики перестали верстать pixel-perfect прототипы. Раньше детализированные прототипы часто воспринимались как почти готовый дизайн, поэтому разработчики старались точно повторять все отступы, размеры и другие детали. Итеративный подход помог разделить добавление функционала и работу над визуалом на разные этапы, поэтому команда сначала сосредотачивается на том, чтобы решение работало, а уже потом доводит внешний вид до финального состояния.

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

6. В следующие итерации попадают только решения, которые прошли тесты.

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

Недостатки

1. Иногда на этапе UX-тестирования пользователи воспринимают первые итерации как финальный макет и оценивают визуальную составляющую, а не функционал.

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

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

Как жилось разработчикам с таким процессом

Преимущества

1. Можно быстро приступать к разработке, цена ошибки не такая высокая, сразу понимаем, что будет работать, а что нет.

2. Классно, что тестирование на реальных пользователях проводилось, чувствовалось, что фидбек учитывается.

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

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

Недостатки

1. Разработчикам может быть непривычно откладывать работу над интерфейсом и сосредотачиваться только на функционале, часто возникает желание сразу сделать всё красиво и правильно.

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

Короткие итерации спринтами

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

Главное отличие от предыдущего варианта: размер дизайн-итерации. В первом варианте прототип охватывает всю продуктовую итерацию с большим количеством user story, во втором только одну user story, которую можно успеть сделать за спринт.

Перед стартом мы провели подготовительный этап, определили цели проекта, описали нужные сценарии и составили User Story Map с примерным функционалом.

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

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

Чтобы быстро проверять гипотезы и тестировать идеи, часть функционала мы рисовали от руки, а затем накладывали анимации для получения интерактивного прототипа. Это помогало оценить удобство взаимодействия ещё до передачи в разработку и наглядно донести идею до заказчика.

Преимущества

1. Каждый спринт заказчик видел новый функционал и мог сразу им пользоваться.

2. Обратная связь от заказчика и команды была на ранних этапах, когда вносить изменения проще и дешевле.

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

4. Наглядные результаты работы мотивировали команду развивать и улучшать продукт.

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

6. Мы могли вовремя остановиться, если тестирование в проде показывало, что цель достигнута и функционал уже делает то, что нужно.

Недостатки

1. Морально сложно показывать заказчику сырой интерфейс, не все готовы видеть такой результат и участвовать в процессе тестирования прототипов от руки.

2. В коротком спринте редко удаётся проработать сценарий использования и проверить его на адекватность со всех сторон.

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

Что важно?

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

2. Такой процесс был очень полезен в проекте с высокой неопределённостью и сложностью, потому что мы очень часто собирали фидбек с заказчика и направляли работу.

3. Заставлять себя и команду прорабатывать следующие итерации. Часто хочется остановиться на текущем варианте и перейти к новому функционалу, но важно делать 2, 3 и следующие итерации, чтобы качественно улучшить решение.

4. Определять границы итераций, чтобы не делать MVP бесконечно.

5. Проговорить с заказчиком, что он видит неокончательный результат.

Как жилось разработчикам с таким процессом

Преимущества

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

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

Недостатки

1. Когда делаешь MVP в быстром темпе, часто принимаются быстрые костыльные решения и растёт техдолг. По-хорошему, если MVP и гипотезы выстреливают и проект продолжается, нужно переделывать всё по-нормальному с самого начала и делать продакшн-реди систему.

Общие практики

Документирование

В итеративном процессе очень важно документировать сам процесс и результаты. В итоге, когда дойдёт дело до новой итерации, с хорошей документацией будет легко вспомнить, почему и какие решения принимались, а что откладывалось на будущее. Мы стали составлять Design Decision Records (то же самое, что ADR, только для дизайн-решений). Структуру DDR мы составили, ориентируясь на эти шаблоны ADR. Пример документации, которую мы описываем по дизайну, можно посмотреть здесь. Теперь, возвращаясь к предыдущим итерациям, можно быстро вникнуть в контекст проекта и делать новые итерации.

Как понять, что прототип закончен и пора остановиться, если нет дедлайнов?

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

2. Прототип покрывает сценарии, запланированные в этой итерации.

3. Одни и те же элементы переделываются снова и снова по кругу.

4. Улучшения становятся еле заметными и не приносят ощутимой пользы.

5. Появляется желание выровнять отступы, оформить компоненты получше.

6. У команды разработки не осталось вопросов к работе системы.

Как перфекционисту делать первые итерации и отдавать неокончательный результат?

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

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

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

3. Установить для себя планку, какой результат будет достаточным и хорошим.

4. Фокусироваться на пользе. Можно бесконечно полировать то, что пользователю не нужно, а можно переключиться на новую задачу, которая принесёт много пользы.

В каких ещё случаях полезен итеративный дизайн?

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

Вот несколько кейсов на эту тему:

Кинопоиск

Snapchat

Sonos

Digg

От общей картины к деталям

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

Работа над презентациями

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

Работа над сайтами и лендингами

В чём может быть полезен итеративный подход?

1. Работу над сайтом можно начать с общей картины, разметить структуру страницы, определить порядок блоков и набросать примерный текст. Так проще выстроить логичный сторителлинг и структуру сайта, прежде чем углубляться в детали.

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

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

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

5. Уже на этапе прототипа можно тестировать сайт, как воспринимается информация, насколько легко выполнить целевое действие и т.д.

6. Сначала сфокусироваться на ценности, что, для кого, почему делаем, как должно работать. А потом уже прорабатывать детали.

Итог

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

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

Надеемся, эта статья оказалась для вас полезной. Будем рады, если вы поделитесь в комментариях своим опытом и подходами в дизайне.

Автор статьи: Маргарита Попова

Редактура: Мария Ядрышникова

На основе опыта команд Tourmaline Core.