Дизайн-ревью. Внедряем новый процесс

Всем привет! Меня зовут Артем Суслов. Я работаю продуктовым дизайнером в стартапе Playdex и в данной статье я хочу рассказать про процесс дизайн-ревью, который у нас выстраивается в компании.

Мы создаем маркетплейс для аренды NFT для Web3 игр, ориентированный на рынок Филиппин, но целимся и на всю Азию.

Дизайн-ревью. Внедряем новый процесс

Перед началом

Тяжело предположить, кто будет читать эту статью — опытные IT-шники или же новички в сфере, но в любом случае хочу привести несколько понятий, которые сделают данный материал доступнее:

  • Продакшн (прод) — то, что видит пользователь при переходе на сайт.
  • Тестовый стенд — это среда в которой проводятся конечные тесты перед внедрением в продакшн.
  • Пул реквест (Pull request, PR) — функция, c помощью которой разработчик может внедрить или изменить что-либо в проекте без влияния на остальной код. Пул реквест проходит ревью, после чего отправляется на тестовый стенд и затем в продакшн.
  • Превью — режим просмотра для того, чтобы протестировать насколько верно внедрена фича.

Почему внедрили процесс?

Когда я пришел в продукт и передал в верстку первые макеты — пришлось испытать не очень приятные эмоции после увиденного результата. Цвета, типографика, отступы, поведение компонентов сильно отличались от того, что было в макетах. С этим нужно было что-то делать и возникла ожидаемая идея внедрить процесс дизайн-ревью.

Данный процесс полезен для будущего всей команды, так как он улучшает коммуникацию между разработчиками и дизайнерами.

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

Figma + Storybook

Для того, чтобы наш продукт выглядел консистентным и единым, мы начали с создания сборника компонентов в Фигме и переноса их в Storybook. В приоритете были кнопки, инпуты и пагинация так как они наиболее часто использовались в текущем интерфейсе.

Storybook — это сервис для разработки переиспользуемых UI-компонентов. Он позволяет взаимодействовать и тестировать их до внедрения в продакшн. Важно отметить, что при изменении компонента в Storybook он изменится и в проде после деплоя. Инициатива принадлежит нашему ультра-фронтенд-разработчику — Мише, за что ему огромный респект.

О процессе

Оформление задачи

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

Также можно описать все свои задумки и поведение компонентов при скроле, адаптивности. Если есть анимации — желательно приложить референсы. В общем, постараться ответить на все возможные вопросы разработчика заранее.

Но если все же требуется — мы созваниваемся с разработчиком, который делает данную задачу и обсуждаем нюансы. Возможно, внедрение анимации в данной задаче может занять долгое время, а так как мы работаем в стартапе — в приоритете скорость разработки. Поэтому все, что не успели сделать в текущей задаче — закидываем в бэклог. Главное, лучше это делать сразу, иначе потом будет тяжело вспомнить, что не успели сделать.

Дизайн-ревью

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

Vercel — это облачная платформа для размещения фронтенд-приложений и статических веб-сайтов. Одной из самых крутых фичей является возможность оставлять комментарии к конкретному компоненту или части интерфейса в превью.

Благодаря этому, не нужно коммуницировать в личных чатах (что пока не всегда получается) и все остальные разработчики видят комментарии.

Так выглядят комментарии в Vercel
Так выглядят комментарии в Vercel

Что проверять?

  • Логика и краевые состояния (edge cases) . Пример: есть флоу присоединения Дискорд-аккаунта к сайту. Что будет если человек перейдет на страницу присоединения аккаунта, но затем нажмет кнопку “Отменить”? В таком случае нужно предусмотреть релевантное модальное окно.
  • Адаптивность и размеры отступов (паддинги и марджины) . Делается это с помощью режима разработчика. Тут дизайнеру нужно минимально знать HTML/CSS, чтобы, если нужно, внести правки и приложить скриншот к комментарию.
  • Состояния компонентов: hover, active, disable, focus.
  • Типографика. Проверяю с помощью плагина Font Ninja. Очень удобная тулза.
  • Цвета. Либо на глаз, либо через режим разработчика.
  • Контент. Правильно ли написаны тексты в интерфейсе и ничего не упущено.

Последующие итерации

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

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

Пробуем Live-coding

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

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

Итого. Для чего нужно дизайн-ревью?

  • Можно сравнить результат работы в редакторе и в проде;
  • Улучшение коммуникации между дизайнерами и разработчиками;
  • Понимать результат своей работы;
  • Прокачиваться в HTML/CSS. Понимать ограничения разработки

--------------------------

Спасибо, что прочитали данный материал. Надеюсь, он был полезен!

Подписывайтесь на мой Телеграм-канал. Я выкладываю личные находки и интересные материалы относящиеся к дизайну интерфейсов.

1919
2 комментария

Мне немного сложно поверить, что в стартапе вы сразу за месяц ввели и отточили новую ступень процесса перед релизом, но я благоговейно вам апплодирую, если это правда :)
Спасибо за конкретику в описании программ и за краткие определения! Не нужно отвлекаться на гугление, все описано.

1

Мы еще не до конца отточили, но уже близки к этому точно. Спасибо за фидбек)