Ксения Беляева написала о дизайн-ревью, когда дизайнер проверяет, как разработчик воплотил его дизайн.

— Он делает это перед релизом: фиксирует отличия реализации от макетов, а потом подтверждает, что они были устранены;
— Без ревью дизайнер не знал, что уже готово, реальный продукт мог отличаться от макетов, а его замечания по отличиям получали низкий приоритет (вызывало ощущение работы в стол);
— Это не дополнительный этап: ревью дизайнера не должно задерживать разработку и может происходить параллельно с тестированием или до него;
— У задач по ревью самый высокий приоритет. Сложно предугадать их появление, поэтому ревью иногда сдвигает другие задачи по дизайну;
— Ревью улучшает качество выпускаемых продуктов и коммуникацию между менеджером, дизайнером и разработчиком, которая часто отсутствует. Разработчик может повлиять на дизайн в процессе вёрстки;
— Без подтверждения дизайнера задачу закрыть нельзя, но иногда приходится идти на компромисс. В свойствах ошибки есть приоритет. Если все ошибки со средним и высоким приоритетом исправлены, а на правки с низким нет времени, задачу можно подтвердить;
— В статье есть пример настройки Джиры под этот процесс, шаблоны для фиксации отличий, чеклист для дизайн-ревью.

#review

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

— А есть ли в этом случае у человека какая-то привычка? Есть ли в мире какие-то привычные паттерны такого интерфейса? Могу ли я сделать максимально приближённый интерфейс к этой привычке?
— Не заставляю ли я делать что-то пользователя, что может сделать компьютер? Например, поле сразу в фокусе.
— Не потерял ли я данные, которые дал мне пользователь?
— Убрал ли я все лишнее с этого экрана? Есть ли возможность соединить какую-то функциональность? Могу ли я добавить какую-то полезность?
— Я стараюсь представить, что я не видел ничего до попадания на конкретный экран. А понятно ли мне на этом экране всё, с учётом всего вышесказанного?
— Сделал ли я всё, чтобы не использовать модальный интерфейс? Могу ли я показать все функции сразу? Могу ли я использовать квазирежим? Хорошо ли я продумал навигацию стеков?
— Легко ли мне попасть в каждый элемент? Показал ли я области клика?
— И ещё 11 пунктов.

#review

Никита Семёнов поделился своим чеклистом для проверки дизайна интерфейса. Некоторые пункты:

— Учтено ли, где и в каком состоянии будет находиться пользователь во время использования продукта;
— Контекст, в котором будет жить создаваемый интерфейс;
— Видел ли его разработчик;
— Что можно упростить и удешевить в разработке без потери ценности;
— Какие действия система может выполнить за пользователя;
— Какие функции и свойства можно объединить в один элемент (например, кнопка «Следующая серия» в Кинопоиске также показывает, когда автоматически запустится следующая серия);
— Что можно убрать из макета без потери смысла;
— Что будет, если контента будет больше или совсем не будет, увеличится количество пунктов и так далее;
— Проработаны ли ошибки, пустые состояния, состояния загрузки;
— Получает ли пользователь обратную связь от системы.

#review

Александр Кузнецов написал о дизайн-ревью.

— Это проверка дизайнером результата разработки своих макетов и фиксация дефектов;
— В отличие от тестировщика, который проверяет всё досконально, дизайнер смотрит верхнеуровнево: всё ли так, как задумано;
— Помогает дизайнеру быть в курсе, что уже разработано, и не выгорать из-за того, что результат отличается от макетов;
— Команде помогает сохранять высокое качество продукта (консистентность, соответствие дизайн-системе, tone of voice), экономить время разработки (не надо гадать, что дизайнер имел в виду, меньше работы тестировщику), улучшить коммуникацию;
— Если сейчас дизайн-ревью не проводится, дизайнеру придётся проявить инициативу и договориться о внедрении этого этапа;
— Проводить дизайн-ревью можно в параллель с тестированием;
— Чтобы эффективно ревьюить, дизайнер должен научиться пользоваться инструментами разработчика в браузере, Xcode, Android Studio и понятно описывать дефекты.

#review

Виктория Рябкова дополнила тему дизайн-ревью своим опытом.

— Проблема: time to market. Дизайнер может найти незначительные по меркам бизнеса дефекты. Часто фичу катят без доработки, а по найденным дефектам заводят баги с низким приоритетом, которые некогда исправлять, так как всегда есть что-то поважнее;
— Решение: внедрить пред-ревью — быструю проверку вёрстки (именно компонентов и вёрстки) на этапе разработки в личке или в специальном треде с разработчиком. Занимает 15 минут и сокращает дизайн-ревью на 50%;
— Проблема: команда не понимает ценность реализации pixel perfect. Когда дизайнер приносит замечания по поводу отступов, растёт недовольство разработчиков;
— Раз в 3 месяца проводят опрос удовлетворённости. На вопрос «Что вас беспокоит в процессах между разработкой и дизайном» 90% ответили «Не понимаю, почему я должен соблюдать pixel perfect»;
— Решение: надо продвигать этот подход разработчикам. Кому-то достаточно разговора по душам, кому-то ссылок на пару статей или серии презентаций для разработки;
— От себя добавлю ссылку на статью «Почему вам следует пододвинуть ту кнопку на 3 пикселя влево».

#review

Юрий Герыш написал о работе с Chrome DevTools.

— Открыть их можно через меню (пункт «Инструменты разработчика») или нажав правой кнопкой мыши в любом месте страницы (пункт «Просмотр кода страницы»);
— Экспорт изображений в формате SVG: скопируйте содержимое тега <svg> из кода страницы и вставьте в Фигму;
— Если картинка в формате PNG, можно поискать её SVG-версию на сайте: добавьте к адресу картинки «?svg», например: «https://habr.com/img/habr-logo-ru.png?svg»;
— Меняя код CSS (вкладка Styles), можно быстро прикидывать стилевые правки;
— В Styles можно видеть и менять правила, определяющие внешний вид страницы;
— На вкладке Computed отображаются текущие свойства выбранного элемента, которые получились после применения всех правил. Например, сколько в пикселях составила ширина, которую задали в процентах;
— Меняя HTML, можно править текст, дублировать и удалять элементы;
— Так можно проверить поведение элементов в корнер-кейсах. Например, что будет, если название слишком длинное;
— Просмотр адаптивных состояний: можно задать размер окна браузера. Есть пресеты размеров популярных устройств;
— Чтобы выбирать Инспектором элементы, свёрстанные с помощью Shadow DOM (изолирование стилей элемента), включите в настройках «Show user agent shadow DOM»;
— Просмотр состояний элементов (hover, active): список состояний отображается на вкладке Styles с нажатым «:hov», либо можно выделить элемент через Инспектор и в контекстном меню нажать «Force state».

#review #chrome_devtools