Разбор концепции приложения по доставке еды

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

Разбор работ в 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, можно подсмотреть:

https://www.figma.com/community/file/1008725738936657843/Agnostic%E2%80%94Typography

Команда

Насколько мой макет в фигма готов для передачи разработчикам?

Этот вопрос больше к разработчикам. Опытные посмотрят на макеты, и сделают по своему, используя встроенные в iOS компоненты. Неопытные будут долго ковыряться. Причина — несоблюдение гайдов платформы. Посмотри в комьюнити какой-нибудь UI-kit для Apple-устройств и сравни со своими компонентами. Увидишь очень большую разницу. Ты можешь возразить: но почему в приложении доставки яндекса своё поле поиска, не похожее на системное? Во-первых, Яндекс может себе позволить несколько кастомных элементов, во-вторых, наверняка эти кастомные поля, панели и прочее построены по принципу существующих в iOs компонентов и имеют те же названия элементов и структуру. У тебя же эти элементы оторваны от реальности, не учитывают состояния и область нажатия.

Пример: поле с поиском и возможность голосового ввода у тебя и в iOs. Разработчикам прозе будет кастомизировать цвет и текст нативного компонента, чем создавать с нуля тот, что нарисован справа

Ты молодец, что собрала UI-kit на отдельной странице, используешь компоненты и варианты. Есть много нюансов, чтобы его ещё больше улучшить:

Использовать цветовые стили. Названы они у тебя корректно, только не занесены в фигму. Кнопки: у тебя все слиты в кашу, а лучше иметь отдельные системные кнопки, отдельные с плюсом и минусом, отдельно с иконкой. Кстати, у тебя в UI-kit есть стили для body 1 и body 2, но в стилях они называются H6 и H7, это собьёт разработчиков с толку.

Ещё одна странность с компонентом карточки: получилась такая карточка швейцарский нож, но это совсем не гибко.

Лучше разделить отдельно: Карточка категории, Баннер, Карточка блюда с состояниями: обычная и добавленная в избранное и так далее.

Про прототип

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

Сам прототип сильно не доработан. Отсутствуют связи между экранами, очень маленькие области нажатия. Рекомендуем тщательнее подходить к этому этапу, так как можно быстрее протестировать взаимодействие с прототипом, причём на настоящих людях (попросить близких и коллег). Тестировать можно отправив ссылку на телефон, либо самостоятельно на устройстве через Figma mirror.

Итого

Какие фундаментальные ошибки допущены в кейсе. Чего не хватает? На что делать акцент в следующем кейсе первостепенно?

Как нам кажется, изначально решаемая проблема была неактуальна, из-за этого приложение кажется неконкурентоспособным. Есть Яндекс, Деливери и другие монстры. Как неизвестному приложению с ними конкурировать? За счёт чего привлекать именитых рестораторов? Как монетизировать приложение, об этом тоже нигде не сказано. Другая фундаментальная ошибка — не использовать готовые UI-kit платформ.

В следующем кейсе рекомендуем не бросаться на всё сразу, а сделать редизайн уже существующего, но устаревшего приложения. Улучшить взаимодействие, протестировать на пользователях, записать результаты. Работодателю интересно не только то, что ты умеешь исследовать и рисовать схемы и макеты, а то, насколько твоя работа эффективна. Для UX это могут быть конкретные метрики: насколько уменьшилось время прохождения флоу, сколько было мискликов и так далее.

Что посмотреть

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

iOS 15 UI Components by Uladzislau Luchkouski

iOS 15 UI Components

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

Успехов в будущих проектах!

Работу разобрали Антон и Лера.

Наш бот Прошка оценил работу так

Читатель! Хочешь такой же разбор от профи? Подписывайся на сервис обучения и поддержки дизайнеров:

https://pro.dsgnline.ru/