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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А как у вас с прототипами? Помогали ли они ускорить разработку и сделать программистов счастливее? Делитесь в комментариях!

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

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

Подписывайтесь на наш телеграм-канал, чтобы не пропустить!