Бородаті дизайнери про дизайні думають в останню чергу

Який колір краще — бірюзовий або оливковий, а кнопки — глянсові або плоскі, а шрифт — антиква або гротеск, а верстка — фіксована, гумова, або адаптивна… і ще 100500 подібних питань. Ласкаво просимо в голову дизайнера. Спробуємо розібратися, що тут зайве, а чого не вистачає.

Отже, мова піде про дизайнерів у маленьких компаніях. Але не про тих, хто малює одноразові художні промо-сайти (де часто працює підхід «чим оригінальніше, тим краще»), а про тих, хто створює функціональні, корисні програми та веб-інтерфейси, розраховані на довгострокове використання. Начебто б, яка різниця, що малювати — скрізь кнопки, сторінки, картинки, текст… А ось і ні. Це зовсім різні завдання і вирішувати їх повинні люди з абсолютно різними навичками і талантами. Але, про все по порядку.

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

З мого досвіду, якщо дизайнер просто малює те, що йому говорять, то в більшості випадків виходить старанно намальована даремна картинка. На етапі впровадження половина красивого макета роз'їжджається, т. к. він натягується на реальні дані, виявляються нестиковки в навігації та ін. Результат не подобається ні самого дизайнера, ні директору (або замовнику). Після цього все залишається як є, або починаються виснажливі переробки, що ведуть до милиць і підпорок. Хто винен — дизайнер?



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

Почавши з цілей користувачів і основних сценаріїв взаємодії їх з продуктом, ми зможемо подивитися на систему «з висоти пташиного польоту». Сфокусуватися на основних частинах системи і простежити основний шлях користувача від входу в додаток до цільової дії, і всі свої зусилля сконцентрувати на тому, щоб зробити цей шлях найбільш зрозумілим і зручним. Цей підхід називається «цілеоріентірованним» і дуже добре описується в книзі Алана Купера «Про інтерфейсі. Основи проектування взаємодії».

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

У нас буде набагато більш сильна позиція, якщо ми бачимо, що ці рішення допомагають у досягненні наших цілей і якщо користувачі розуміють, що і як вони можуть робити на сторінці і поводяться так, як ми хочемо. Як написав Ерік Рис у книзі «Бізнес з нуля. Метод Lean Startup для швидкого тестування ідей та вибору бізнес-моделі»:
«Хороший дизайн — той, який змінює поведінку споживачів на краще».
І це єдиний об'єктивний критерій хорошого дизайну. І ось вам ще один вислів на цю тему з книги Getting Real компанії 37signals. Тут немає слово «Дизайнер», але по-моєму, до нас ця фраза відноситься безпосередньо:
«Кращі проектувальники і кращі програмісти — не ті, у кого кращі навички, або наймоторніші пальці, чи не ті, хто може зробити красивий макет в Photoshop, — це ті, хто може визначити, що має значення. Це ті, хто приймає вигоди від рішення.»
Думати не треба малювати
Часто дизайнер виявляється єдиною людиною відповідає за те, як додаток буде сприйматися користувачами, що і як вони будуть в ньому робити, наскільки вони будуть задоволені, стануть постійними клієнтами або закриють додаток і ніколи до нього не повернуться. Погодьтеся, що зміна кольору кнопочки навряд чи може серйозно на це вплинути.

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



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

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

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

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

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

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

<habracut/>

Джерело: Хабрахабр

0 коментарів

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