Разбор приложения-напоминалки о питье
Разбор работ в 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
Большущая коллекция экранов из игр, в частности экранов с ачивками. Всегда полезно брать вдохновение из соседних областей
Разбор провели Валерия, Антон и Алана
Эй, читатель! Хочешь такой разбор? Подписывайся на сервис обучения и поддержки дизайнеров