Как создают дизайн приложения. От Уих и до Уи

Привет! Эта статья — ответ на вопрос — а как же мать его, создают приложения?

И я понимаю вопрошающего — заблудиться в построении приложении — проще простого, особенно, когда любители позадроствовать начинают сыпать терминами User-Flow, Customer Development, Юнит-экономика и т.д.

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

В этой статье я буду опираться на процессы, описанные в трекшн-карте от ФРИИ. Я считаю, что любой хороший дизайнер (а ты — хороший дизайнер?) должен понимать не только свой процесс, связанный с разработкой интерфейса приложения, но и весь процесс создания и продвижения приложения от самого зачатка (идеи) и до конца (масштабирования). Где-то у меня самого присутствуют белые пятна в плане отсутствия понимания внутренних процессов, но это дело наживное.

Как бы сказал Гагарин — Поехали! Постараюсь быть кратким.


Фаза 1. Исследования

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

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

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

Для этого мы можем самостоятельно тыкать в чужие приложения, а может и устроить ИНТЕРВЬЮ.

ПРОЦЕСС 1. ИНТЕРВЬЮ

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

Интервью помогает нам на этапе 3 Customer Development, выяснить действительно ли такая проблематика существует.

К примеру, я активно пользовался трекерами привычек, и меня всегда парило, что я не могу в большинстве из них указывать время или количество (чего-то), а только делал ли я что-то или нет.

Теперь у меня есть идея — я хочу сделать приложение по учёту привычек, которое помимо стандартных крестиков и галочек (зачеркни 10 дней в ряд) будет учитывать также и время или количество. К примеру, если мы говорим о времени — то мы можем указать условие — подъем с 5 до 6 утра, и по пробуждению вносить это время в трекер. Если время НЕ с 5 до 6 утра, то привычка на сегодня провалена. Или делать более 100 отжиманий в день, если я вношу за день менее 100 в графе "Отжимания", то привычка на сегодня провалена.

Но это моя проблематика, которую я ещё не подтвердил. Для этого я буду использовать интервью.

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

Давай поясню:

1) Хотите ли вы в трекере иметь возможность учитывать не только галочки, но и крестики? Ответ может звучат как да, так и нет, но на деле это не даст нам ответа на вопроса — а нужно ли вам новое приложение с такой функцией. Вполне возможно, что это фича будет слишком незначительна, и люди попросту будут пользоваться старым приложением с галочками. Это — вопрос-предположение.

2) Ведёте ли вы учет привычек? Где вы ведёте учёт привычек? Какие приложения вы использовали? Что вам понравилась в этих приложениях? Что вам не понравилась в этих приложениях? Это уже вопросы, касаемые опыта. Именно они дадут нам ответ на все поставленные нами вопросами.

Как вести интервью? В идеале, это нужно делать лично с человеком. Но если такой возможности нет (а её часто нет) — то стоит провести такой опрос хотя бы в гугл-формах.

Фаза 2. Создание ТЗ и первые наброски

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

Здесь уже начинается реальная работа UX/UI дизайнера и продакта в их "прямых ролях".

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

Для простоты, Beta — это уже почти MVP, который ещё не протестирован небольшой выборкой пользователей, и может содержать в себе ошибки и несостыковки. Тестирование бетки как раз показывает нам все косяки приложения, которые мы можем оперативно устранить. В ветке Current мы можем держать текущие фичи, которые уже имплементированы. Бэклог (backlog) — это набор фич, которые ХОРОШО бы внедрить в приложение, но пока в этом нет смысла и особой рациональности. Или она есть, но прямо сейчас эта функция не критична.

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

Изначально же, ещё на стадии MVP, нужно и продумать возможную монетизацию приложения. То есть то, как мы будем получать деньги от клиентов. Об этом нужно думать сразу — потому как если ты выпустишь приложение, которое сразу выполняет все функции, то можешь и обосраться — потому что забыл повесить монетизацию. К примеру нашего приложения, можно повесить монетизацию на ограничение количества привычек до 4. То есть максимум 4 привычки, всё что больше — уже за финансы.

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

ПРОЦЕСС 2. Роли

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

ПРОЦЕСС 3. User-Stories и User Flow

Юзер-стори и юзер-флоу — это описание процесса для выполнения цели пользователем.

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

Но давай не будем путать мозги, и сразу перейдём к примерам:

Юзер-стори для нашего приложения.

Кейс: пользователь хочет вести учёт привычек — 100 отжиманий, каждый день.

История: пользователь регистрируется в приложении (если ранее не зарегистрирован) с помощью социальных сетей или электронной почты. Если он использует электронную почту, то подтверждает регистрацию через почту. Пользователю объяснено, что регистрация нужна для синхронизации привычек с этим аккаунтом. Если же пользователь понимает, что синхронизация ему не нужна — то он её пропускает и данные хранятся только в телефоне. Также он может зарегистрироваться в любой момент, при этом привычки в телефоне сохранятся и синхронизируются с аккаунтом. После регистрации или входа пользователь переходит на вкладку "Привычки", нажимает на плюс, вводит название привычек, количество раз повторений, выбирает что хочет учитывать это всё в цифрах, сохраняет. Привычка создана, история окончена.

Юзер-Флоу

Юзер-флоу является продолжением утверждённой и подтвержденной юзер-стори, которая изображает точно тот же процесс, но уже схематично. Для его создания в интернете есть куча инструментов, из них я бы выделил https://flowmapp.com/ и https://whimsical.com/a.

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

Вот как выглядит образцово-показательный юзер-флоу:

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

Процесс 4. User Journey Map

Ещё один инструмент в арсенале дизигнера — это Юзер джорни мап, или карта путешествия клиента. Рассказывать о ней не буду, потому что уже было здесь: https://ux-journal.ru/chto-stroit-v-pervuyu-ochered-user-journey-map-ili-user-flow.html, да и откровенно говоря ни разу не составлял потому что не было особо нужно.

Фаза 3. Создание прототипа

На этом этапе дизигнер создаёт уже настоящее приложение, в которое можно потыкать, исходя из user-flow и user journey map.

Процесс 5. Вайрфреймы

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

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

Для создания wireframes можно использовать как специальные тулзы типа Axure (очень полезно при создании веб-приложений), либо просто рисовать низко-детализированные прототипы в Figma/Sketch и связывать их там же в Figma или с помощью Invision/Marvel. А можно и вообще на бумаге рисовать и соединять через POP.

Процесс 6. Высоко-детализированные прототипы

Это то, о чём в курсе как раз все — это создание финальных макетов в Фихме/Скетче, или где ещё угодно.

Не забываем, что после создания макетов дизайнер обязательно должен сопроводить макеты "спецификацией", то есть UI Kit,  который показывает все возможные состояния элементов при: наведении курсора, потере фокуса, приобретении фокуса, нажатии, и так далее. Хороший образец для создания UI Kit — это контур.Гайды https://guides.kontur.ru/, которые очень хорошо демонстрируют, какие могут быть состояния у различных элементов.

Фаза 4. Программирование и создание MVP

Это для меня — откровенно тёмный лес, особенно на стадии бэкенда. На стадии фронта я советую каждому изучить основы вёрстки и поверстать немного самому — хотя бы используя связку HTML/CSS/jQuery, а потом и с помощью препроцессоров типа GULP.

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

Фаза 5. Получение фидбэка

Ура-ура, мы добрались наконец до той фазы, где у нас начинаются первые скачивания нашего суперприложения. После скачивания неизменно польётся фидбэк — то есть обратная связь. Это могут быть запросы в техподдержку (их стоит изучить), отзывы от пользователей на почте или например в Маркете или Апп Сторе. Исходя из них, нужно выяснить узкие места и самую большую боль — и разработать её и имплементировать в проект. На этом этапе мы получаем фидбэк, делаем первые продажи (или не делаем, что тоже интересно), и начинаем весь процесс, но уже по улучшению действующего продукта.