Сегодня поговорим о том как искать ошибки в интерфейсе, которые неизбежно появляются при проектировании фичи.
Зачастую они возникают в следствии кропотливого труда и большой фичи, а также при плохом анализе и виденье конечного результата.
И так что же делать, чтобы проектировать интерфейс качественней и отлавливать все возможные ошибки при его проектировании, которые могут повлиять на time to market и уменьшить скорость разработки фичи.
Разрабатывая технологическую платформу мы, часто, применяем userstory для того, чтобы продемонстрировать дизайн решение фичи, а также поиск возможных ошибок при проектировании интерфейса.
У нас есть отдельный проект в Figma, где мы подготавливаем и демонстрируем макеты при защите дизайн решения перед руководителем.
Приведу пример как userstory выглядит.
Над сбором макетов и последующем построением userstory работают два человека. Как правило, дизайнер и системный аналитик. Роли распределяются между ними следующим образом. Дизайнер собирает userstory, а системный аналитик описывает каждый шаг пользователя и поведения интерфейса. При этом они совместно находятся на связи и общаются между собой. При таком тандеме дизайнер и системный аналитик могут найти и исправить большое количество багов, которые могут быть выявлены в ходе подготовки userstory к защите дизайн решения. Также может дизайнер в одиночку готовить макеты для показа, но в группе это проще и быстрее чем в одиночку.
При подготовке макетов к защите мы у нас есть определенные правила, которыми мы руководствуемся. Расскажу о них по подробней.
Любое userstory начинается с роли, под которую проектируется интерфейс будущей фичи. Это нужно для того, чтобы сфокусировать всех участников встречи на определенную роль в данный момент и потом самому не запутаться под какую же роль был спроектирован интерфейс. Так же эта роль помогает при демонстрации дизайн решения смежным командам.
От роли отводится стрелка на стартовую страницу процесса для этой роли. Не рекомендуется всегда начинать userstory прям с самой страницы авторизации из за большого количества макетов, этот процесс мы выносим за скобки. Для примера я покажу процесс регистрации и авторизации.
Между экранами всегда пишется информация, о том что пользователь с соответствующей ролью делает на предыдущем экране. В описании, которое находится с иконкой ”i”, мы пишет более подробно, что должно произойти на следующем экране и любую другую полезную информацию, чтобы при проказе, все дополнительные вопросы касательно реализации закрывались сами собой. Важная информация имеет красный цвет и помечается иконкой “!”.
Причем описание может быть большое мы никак не ограничиваем его длину, главное чтобы было понятная сама концепция и были закрыты все возможные вопросы при демонстрации дизайн решения.
При написании информации между экранами, мы используем наименование роли или нескольких ролей в зависимости от того, для кого конкретно разрабатывается фича. От лица роли мы описываем шаги, дальнейшие действия и дополнительную информацию.
А так при подготовке макетов к демонстрации, в userstory добавляются макеты с дополнительными действиями и состояниями. Для того чтобы все участники встречи видели все возможные действия, с которыми будет необходимость работать пользователю.
При подготовке макетов выбирается цвет, чаще мы используем черный, для отображения целевого сценария. Дополнительные цвета мы отображаем для того, чтобы показать другие не целевые сценарии, которые есть в процессе.
Остальные цвета задаются на усмотрения дизайнера. Также при большой развилки дизайнер добавляет метку с названием сценария. Различные цвета служат, чтобы проще было концентрировать внимания при демонстрации сценария.
Красный цвет линий мы используем для того, чтобы показывать деструктивных операций, например удаление.
Расстояние между макетами мы делаем 2000px и придерживаемся сеточного позиционирования макетов.
Я, чаще, использую плагин для Figma — Autoflow. Также у меня в команде дизайнеры используют стрелочки из FigmaJam. Мы никак не регламентируем, что использовать, главное чтобы было комфортно и быстро готовить макеты для презентации дизайн решения.
Такой подход помогает находить и презентовать дизайн решения с минимальным количеством ошибок и получить глубокую проработку будущей фичи. Попробуйте, и ваши интерфейсы улучшаться, а команда разработки скажет вам спасибо.
Подготовил маленькую библиотеку, для оптимизации времени при построении userstory.
Error handling this external URL
Зачастую они возникают в следствии кропотливого труда и большой фичи, а также при плохом анализе и виденье конечного результата.
И так что же делать, чтобы проектировать интерфейс качественней и отлавливать все возможные ошибки при его проектировании, которые могут повлиять на time to market и уменьшить скорость разработки фичи.
Разрабатывая технологическую платформу мы, часто, применяем userstory для того, чтобы продемонстрировать дизайн решение фичи, а также поиск возможных ошибок при проектировании интерфейса.
У нас есть отдельный проект в Figma, где мы подготавливаем и демонстрируем макеты при защите дизайн решения перед руководителем.
Приведу пример как userstory выглядит.
Над сбором макетов и последующем построением userstory работают два человека. Как правило, дизайнер и системный аналитик. Роли распределяются между ними следующим образом. Дизайнер собирает userstory, а системный аналитик описывает каждый шаг пользователя и поведения интерфейса. При этом они совместно находятся на связи и общаются между собой. При таком тандеме дизайнер и системный аналитик могут найти и исправить большое количество багов, которые могут быть выявлены в ходе подготовки userstory к защите дизайн решения. Также может дизайнер в одиночку готовить макеты для показа, но в группе это проще и быстрее чем в одиночку.
При подготовке макетов к защите мы у нас есть определенные правила, которыми мы руководствуемся. Расскажу о них по подробней.
Правило №1
Любое userstory начинается с роли, под которую проектируется интерфейс будущей фичи. Это нужно для того, чтобы сфокусировать всех участников встречи на определенную роль в данный момент и потом самому не запутаться под какую же роль был спроектирован интерфейс. Так же эта роль помогает при демонстрации дизайн решения смежным командам.
Правило №2
От роли отводится стрелка на стартовую страницу процесса для этой роли. Не рекомендуется всегда начинать userstory прям с самой страницы авторизации из за большого количества макетов, этот процесс мы выносим за скобки. Для примера я покажу процесс регистрации и авторизации.
Правило №3
Между экранами всегда пишется информация, о том что пользователь с соответствующей ролью делает на предыдущем экране. В описании, которое находится с иконкой ”i”, мы пишет более подробно, что должно произойти на следующем экране и любую другую полезную информацию, чтобы при проказе, все дополнительные вопросы касательно реализации закрывались сами собой. Важная информация имеет красный цвет и помечается иконкой “!”.
Причем описание может быть большое мы никак не ограничиваем его длину, главное чтобы было понятная сама концепция и были закрыты все возможные вопросы при демонстрации дизайн решения.
Правило №4
При написании информации между экранами, мы используем наименование роли или нескольких ролей в зависимости от того, для кого конкретно разрабатывается фича. От лица роли мы описываем шаги, дальнейшие действия и дополнительную информацию.
Правило №5
А так при подготовке макетов к демонстрации, в userstory добавляются макеты с дополнительными действиями и состояниями. Для того чтобы все участники встречи видели все возможные действия, с которыми будет необходимость работать пользователю.
Правило №6
При подготовке макетов выбирается цвет, чаще мы используем черный, для отображения целевого сценария. Дополнительные цвета мы отображаем для того, чтобы показать другие не целевые сценарии, которые есть в процессе.
Остальные цвета задаются на усмотрения дизайнера. Также при большой развилки дизайнер добавляет метку с названием сценария. Различные цвета служат, чтобы проще было концентрировать внимания при демонстрации сценария.
Красный цвет линий мы используем для того, чтобы показывать деструктивных операций, например удаление.
Правило №7
Расстояние между макетами мы делаем 2000px и придерживаемся сеточного позиционирования макетов.
Какие инструменты мы используем
Я, чаще, использую плагин для Figma — Autoflow. Также у меня в команде дизайнеры используют стрелочки из FigmaJam. Мы никак не регламентируем, что использовать, главное чтобы было комфортно и быстро готовить макеты для презентации дизайн решения.
Какие плюсы такого подхода?
- Быстро находятся проблемы и недочеты, которые были упущены во время проведения аналитики и проектирования интерфейса;
- Удобно демонстрировать дизайн решение руководству или коллегам из смежных команд;
- Удобно демонстрировать дизайн решение команде;
- Такая карта помогает разработчикам проследить весь путь пользователя и понять его особенности, а также разработчики лучше понимают детали фичи;
- В любой момент можно вернуться к старым макетам и освежить память о разработанной функциональности;
- Все необходимые состояния интерфейса находятся близко к связанному с ним экрану.
Какие минусы такого подхода?
- Нужно закладывать время на подготовку макетов для презентации. Подготовил маленькую библиотеку компонентов;
- Нужно отвлекать сотрудников для помощи в подготовке;
- Переделки в ходе получения комментариев во время презентации;
- Требуется определенный уровень, чтобы собирать макеты быстро и писать описание.
Такой подход помогает находить и презентовать дизайн решения с минимальным количеством ошибок и получить глубокую проработку будущей фичи. Попробуйте, и ваши интерфейсы улучшаться, а команда разработки скажет вам спасибо.
Полезная ссылка
Подготовил маленькую библиотеку, для оптимизации времени при построении userstory.
Error handling this external URL
You do not have permission to view link please Вход or Регистрация
