Как быстро и экономно тестировать гипотезы в условиях кризиса

Как быстро и экономно тестировать гипотезы в условиях кризиса?

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

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

Почему прототип лучше статичной карты экранов со стрелочками

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

Статичный дизайн — это набор картинок, где все экраны приложения соединены стрелками с подписями действий. Это карта экранов, но она не позволяет «пощупать» результат и понять, насколько будет удобен интерфейс. Она менее наглядна.

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

После дизайна делается кликабельный прототип. В зависимости от нужд клиента можно сделать прототип разной степени проработки: low-fidelity и high-fidelity.

Low-fidelity — прототип из статичных изображений, с активными ссылками на следующие экраны на кнопках. 

High-fidelity — прототип, который почти не отличается от приложения, имеет полный интерактив: в поля ввода можно вводить любой текст, есть анимация, переходы между экранами, иногда даже подключены расчеты. 

Прототип лучше, чем карта экранов, объясняет процессы в приложении благодаря «погружению». Если использовать карту экранов в большом проекте, то она превращается в лабиринт, в котором сложно перемещаться и видеть логику приложения. А в прототипе внимание уделяется каждому экрану по очереди: заказчик или разработчик просто кликает по кнопкам, как будто это полноценное приложение, и ему все становится понятно. В итоге разработчик и заказчик получают наглядный пример необходимого результата, и им будет понятнее поведение элементов в разных ситуациях. Тогда большая часть вопросов по UX будет закрыта еще до старта разработки.

В каких случаях одним прототипом не обойтись... И нужны будут несколько!

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

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

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

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

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

В прототипе приложения Russia Running можно протестировать весь интерфейс: кнопки, выпадающее меню, поиск, фильтры и календарь

Почему при реализации пишется код вручную, а не генерируем из прототипа

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

Но у сгенерированного кода есть следующие проблемы:

1. Прототип не отображает, какие данные и откуда нужно брать для работы с бэкендом: программисту все равно придется это прописывать.
2. Программа генерирует не самый оптимальный код, и на то, чтобы сделать его читаемым и оптимизированным, тратится столько же времени, сколько на создание аналогичного кода с нуля.
3. Сложно, а иногда невозможно подстроить свой дизайн и идеи под ограничения приложений-генераторов.

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

Как же прототип выручает при создании приложения

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

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

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

Снижает риски на этапе разработки. На этапе выявления требований можно довольно быстро собрать wireframe-прототип, чтобы точно не пропустить ничего важного в навигации и функциональности проекта. Разработчик будет знать, как должна работать каждая кнопка и экран будущего приложения. Если что-то не получится сделать или потребует определенных технологий, это станет ясно до начала разработки.

А собранный на этапе дизайна high-fidelity-прототип помогает делать ревью дизайна и легко находить и исправлять логические и композиционные ошибки в UI-дизайне.

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

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

Например, когда high-fidelity-прототип готов, QA-специалисты уже могут начинать готовить множество тест-кейсов для дальнейшей проверки приложения, пока его разрабатывают.

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

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

Всегда ли нужен прототип

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

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

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