Чому хороший дизайн починається раніше, ніж перші картинки

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

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

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

Нижче наведені типові проблеми, які я спостерігав у своїй практиці (і не тільки), що призводять до поганого дизайну, а так само поради що з ними робити.

Проблеми з комерційною частиною

Скільки буде коштувати продукт? Які плануються способи оплати? Який набір опцій буде включати в себе кожен тариф? Без яких даних можна обійтися на етапі покупки або реєстрації? Обов'язково прив'язувати банківську карту, щоб активувати пробний період? Зазвичай ці питання вирішуються на самому верху, узгоджуються з фін. працівниками і приходять дизайнерам як даність. Яким би ідеальним не був інтерфейс прив'язки банківської картки, але якщо це робиться при реєстрації, сервіс втратить дуже багато клієнтів.

Що робити?

Питання тарифної політики і фінансів повинні вирішуватися якомога раніше, спільно з ux-дизайнерами і тестуватися разом з прототипом сервісу. Етап вибору і придбання продукту не повинні сприйматися окремо від його використання. Проблеми в цій частині можуть відбитися і на інтерфейсі.

Проблеми з маркетингом

Хто наші покупці? Чим їх не влаштовує наявний стан справ? Які функції продукту найбільш важливі? За що люди готові платити? Які функції включити в першу версію?
Відповіді на ці питання часто шукає хто завгодно, але тільки не той, хто винен. Дизайнерам і програмістам кажуть: “У нас тепер lean-підхід, ось вам ідея продукту і книжка на вечір. Завтра підете робити customer development, потім намалюєте дизайн і зробите прототип". В результаті може вийти так, що функціями продукту буде зручно користуватися, тільки не тими, які потрібні. А ті, що потрібні, заховані далеко вглиб і зроблені за залишковим принципом.

Що робити?

Саме продакт-менеджер і маркетолог повинні знайти відповіді на ці питання і як можна раніше. Не без допомоги колег, звичайно, але і не можна пускати процес на самоплив. Без цієї інформації, дизайнери будуть орієнтуватися на свою думку, або проведуть дослідження самостійно, але від цього не виграють ні дизайнери, т. к. вони будуть займатися не своєю справою, ні бізнес, т. к. він ризикує отримати не те, що чекає. Методів дослідження ринку і пошуку ринкової ніші можна навчити, але це окрема наука і парою стартаперских майстер-класів тут не обійтися.

Проблеми з управлінням проектом

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

Що робити?

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

Проблеми в орг. структурі і бізнес-процесах

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

Що робити?

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

Проблеми з реализуемостью функцій

Дизайнер може намалювати скільки завгодно красивий і зручний інтерфейс, але він не буде реалізований з-за технічних обмежень.

Що робити?

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

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.