Как согласовывать интерфейс веб-приложения с разработчиком, а не только с дизайнером
Чем ревью веб-приложения отличается от ревью сайта
Коротко: для сайта или лендинга достаточно согласовать картинку — макет статичен, экран выглядит одинаково у всех и всегда. Для веб-приложения это не работает: личный кабинет, SaaS-дашборд или внутренний сервис — это не картинка, а набор состояний, данных и логики, и правка «подвинуть кнопку» может на деле означать правку кода, а не только слоя в макете. Поэтому ревью веб-приложения с первого раунда требует участия разработчика, а не только дизайнера — иначе согласованный макет и то, что реально можно собрать, расходятся уже на старте.
Почему фидбек «не нравится интерфейс» не долетает до разработчика
Обычная цепочка выглядит так: клиент смотрит макет, пишет комментарий дизайнеру, дизайнер правит файл и передаёт его в разработку. Разработчик же собирает не картинку, а рабочий экран со всеми его состояниями — загрузка, ошибка, пустой список, частично заполненная форма. В статичном макете эти состояния почти никогда не показаны: обычно рисуют один, «счастливый» вариант экрана с данными. В результате ревью идёт мимо того, что реально будет видеть пользователь, а комментарий «не нравится, как выглядит таблица» не говорит, что делать, когда таблица пустая или грузится. По наблюдениям Nielsen Norman Group, именно пустые и промежуточные состояния интерфейса чаще всего остаются непродуманными — потому что на этапе дизайна их просто не с чем сверить. Снять этот разрыв системно проще не своими силами, а отдав его на подряд: на практике таким согласованием интерфейса и его реализацией на аутсорсе занимается команда, которая отвечает и за интерфейс, и за код веб-приложения — тогда макет и сборка ведутся одними и теми же людьми, а не передаются через третьи руки.
Три роли в одном треде: заказчик, дизайнер, разработчик
Для сайта согласование обычно двустороннее: клиент и дизайнер. Для веб-приложения этого состава недостаточно — нужна третья роль, которая оценивает правку не только по виду, но и по тому, что она значит для данных, состояний и логики экрана. Без разработчика в этом треде заказчик и дизайнер легко утверждают правку, которую потом дорого или вовсе невозможно реализовать так, как она была нарисована, и согласование приходится переоткрывать уже после того, как решение считалось принятым.
На практике это выглядит так: заказчик видит макет и хочет, чтобы список обновлялся «мгновенно», дизайнер рисует, как это должно выглядеть, а решает, откуда возьмутся данные и что произойдёт при сетевой задержке, именно разработчик. Если он подключается к обсуждению уже после того, как заказчик публично одобрил макет, у него остаётся два плохих варианта: молча отступить от утверждённого вида или заново поднимать вопрос, который все считали закрытым. Оба варианта портят доверие к процессу. Три роли в одном обсуждении с самого начала, а не разработчик «в курсе постфактум» — это и есть разница между ревью сайта и ревью приложения.
Как формулировать правку, чтобы она не повисла между дизайном и кодом
Правка «не нравится интерфейс» не долетает ни до дизайнера, ни тем более до разработчика — её не на что опереться. Рабочая формулировка называет три вещи: конкретный экран и состояние (например, форма с ошибкой валидации), элемент, к которому относится комментарий, и ожидаемое поведение, а не только внешний вид. «Кнопка должна становиться неактивной, пока форма не заполнена» — это правка, которую можно оценить и реализовать. «Сделайте кнопку заметнее» — это вкусовщина, которая может уйти в бесконечный обмен вариантами. Чем ближе формулировка к поведению экрана, тем быстрее разработчик понимает, меняется ли только стиль или нужно трогать логику.
Сначала логика экрана, потом пиксели
Порядок согласования в веб-приложении имеет значение. Если сначала утвердить структуру и поведение экрана — какие элементы на нём есть, что происходит в каждом состоянии, какие данные и как отображаются, — а визуальные правки оставить на потом, экономится немало переделок. Если же сначала до мелочей отполировать цвет и отступы, а порядок полей или логику фильтра поменять уже после, визуальные правки приходится переделывать следом за структурными — а делать это дважды дороже, чем один раз в правильном порядке.
Проще всего заметить это на форме. Если сначала согласовать, какие поля обязательны, в каком порядке они идут и как форма реагирует на ошибку, а уже затем обсуждать отступы и цвет подсветки, правки по визуалу встают на готовую структуру и не требуют переделки. Если же сначала утверждён только внешний вид, а состав полей меняется позже, под новую логику приходится перекраивать и визуальные решения — то, что уже казалось согласованным. Такой порядок стоит закладывать в план ревью заранее, а не изобретать по ходу проекта.
Что проверить до того, как интерфейс ушёл в разработку
Перед тем как передавать макет в разработку, стоит пройти короткий чек-лист. Показаны ли в макете все состояния экрана — пустое, загрузка, ошибка, а не только вариант с заполненными данными. Явно ли названо, какие элементы интерфейса динамические и зависят от данных, а какие статичны. Видел ли разработчик макет до начала вёрстки, а не только готовую ссылку на уже согласованный файл. Согласован ли порядок, в котором будут приниматься правки — сначала логика, потом визуал. Эти четыре пункта снимают большую часть расхождений между тем, что утвердили на бумаге, и тем, что в итоге можно собрать.
