Создание прототипа приложения за 5 дней

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

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

Определение дизайн-спринта

В общем плане спринт — это определённый период времени, в течение которого команда разработчиков или дизайнеров (иногда всех вместе) выполняет какой-то объём работы. Он применяется в методологии Agile. Обычно сроки спринта составляют от 5 до 15 дней.

5-дневный дизайн-спринт — это процесс ускоренного проектирования и тестирования на основе Agile-спринта. Концепцию придумал дизайнер Джейк Кнапп в 2010 году, когда работал в Google. В 2012 году он перешёл в венчурный фонд GV (ранее Google Ventures), для которого доработал концепцию. С тех пор они используют дизайн-спринт для решения проблем стартапов за 5 рабочих дней таким образом:

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

ИТ-компании переняли наработку Кнаппа и применяют, чтобы проверять предположения, пробовать идеи и получать анализ перед созданием цифровых продуктов, таких как мобильные и веб-приложения. Цель дизайн-спринта в ИТ — создать 3-4 кликабельных прототипа, протестировать их на юзабилити, а затем выбрать и доработать 1-2 окончательных прототипа.

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

День 1: разработка идей и стратегии

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

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

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

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

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

День 2: расхождение и схождение

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

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

• Безумные восьмёрки — упражнение по созданию набросков. Коллеги должны набросать 8 разных идей за 8 минут. Цель — выйти за рамки первой очевидной идеи и расширить диапазон решений. Достаточно делать грубые наброски без углубления в детали, чтобы побыстрее передать идеи. Упражнение помогает придумать несколько идей интерфейса.
• Карты потоков — упражнение по представлению потока продукта. Коллеги должны начать с первого взаимодействия пользователя с приложением и разветвить все возможные потоки, в которые может погрузиться пользователь. Упражнение помогает построить разные сюжетные линии вокруг приложения.

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

• От 8 к 4 и к 2 — упражнение по доработке идей из «безумных восьмёрок». Сначала 15 минут коллеги дорабатывают 4 из 8 идей, потом ещё 15 минут дорабатывают детальнее 2 из этих 4 идей.
• Магический график — упражнение по представлению графика соотношения потребностей и усилий. Коллеги рисуют на оси X оценку потребности по шкале от 1 до 10, а на оси Y — оценку усилий по шкале от 1 до 10. Затем строят график всех идей, которые появились на этапе расхождения. Самыми успешными будут те, что имеют высокую потребность и низкие усилия.

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

День 3: построение каркасов и создание прототипов

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

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

Когда есть время, можно переносить каркасы в Balsamiq Wireframes, Miro или Mockplus, либо превращать их в прототипы с помощью CanvasFlip, Figma или InVision. Как только прототипы готовы, группы делятся ими друг с другом. Тестирование этих прототипов различными членами команды помогает подтвердить поток прототипа.

К концу дня мы обсуждаем прототипы и инсайты пользовательского опыта, которые собрали в результате тестирования на своей команде. UI- и UX-дизайнеры высказывают мнения по каждой детали. Таким образом, остаются два прототипа, подготовленные к доработке и тестированию на юзабилити.

День 4: доработка прототипов

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

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

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

День 5: подтверждение в ходе тестирования

Последний день мы посвящаем дискуссиям, размышлениям и ответам. Они появятся после тестирования прототипа на реальных пользователях. Если предыдущий день завершили с двумя прототипами, то разделяем пользователей на две группы и тестируем каждый прототип на одной группе. Такое A/B-тестирование даёт точные результаты.

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

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

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