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

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

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

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

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

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

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

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

Figma + Storybook

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

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

О процессе

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

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

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

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

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

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

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

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

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

• Логика и краевые состояния (edge cases) . Пример: есть флоу присоединения Дискорд-аккаунта к сайту. Что будет если человек перейдет на страницу присоединения аккаунта, но затем нажмет кнопку “Отменить”? В таком случае нужно предусмотреть релевантное модальное окно.

• Адаптивность и размеры отступов (паддинги и марджины) . Делается это с помощью режима разработчика. Тут дизайнеру нужно минимально знать HTML/CSS, чтобы, если нужно, внести правки и приложить скриншот к комментарию.

• Состояния компонентов: hover, active, disable, focus.

• Типографика. Проверяю с помощью плагина Font Ninja. Очень удобная тулза.

• Цвета. Либо на глаз, либо через режим разработчика.

• Контент. Правильно ли написаны тексты в интерфейсе и ничего не упущено.

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

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

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

Пробуем Live-coding

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

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

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

• Можно сравнить результат работы в редакторе и в проде;

• Улучшение коммуникации между дизайнерами и разработчиками;

• Понимать результат своей работы;

• Прокачиваться в HTML/CSS. Понимать ограничения разработки

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

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