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