Клієнт приходить із готовим рішенням у голові: «Зробіть як у конкурента, тільки краще». За тиждень дизайнер показує перший макет — і виявляється, що «краще» кожен уявляв по-своєму. Один чекав каталог одразу на головній, другий — велику форму заявки на пів екрана, третій — відео на всю ширину й мінімум тексту. Прототип потрібен саме для того, щоб цю розбіжність спіймати на сірій схемі, а не після того, як половину сторінок уже зверстано й підключено до бекенду. У Netloria жоден багатосторінковий проєкт не заходить у розробку без цього кроку, і далі я поясню, чому це не зайва бюрократія, а спосіб не переплатити двічі.
Прототип — не картинка «щоб погодити». Це рішення, ухвалене до того, як воно стало дорогим.
Плутанина починається з термінів. Люди кажуть «прототип», а мають на увазі три різні речі, у яких різна мета й різна вартість помилки. Каркас відповідає на питання «що і в якому порядку». Макет — «як це виглядає». Інтерактивний прототип — «як це працює, коли по ньому клікати». Якщо ці три речі не розводити, замовник дивиться на сірі блоки й думає, що йому показали недороблений дизайн, хоча насправді на цьому етапі колір і шрифт свідомо ще не існують.
| Що це | Що показує | Чого ще свідомо немає |
|---|---|---|
| Каркас (wireframe) | Сірі блоки: де меню, де заголовок, де кнопка, у якому порядку йде контент на кожному екрані | Кольорів, шрифтів, реальних фото — щоб не сперечатись про відтінок, поки не погоджена структура |
| Макет (mockup) | Той самий каркас, але вже в кольорі, зі шрифтами й зображеннями — статична, «намальована» сторінка | Клікабельності: кнопки не натискаються, переходів між екранами немає |
| Інтерактивний прототип | Макет, у якому працюють кнопки й переходи — сайт можна «клікати» ще до рядка коду | Коду, бази даних, реальних даних і реальної швидкості завантаження |
На практиці в один проєкт часто входять усі три: спершу каркас, щоб домовитись про логіку, потім макет, щоб домовитись про вигляд, і за потреби клікабельний прототип для складних сценаріїв — оформлення замовлення, багатокрокової форми, особистого кабінету. Для простого лендингу вистачить каркаса й макета. Для інтернет-магазину з фільтрами й кошиком без клікабельної версії ви ризикуєте виявити проблему з навігацією вже на живому сайті.
Головний аргумент проти прототипу звучить логічно: навіщо платити за схеми, якщо можна одразу верстати й бачити результат. Проблема в тому, що правка на схемі коштує кількох хвилин у Figma, а та сама правка на зверстаному сайті — це переписаний HTML, зламана адаптивність під мобільний, перевірка на всіх сторінках і повторне тестування. В інженерії програмного забезпечення це описують правилом 1:10:100: помилка, яку виправили на етапі вимог і дизайну, коштує умовну одиницю; на етапі тестування — уже близько десяти; після релізу — понад сто. Цифри приблизні й залежать від проєкту, але напрямок ніхто не оскаржує: чим пізніше ви знайшли, що структура не працює, тим болючіше її міняти.
Переклад цього правила на мову веб-студії простий. Замовник, який погодив каркас за годину обговорення, економить тижні. Замовник, який сказав «давайте одразу робити, по ходу розберемось», майже завжди повертається з фразою «а можна тут усе переставити» — коли «тут» уже коштує переставити дорого.
Прототип — не про красу. Він про рішення, які потім важко відкотити. Ось що реально випливає на сірих схемах і майже ніколи — на етапі «здається, і так зрозуміло»:
Знайомо? Якщо ви хоч раз запускали сайт і за тиждень після старту переставляли блоки місцями — це і є той випадок, коли прототипу не було.
Не кожному проєкту потрібен однаковий за деталізацією прототип. Логіку деталізації зручно тримати в голові так: чим більше грошей і сторінок на кону, тим детальніше треба домовитись «на березі».
| Рівень | Що це на практиці | Коли доречно |
|---|---|---|
| Низька деталізація | Сірі каркаси, іноді від руки чи в простому редакторі — швидко, дешево, легко викидати й переробляти | Ранній етап, коли ще сперечаються про саму структуру й склад сторінок |
| Середня деталізація | Акуратні каркаси з реальним порядком блоків і чорновим текстом, але ще без фінального дизайну | Погодження логіки з замовником перед тим, як дизайнер витрачає час на красивий макет |
| Висока деталізація | Кольоровий клікабельний прототип, майже не відрізнити від готового сайту | Складні сценарії, презентація інвестору, тестування з реальними користувачами |
Часта помилка — стрибнути одразу у високу деталізацію. Красивий клікабельний прототип виглядає переконливо, і замовник погоджує його емоційно, «бо гарно», не помітивши, що з третього екрана нема виходу назад. Низька деталізація навмисне некрасива саме тому, що змушує дивитись на логіку, а не на відтінок кнопки.
Прототипування — не одна дія, а коротка послідовність, у якій кожен наступний крок спирається на погоджений попередній. Ось як це відбувається на реальному проєкті.
У Netloria ми свідомо не перескакуємо перші два кроки навіть під тиском дедлайну — бо саме там ховаються рішення, які потім неможливо відкотити дешево. Півдня на структуру економлять тижні на переробках.
Погодити прототип очима замовника й перевірити його на реальних людях — це різні речі, і друге сильніше. Замовник знає свій продукт зсередини й тому не бачить того, що не зрозуміє новачок. Класичне дослідження Якоба Нільсена з Nielsen Norman Group показує, що вже перші п’ять користувачів у тесті знаходять близько 85% проблем зручності — тобто щоб зловити переважну більшість помилок навігації, не потрібна велика й дорога вибірка, достатньо посадити кількох людей із цільової аудиторії за клікабельний прототип і мовчки подивитись, де вони зупиняються, куди тицяють не туди й на якому екрані втрачають нитку. Нільсен радить не гнатися за одним великим тестом на п’ятнадцять осіб, а розбити перевірку на три невеликі раунди, переробляючи прототип між ними — саме тому клікабельна версія цінна: її можна тестувати ще до того, як написаний бодай рядок робочого коду. Дешевше сценарію годі й шукати.
Тест не мусить бути лабораторним. Іноді достатньо показати прототип трьом-чотирьом людям, які не бачили проєкт, дати їм завдання «знайди ціну й залиш заявку» й помовчати. Те, де людина застрягає мовчки, і є найдорожча помилка, яку ви щойно спіймали безкоштовно.
Коли в Netloria ми віддаємо прототип на погодження, то одразу проговорюємо з клієнтом, що саме зараз вирішується, а що — ні. Це знімає половину непорозумінь: людина перестає шукати на схемі колір і починає дивитись на те, заради чого схема й існує.
Чесно: не завжди він потрібен у повному обсязі. Простий односторінковий сайт на перевіреному шаблоні, де структура вже відома й відпрацьована на десятках проєктів, можна зробити без окремого клікабельного прототипу — достатньо каркаса на пів години. Ризик тут низький, бо переставляти майже нічого.
А ось де пропускати не варто: багатосторінковий корпоративний сайт, інтернет-магазин, будь-який проєкт із формами, фільтрами, особистим кабінетом чи нестандартною логікою. Що більше екранів і сценаріїв, то дорожча кожна структурна помилка — і то більше сенсу в тому, щоб знайти її на схемі. Правило просте: якщо ви не можете описати весь сайт однією сторінкою, вам потрібен прототип.
Прототип — це той рідкісний етап, який майже нічого не коштує порівняно з тим, скільки економить. Він перетворює «здавалося, ми про одне» на конкретну схему, яку видно й можна виправити за хвилини. Далі за прототипом іде вибір візуального стилю — про це ми писали окремо в гіді, як обрати стиль дизайну сайту, — але спершу має бути погоджена структура, інакше будь-який стиль ляже на хиткий фундамент.
Якщо вам потрібен багатосторінковий сайт, який спочатку продумують, а вже потім верстають, команда Netloria збирає корпоративний сайт під ключ — з прототипом, тестуванням логіки й погодженням структури до того, як почнеться розробка. Напишіть нам, і ми покажемо на вашому прикладі, як виглядає прототип і що він встигає врятувати.
