Слово «передача» точно описує проблему. Щось закінчено, а потім перекинуто. Те, що приземляється з іншого боку, — статична картинка системи, яка мусить працювати в станах, яких картинка ніколи не показувала.
Макети завершені за визначенням. Продукти — ні. Кожен розрив між ними заповнює розробник, що о шостій вечора ухвалює дизайн-рішення без контексту, щоб зробити це добре.
Чого бракує кожному макету
Ось стани, які ми тепер вимагаємо, перш ніж щось назвати готовим. Більшість суперечок між дизайнерами й розробниками насправді через те, що один із них не визначений.
- Порожній. Що бачить новий акаунт. Зазвичай найбільш переглянутий екран продукту і найменш спроєктований.
- Завантаження. Скелетон, спінер або нічого — вирішено, а не за замовчуванням.
- Помилка. По кожному полю й сторінці, з реально написаним реченням.
- Забагато. Найдовше ім’я, опис на 400 символів, список із сорока пунктів.
- Замало. Один елемент. Нуль елементів. Ім’я з двох літер.
- Права доступу. Що бачить користувач лише для читання там, де раніше була кнопка.
Дизайн завершено, коли намальовано його найпотворніший стан, а не найкрасивіший.
Що замінило передачу для нас
Одна команда, один репозиторій і живе staging-посилання з першого тижня. Дизайнери перевіряють у браузері, а не у файлі — бо саме в браузері шрифт рендериться інакше, тінь важча і існує стан hover.
Ми також перестали вважати файл дизайну джерелом істини. Щойно компонент побудований, канонічним стає побудований, а файл слідує за ним. Файл, що суперечить продакшену, — не документація, а дезінформація.
Якщо змушені працювати з двома підрядниками, купіть їм спільний щотижневий дзвінок і внесіть чек-лист станів вище в контракт. Це коштує годину на тиждень і рятує від суперечки, хто мав спроєктувати порожній стан.