Comments 6
Очень полезно, спасибо!
Хорошая статья! Важная мысль, что дизайнер тоже может влиять на процессы в компании, чтобы более эффективно работать)
Описывайте в формате действия с параметрами что на что исправить. Например, вы заметили, что отступ после шапки сайта маленький. Можно написать коммент в формате констатации факта, но это неэффективно, т. к. у разработчика останется вопрос: «а какой отступ должен быть?», и это выльется в поиски на макете, дополнительную коммуникацию или неточное исправление.
Мне такой подход не нравится, потому что он провоцирует разрабов на исправление ошибок быстрыми костыльными фиксами, без понимания логики макета и разбирательств в причинах бага. "Не хватает 10 пикселей? Ну на тебе плюс 10 пикселей". А что было не так? Опечатка? Не та переменная? Конфликт стилей? Криво контейнеры вложены? А может быть вылезет ошибка в самих макетах?
Конечно, там где возможно дать более осмысленный контекст – его нужно давать. Например: "отступы слева и справа должны быть одинаковые". Или "левый паддинг слева должен быть больше, это сделано специально, чтобы скомпенсировать иконку". Но если специфики нет, тогда "неправильный отступ" тоже может сгодиться. Но не конкретные числовые фиксы.
Одно не противоречит другому) Полностью согласна, что ребят нужно погружать в тонкости дизайна и сокращать таким образом будущие ошибки. Если вижу в чём проблема или если ошибка часто повторяется, всегда стараюсь объяснить как правильно собирать и почему надо делать именно так. И на самом деле именно эту идею хотела заложить в пункт "обучение разработки".
Но чаще всего дело в банальной невнимательности и наличие фактических значений значительно ускоряет и упрощает исправление таких багов.
Что касается проблем в макетах, у нас с разрабами/тестерами выстроена так коммуникация, что ребята подсвечивают всякие не состыковки в макетах. И это очень помогает, они как мой надежный тыл и я всегда знаю если где-то ошибусь ребята подстрахуют)
Как организовать и оптимизировать дизайн-ревью