Всем привет! Меня зовут Артем Суслов. Я работаю продуктовым дизайнером в стартапе 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. Понимать ограничения разработки
Спасибо, что прочитали данный материал. Надеюсь, он был полезен!
Подписывайтесь на мой Телеграм-канал. Я выкладываю личные находки и интересные материалы относящиеся к дизайну интерфейсов.
