ADR для дизайнерів: як зафіксувати не тільки рішення, а й причину

💡 Усі статті, обговорення, новини про дизайн — в одному місці. Приєднуйтесь до Design спільноти!

Привіт! Мене звати Марина, я UI/UX & Product Designer. У цій статті розповім вам про те, як розв’язала проблему втрати контексту, коли до готового дизайн-флоу за якийсь час повертається інший учасник команди.

Дисклеймер: це не гайд і не «як треба». Якщо у вашій команді така практика вже є — чудово. Я просто ділюся власним досвідом: як прийшла до цього сама і що це змінило в роботі.

Коли макет є, а контексту вже немає

У нашій команді над продуктом одночасно працює кілька дизайнерів, і флоу, до яких я торкалася місяць тому, зараз може дороблювати хтось інший. Це нормально, так влаштована робота в команді такого розміру.

Але через це я почала помічати, що коли хтось (включно зі мною) повертається до вже готового флоу, щоб щось доробити чи виправити, він бачить тільки фінальний результат. Не бачить, що саме розглядалося, від чого відмовилися і чому саме так, а не інакше. І доводиться або перепитувати людину, яка робила це місяців зо два тому (і вже сама не все пам’ятає), або вирішувати наосліп, спираючись тільки на те, що видно на екрані зараз.

Рішення живуть тільки в голові людини, яка їх ухвалила. А команда — це постійний рух, коли хтось у відпустці, хтось перемикається на інший проєкт, хтось за пів року взагалі йде з компанії. Разом з людиною зникає і контекст.

Рев’ю — це подія, яка трапляється і зникає. Якщо рішення ніде не зафіксоване окрім усної домовленості на дзвінку, воно існує рівно стільки, скільки пам’ять учасників цього дзвінка.

У розробників ця проблема вирішена вже давно практикою Architecture Decision Records (ADR). Це коротка нотатка, яка фіксує рішення разом із контекстом: що обрали, чому, які альтернативи розглядали і відкинули. Не документ на двадцять сторінок, а щось, що читається за хвилину.

Мені сподобалася у цій практиці, що рішення там не видаляють і не переписують мовчки. Якщо його переглядають, тоді стара версія отримує статус «Superseded by» з посиланням на нову і поясненням, що змінилося. Тобто історія рішень не губиться навіть тоді, коли самі рішення змінюються — а вони змінюються часто, і це нормально.

Це і є те, чого не вистачає в дизайні. Не інструмент, щоб когось «зловити», а спільна пам’ять команди, яка не залежить від того, хто зараз у відпустці.

Як я перенесла ADR у дизайн-флоу

Спочатку я почала вести спрощену версію для себе. Писала шість рядків поруч із самим флоу (canvas-секція у Figma, а не окрема вікі, до якої ніхто не заходить):

• Контекст: яку задачу вирішували, які були обмеження.
• Рішення: що обрали, одним реченням.
• Відкинуті альтернативи: що розглядали і чому відмовились.
• Ціна рішення: що ми цим ускладнюємо чи втрачаємо.
• Впевненість: наскільки ми були певні (60%? 90%?).
• Статус: Accepted / Superseded by → посилання.

Правило діє одне — якщо запис не читається за хвилину, його ніхто не писатиме і не читатиме.

Щоб шаблон не лишався абстрактним, ось реальний запис із мого флоу. Момент, коли користувач вводить суму більшу за доступний баланс.

Контекст: на кроці введення суми людина може ввести більше, ніж є на балансі. Треба вирішити, коли і як про це сказати. Обмеження: помилка не повинна спрацьовувати на пів-цифри, бо суму часто друкують не одразу цілком.

Рішення: показуємо помилку не на кожен символ, а на blur / спробі піти далі. До того — м’яка підказка з доступним балансом під полем.

Відкинуті альтернативи: (1) валідація на кожен символ — блимає, поки людина ще друкує; (2) автоматично обрізати введення до максимуму — користувач не розуміє, чому цифра «не вводиться».

Ціна рішення: можна дійти до «Далі» з невалідною сумою й аж там отримати помилку — один зайвий клік у найгіршому випадку.

Впевненість: 80%. Тестували на 5 людях, патерн зрозумілий, на дуже великих сумах ще не перевіряли.

Статус: Accepted.

Пишеться хвилини за три, читається за одну. І коли за місяць хтось запропонує «а давайте валідувати одразу» — відповідь уже є, з причиною.

Щоб це не перетворилося на бюрократію, я одразу окреслила, чого НЕ документую. Дрібниці рівня «тут відступ 16, а не 12» — ні. Очевидні рішення без відкинутих альтернатив — теж ні. Якщо не було з чого обирати, немає що фіксувати.

Запис має сенс тільки там, де була справжня розвилка: ми свідомо обрали одне і відмовилися від іншого, і це інше достатньо привабливе, щоб за пів року хтось захотів до нього повернутися. Фільтр, яким користуюся: «Чи розсердить мене майбутня я, якщо доведеться пояснювати це рішення втретє?». Якщо так — пишу.

Чим це допомогло

За кілька місяців такої практики було два випадки, де вона змінила роботу найпомітніше. Розповім про обидва

Перший випадок — складний флоу, який довго не міг стабілізуватися. Різні дизайнери підключалися до нього в різний час, і кожен вносив свої правки. Хтось бачив одне рішення, хтось інше, і флоу постійно «плавало» навіть тоді, коли, здавалося б, вже все узгодили. Проблема була в тому, що навіть стабільне рішення ніде не фіксувалося як «закрите питання», а просто висіло в повітрі, і тому виглядало доступним для чергової правки.

Коли я почала фіксувати, що це рішення прийняте, воно пройшло юзер-тестування, воно закриває всі проблеми, які перед нами стояли, і не потребує постійних доопрацювань — ситуація змінилась. Це вже не виглядало як поточна версія, яку можна поправити. Це вже було як завершене рішення з підставою. Люди, які підключалися пізніше, бачили не просто макет, а макет з поясненням, чому саме так. Тож питання «а може спробуємо інакше?» виникали набагато рідше, бо відповідь на них уже була написана.

Другий випадок простіший, але показовий. Перед тим, як піти у відпустку, я залишила флоу повністю опрацьованим і задокументованим: рішення, обґрунтування, короткі анотації поруч з екранами — по суті, той самий шаблон. Коли я повернулася, з’ясувалося, що це реально прискорило роботу команди.

У невеликих командах часто буває, що і розробник, і дизайнер, і інші учасники пропонують свої ідеї по ходу — і це нормально, навіть корисно. Але коли поруч є лог з поясненням, розробник одразу бачить, чи закриває запропонована ним ідея ті самі проблеми, які вже врахували в рішенні. І навіть якщо хтось не подивився пояснювальне відео на п’ять-шість хвилин, вся логіка вже була у Фігмі, поруч з макетом, а не десь окремо.

Це не про те, щоб захистити своє рішення від когось, а більше для того, щоб команда, яка постійно перетинається на одних і тих самих флоу, не витрачала час на здогадки і повторні пояснення.

Бо коли лог є, питання, чому тут зроблено саме так, перестає бути риторичним чи звинувачуваним. Це просто питання, на яке є відповідь за хвилину читання. І це стосується не тільки мене, будь-хто в команді, хто торкнеться цього флоу через рік, отримає те саме.