Разбор концепции приложения по доставке еды
Посмотрим, к чему может привести неясно сформулированные гипотезы. Почему важно анализировать боли бизнеса и применять гайдлайны платформ.
Разбор работ в DL PRO состоит из двух частей: статьи с анализом, который вы видите ниже и файла в Figma, который передается автору работы с большими подробностями и точечными указаниям на то, что следует исправить.
Автор работы Евгения Кубарева, подписчик DL PRO
Какие ключевые вопросы по работе у тебя есть к менторам?
Цель портфолио - получить оффер на Джуниора. Какие фундаментальные ошибки допущены в кейсе. Чего не хватает? На что делать акцент в следующем кейсе первостепенно?
Задача
Интересует подробный разбор кейса по доставке еды
Спасибо, что поделилась работой. Изначально, по ссылке на презентацию был Notion с описанием исследования, этапами работы и результатом. На момент публикации, ссылка недоступна, поэтому оценивать в разборе будем только присланный фигма файл и презентацию в нём.
Что понравилось в работе
Внушительный объём проделанной работы: исследования, конкурентный анализ, прототипы и презентация.
Что выдаёт меня как новичка
Тебя выдают нюансы: невнимательность к деталям и незнание гайдлайнов платформы, для которой разрабатываешь приложение; незаконченный и негибкий в использовании UI-kit; неконсистентые элементы и типографика. Само решение кажется неработоспособным, но обо всём по-порядку:
Логика
В ходе исследований ты выделила две гипотезы: 1) из-за пандемии стало сложно питаться изысканными блюдами из ресторанов 2) чтобы ресторанам было проще выйти из кризиса, им нужно организовать доставку за МКАД.
Возникает сразу несколько вопросов к гипотезам и задачам:
— Такая доставка уже есть у яндекса и деливери, причём работала она и до ковида. Поэтому проблема кажется надуманной. В чем будет УТП такого сервиса, за счет чего он сможет конкурировать с текущими игроками на рынке?
— Про доставку в пригород: основная проблема заключается в логистике и том, что еда, очевидно, будет холодной. Как решить задачу, без удорожания процесса доставки? Ведь цель — это продержаться на плаву, а значит инвестиции должны быть обдуманы. Плюс это наверняка находится за пределами возможностей проектирования мобильного приложения.
Как надо было подступиться к проверке второй гипотезы? Не уверена в своих решениях
Проблема в том, что у тебя отсутствует там гипотеза как таковая. Что конкретно ты в своей гипотезе собиралась проверить? Какова была цель? Какие метрики ты в это закладываешь, чтобы проверить, подтвердилась она или нет?
А доставка готовой еды за пределы города кажется нам не самой разумной идеей. Что будет с окупаемостью? Будут ли готовы клиенты за это платить, чтобы это было рентабельно для бизнеса? И если и готовы, то каков объём рынка для такого типа услуг?
Бизнес
Если мы говорим о премиум-сегменте пользователей, то самый ограниченный ресурс у них это время, тогда как ты предлагаешь им агрегатор со всеми муками множественного выбора, что с большей долей вероятности приведет к тому, что они не купят ничего.
Перейдём от исследований сразу к решению: сделать вход в приложение без регистрации.
При загрузке пользователю нет необходимости проходить авторизацию, он сразу попадает в основной каталог, который содержит три раздела меню, рассчитанных на разных типов пользователей.
Сомнительное решение, т.к. для получения услуги всё равно нужно указывать адрес и способ оплаты.
Далее, пользователям предлагается выбрать из трёх услуг: заказ еды, заказ наборов для готовки и заказ ингредиентов (если мы правильно поняли). Выбрать уже не просто. Три разных услуги, и непонятно в чем преимущество каждой из них, в каком случае какую выбирать?
Вероятно, в таком случае помог бы онбординг. С его помощью можно рассказать, что есть в приложении и дать пользователю выбрать, что ему актуальнее. На этом этапе также можно собрать предпочтения и персонализировать рекомендации. Проявить заботу. Это сэкономит время выбора и потенциально может повысить лояльность пользователя.
Про онбординг — как можно погрузить пользователя в продукт и надо ли
Лайк и дизлайк в отзывах — это малоинформативно. Бизнесу важно знать более объективную оценку: можно спросить про качество упаковки, если это наборы, или про курьера, а если он опоздал, предложить как-то сгладить ситуацию. Кстати, не нашли в экранах, где можно оставить отзыв и на каком этапе.
Для раздела «Ещё» не отрисованы экраны: Мои адреса, История заказов, Мои карты, хотя они очень важны, чтобы показать логику работы приложения.
Визуал
На первый взгляд, всё оформленно симпатично и «по-дриббловки», но если присмотреться к деталям, станут видны обидные недочёты.
На карточках текст «Новиков групп» и подобные заходят на картинку, лучше добавлять затенение\высветление для контраста, либо разделять текст и картинку. Наглядно об этом написал Илья Бирман в заметке «Текст поверх фотографии»:
https://ilyabirman.ru/meanwhile/all/text-over-photo/
О том же, но на других примерах писал Максим Ильяхов:
https://visual-storytelling.ru/all/text-photo/
Ещё бросается в глаза сжатая типографика, слабый контраст текста в поле поиска, неконсистентность элементов: на главной фото без плашек, тут уже с ними.
Мудборд и референсы
А вот конкурентное исследование клёвое! К нему бы ещё выводы выписать и то, что можно было бы применить в приложении. Было бы очень ценно.
А чтобы логика не страдала, в будущем можно выхватывать не только отдельные экраны приложений конкурентов, но изучать целые флоу и смотреть, как в своём приложении это можно улучшить. Заодно и протестировать и на целевых пользователях, так как восприятие дизайнера не равно опыту потенциального клиента.
Типографика
В проекте добавлены стили текста. Заголовки расписаны до девятого уровня. Как правило, используются до шести уровней, H1-H5 а дальше стили называются по функции: параграф, подпись, кнопка и так далее.
Улучшить подход в выбору шрифта, размеров и цвета поможет это руководство.
Руководство по проектированию улучшенной типографики мобильных приложений
В частности, обрати внимание на совет про платные шрифты. Обычно существует отдельная лицензия для приложений, которая может стоить дороже, чем Desktop или Web-версия. И если это учитывать, то выбор шрифта Mulish для приложения может оказаться неудачным и невыгодным для бизнеса.
Что касается иерархии типографики и названия стилей, ниже пример из Figma Community, можно подсмотреть:
Команда
Насколько мой макет в фигма готов для передачи разработчикам?
Этот вопрос больше к разработчикам. Опытные посмотрят на макеты, и сделают по своему, используя встроенные в iOS компоненты. Неопытные будут долго ковыряться. Причина — несоблюдение гайдов платформы. Посмотри в комьюнити какой-нибудь UI-kit для Apple-устройств и сравни со своими компонентами. Увидишь очень большую разницу. Ты можешь возразить: но почему в приложении доставки яндекса своё поле поиска, не похожее на системное? Во-первых, Яндекс может себе позволить несколько кастомных элементов, во-вторых, наверняка эти кастомные поля, панели и прочее построены по принципу существующих в iOs компонентов и имеют те же названия элементов и структуру. У тебя же эти элементы оторваны от реальности, не учитывают состояния и область нажатия.
Ты молодец, что собрала UI-kit на отдельной странице, используешь компоненты и варианты. Есть много нюансов, чтобы его ещё больше улучшить:
Использовать цветовые стили. Названы они у тебя корректно, только не занесены в фигму. Кнопки: у тебя все слиты в кашу, а лучше иметь отдельные системные кнопки, отдельные с плюсом и минусом, отдельно с иконкой. Кстати, у тебя в UI-kit есть стили для body 1 и body 2, но в стилях они называются H6 и H7, это собьёт разработчиков с толку.
Ещё одна странность с компонентом карточки: получилась такая карточка швейцарский нож, но это совсем не гибко.
Лучше разделить отдельно: Карточка категории, Баннер, Карточка блюда с состояниями: обычная и добавленная в избранное и так далее.
Про прототип
Прототип от финальных экранов слабо отличается. Просто раскрашенные прямоугольники. Обычно в нём закладывается структура, настраивается взаимодействие, а в финале добавляется не просто фото, а другой эмоциональный визуал, детали, готовится нормальный UI-kit со всеми компонентами и вариантами.
Сам прототип сильно не доработан. Отсутствуют связи между экранами, очень маленькие области нажатия. Рекомендуем тщательнее подходить к этому этапу, так как можно быстрее протестировать взаимодействие с прототипом, причём на настоящих людях (попросить близких и коллег). Тестировать можно отправив ссылку на телефон, либо самостоятельно на устройстве через Figma mirror.
Итого
Какие фундаментальные ошибки допущены в кейсе. Чего не хватает? На что делать акцент в следующем кейсе первостепенно?
Как нам кажется, изначально решаемая проблема была неактуальна, из-за этого приложение кажется неконкурентоспособным. Есть Яндекс, Деливери и другие монстры. Как неизвестному приложению с ними конкурировать? За счёт чего привлекать именитых рестораторов? Как монетизировать приложение, об этом тоже нигде не сказано. Другая фундаментальная ошибка — не использовать готовые UI-kit платформ.
В следующем кейсе рекомендуем не бросаться на всё сразу, а сделать редизайн уже существующего, но устаревшего приложения. Улучшить взаимодействие, протестировать на пользователях, записать результаты. Работодателю интересно не только то, что ты умеешь исследовать и рисовать схемы и макеты, а то, насколько твоя работа эффективна. Для UX это могут быть конкретные метрики: насколько уменьшилось время прохождения флоу, сколько было мискликов и так далее.
Что посмотреть
Рекомендуем разобрать пару файлов с компонентами iOS из Figma community. Это позволит в дальнейшем использовать нативные компоненты в макетах и даст понимание, как готовить свои. В частности, так ты сможешь освоить атомарный подход.
https://www.figma.com/community/file/922533165060687529/iOS-15-UI-Components
Про важность нативных компонентов и особенности платформ
Различие в проектировании нативных приложений iOS и Android - UXPUB
Про важность размера кликабельной области в сенсорных интерфейсах
Size matters! Accessibility and Touch Targets
Редизайн приложения Икеи. Хороший пример исследования и тестов. Показывает на реальных цифрах, как UI решения повлияли на пользовательские сценарии.
UI/UX Case Study — IKEA Application Redesign
Работу разобрали Антон и Лера.
Читатель! Хочешь такой же разбор от профи? Подписывайся на сервис обучения и поддержки дизайнеров: