🪧

Visual QA или пойдем проверим

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

Основные принципы

Приемка должна происходить один раз в спринт.

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

В первую очередь вам нужно сформировать понимание на основе чек листов, задачек или беклогов, список реализованных фич за неделю и сколько экранов вам нужно посмотреть.

В случае если у вас нет iOS или Android устройства, можно обратиться к эмуляторам или browserstack

Фиксация

Для фиксации расхождений между дизайном и уже выполненной работой разработчика, лучше вернуться в софт где мы делали дизайн, в нашем случае это фигма. Далее создаем отдельный файлик, назовем его например “Review”, а внутри страничку обозначающую итерацию этого самого ревью. Это может быть дата, или номер спринта, ориентируетесь на свою компанию и ваши процессы что бы не путаться в дальнейшем.

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

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

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

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

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

Разберем на практике

На схеме мы видим несколько элементов:

  1. Имя раздела - для нас это опознавательная точка как и для разработчика. Мы можем указать например “Авторизация” и разработчик сразу понимает какого раздела это касается. Например если у вас две корзины на проекте (да-да и такое бывает), то это здорово может сократить время разработчику.
  1. Platform - lалее мы создаем секции с именем платформы (если их несколько), это могут быть iOS, Android, web и любая ваша платформа. Если у вас всего одна платформа, то оказывать разумеется не обязательно.
  1. Экраны - тут самое вкусное, слева располагаем экраны с ошибкой, слева копируем правильный экран (что бы разработчик не бегал в поисках нужного ему экрана)
    1. Между экранами пишем комментарий, у каждого комментария можно установить статус (сделайте окошко с комментом компонентом что бы не париться с ним). Мы используем статусы:
      1. Открытый вопрос (фиолетовый) - например мы не понимаем почему заголовок разный “добро пожаловать” и “вход”. Но там есть какие-то изменения которые прошли мимо вас. В зависимости от ответа, мы сможем понять что делать дальше, отправить на доработку, изменить нам в макетах или например эти изменения будут в следующем спринте.
      1. Желательно (оранжевый) - что-то не критичное, например если что-то отличается на разных платформах, с одной стороны желательно поменять, а с другой вообще не критично, ибо это больше эстетическая хотелка без особой пользы для пользователя.
      1. Критично (красный) - это прямо косяк отображения который нужно исправить обязательно, цвет съехал, пропал кусок сценария, кнопка потерялась, шрифт отображается не корректно и т. д.

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