Разбор приложения-напоминалки о питье

Разбор работ в DL PRO состоит из двух частей: статьи с анализом, который вы видите ниже и файла в Figma Jam, который передается автору работы с большими подробностями и точечными указаниям на то, что следует исправить.

Автор работы Катя Селиверстова, подписчицы DL PRO

Ссылка на беханс, как первый подход к задаче

Пример экранов из рабочего макета

Привет, Катя! Мы изучали не кейс на беханс, а рабочий файл в фигме. Он тебя неплохо организован: на отдельных страницах исследование, мудборд и прототипы. Пройдёмся по каждой странице и дадим наши заметки по четырём критериям для полной объективности: Логика, Визуал, Бизнес и Команда как мы это делаем для рейтинга

Первая страница посвящена исследованию

Исследования

Общее замечание по логике — непонятно, чем отличается приложение от конкурентов, каковы ограничения.

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

Исследуемый сегмент: активно пользующиеся телефоном люди 15 — 50 лет. Такого нет. Вот как подбирать https://habr.com/ru/company/mailru/blog/304720/

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

Стоит выделить вывод из составленных гипотез, чтобы работодателю и тебе было проще в них разобраться, чтобы с ними можно было дальше работать.

Сделать блок “Использованные метологии” и сразу их там перечислить, например: JTBD, CJM, глубинные интервью.

В каждом блоке исследований нет вывода. Рекомендуем для визуализации использовать фактоиды. Например: 9 респондентов, 2 гипотезы составлено, и так далее

Мудборд и референсы

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

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

Прототипы

В прототипах прописывай сценарий, а не название сущностей. Например, «пользователь проходит онбординг», «пользователь настраивает уведомления» Ты понимаешь, что работаешь с процессами, но при подходе со сценариями, ты продумаешь больше нюансов, которые могут непосредственно влиять на пользовательский опыт, учтешь крайние состояния (ошибки). Например, у тебя есть сущность Articles и показана она только в одном базовом состоянии. А что пользователь будет делать с этой статьей? Делиться, добавлять в избранное? Тут очень пригодилась бы методология JTBD.

Рекомендуем названия экранов тоже нумеровать, чтобы они логически складывались в последовательности. Например, можно нумеровать — можно делать основной и альтернативный флоу, экран 1.1 — все ок, 1.2 — ошибка с инетом, 1.3 — инет пашет, а сервис нет и т.д.

1.1 Main
1.2 Main - empty
1.3 Main - Internet No
1.4 Main - Internet Yes Server No


Есть вариант нумеровать “в тупую” (простой) вообще не привязываясь к логике — идеально подходит, если тебе нужно, чтобы разраб и ты могли ссылаться на номер макета, а сами экраны у вас связаны стрелками (плагин Autoflow).

Самое важное:

Понимать, зачем эта нумерация нужна. Это основной инструмент взаимодействия в команде внутри дизайнеров и передачи экранов разработчикам. Главное - чтобы все участники процесса понимали, как это работает. Названия: всегда должна быть связка (название экрана + стейт)

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

В графике ачивок нарушена консистентность. Цифры жирные, иконки — нет. Имело смысл больше поработать над этим экраном, поскольку его пользователи будут дольше рассматривать

Попробуй спроектировать еще несколько состояний этого экрана — возможно все поедет

Компоненты

В UI-kit лучше использовать вместо H1-H5 название шрифта, размер и межстрочное. Например: Gilroy, 54/46px

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

Правильно используете варианты и компоненты. И видно, что не выдумываете компонентов, которых нет в HIG. Но всё-равно рекомендуем пройтись по всем компонентам и удалить лишние фоны, проверить не будут ли элементы пересекаться. Это исключит многие ошибки при передаче макетов. Идеально найти разработчика и показать им макеты. А ещё, попробуйте купить платный UI-kit и поковыряться в нём

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

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

Остальные страницы

Не поняли необходимости страницы WatchOS.

На страницах Home page drafts и draft черновики и наброски. Скетчи это хороший артефакт, чтобы показать его в кейсе.

Что можно улучшить

Сразу надо сказать, что ваш ментор — молодец. В кейсе на беханс много проблем с логикой и визуалом. Новый проект в фигме демонстрирует исследования, работу с компонентами, глубокое погружение. Совершенно иной уровень! И нужно продолжать в этом же направлении. Однако, так как с этим проектом вы уже прошли два этапа, он мог вам надоесть. Поэтому советуем оформить этот кейс в простом формате на notion и расписать про исследование. А для кейса на беханс придумать новое приложение и учесть при его проектирование то, что мы вам посоветовали: ограничение, правильная сегментация пользователей, использование сценариев в прототипах.

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

Ещё раз соберём все ссылки в одном месте:

https://habr.com/ru/company/mailru/blog/304720/
Тонкости подбора респондентов для UX-исследований

https://growth.design/
Разбор продуктовых кейсов на реальных примерах в виде комиксов

https://www.gameuidatabase.com/index.php?&scrn=82&set=1&plat=1
Большущая коллекция экранов из игр, в частности экранов с ачивками. Всегда полезно брать вдохновение из соседних областей

Удачи!

Разбор провели Валерия, Антон и Алана

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

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

https://pro.dsgnline.ru/