Дизайн

Тонкощі продуктового дизайну

Продуктовий дизайнер — це не зовсім дизайнер. Він може тижнями не відкривати графічний редактор і не зробити ні одного макета за місяць. Тому що основна мета його роботи в іншому.

За останні півтора року я працював над двома продуктами. З першим (BINO CX) пройшов шлях від нуля до виручки в 1 млн рублів менше ніж за рік, а другий розвиваю в даний момент.

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

Не творче просвітлення

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

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

Не справедливо? Аж ніяк.

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

Щоб підвищити свою значимість у компанії, від дизайнера потрібно показувати розуміння бізнес-завдань і завойовувати довіру грамотними дизайн-рішеннями.

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

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

Продуктові дизайнери теж крадуть

Дуже корисно звернутися до досвіду схожих сервісів, навіть якщо ви створюєте новий продукт. Це можуть бути прямі конкуренти або сервіси з схожою механікою.

Слухаючи курс ux-design від AIC, мені стало очевидно, що вивчення конкурентів допомагає не тільки в пошуках натхнення, але і при аргументації своїх рішень замовнику керівнику. Варто показати приклад успішного сервісу та довіра до вашої ідеї зростає в рази.

Авіакомпанії можуть аналізувати інтерфейси сервісів з продажу квитків у кіно. Сайти футбольних клубів можуть звернутися до досвіду медіа-сервісів. І хто завгодно може подивитися на соцмережі.

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

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

“Так робить Google!” — не аргумент.

“Так робить Google, тому що він таким чином вирішує схожу задачу” — зовсім інша справа.

Головні друзі

Розробники — головні друзі дизайнерів (і самий головний інструмент).

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

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

Це не є проявом неповаги до колег. В цьому проявляється ваша повага до створюваного продукту.

Про що вони говорять

Прочитавши Канемана і Талеба, я став обережніше ставиться до будь-якого типу статистикою.

Одного разу до нас в офіс залетів маркетолог щоб поділитися відкриттям. Він дізнався, що люди працюють “по-іншому”, тому нам доведеться переробити продукт. Маркетолог навів нещодавній приклад, його заява виглядало логічним і засновник готовий був з цим погодитися, але зробив би велику помилку.

Додаючи будь функціонал, спираючись на реальні приклади, дізнайтеся який відсоток ваших потенційних користувачів буде його використовувати. Можливо, ви перелопатите продукт заради 1% користувачів, які нічого бізнесу не приносять.

Так, це більше аналітика, ніж дизайн, але це не означає, що продуктовий дизайнер не повинен цього знати.

Прочитайте “Думай повільно… вирішуй швидко”. Ця книга сильно вплинула на моє сприйняття досліджень і допомагає уникати типових помилок.

Фільтр шуму

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

Засновники/інвестори володіють авторитетом, але не завжди мають глибоку експертизу, як співробітники, які щодня працюють “в полі”. Саме тому, працюючи над попереднім проектом, я регулярно спілкувався з підтримкою і цікавився питаннями користувачів.

Ця практика допомагає виявити місця, на яких у користувачів виникають труднощі. І якщо ці місця критично важливі, приділіть їм достатньо уваги.

Десь буде досить текстової підказки, а в деяких випадках доведеться змінювати інтерфейс.

Гнучкий фреймворк

Фреймворк — базова структура, навколо якої будуються елементи інтерфейсу.

Чим гнучкіше у вас фреймворк, тим краще.

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

Щоб створити гнучкий фреймворк, потрібно розуміти можливі варіанти розвитку сервісу, в чому вам допоможе “База знань” (нижче). Аналізуючи потенційні зміни, ви зможете приймати стратегічно правильні дизайн-рішення.

База знань

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

В моїй базі даних зберігається кілька типів матеріалів:

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

Сценарії. У кожного сервісу є кілька сценаріїв і дизайнер повинен знати їх і добре пам’ятати.

Customer Journey Map. Відмінний інструмент, який допомагає проаналізувати сценарії на наявність потенційних проблем. CJM основних сценаріїв я роблю в таблиці:


Багато конфіденційної інформації 🙂

Інтерфейси. Тут я збираю думки та ідеї про ключових місцях сервісу.

Ідеї. Загальні думки щодо майбутнього розвитку продукту.

Хто вони?

Я періодично буваю в студії AIC, де двічі стикався з цікавими випадками. Один раз поруч з монітором дизайнера я побачив фотографію Володимира Машкова, в іншій — Сергія Гармаша. Здогадуєтеся чому?

Обидва актори були особами клієнтів студії — банків ВТБ і “Пошта Банку”. Маркетинг спеціально підбирав акторів під цільову аудиторію, тому дизайнери повісили портрети на чільне місце.

Знати користувачів — це значить розуміти їх мотиви, бажання, звички, графік життя, використовувані пристрої, середній дохід, сімейний стан, …

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

Бачення

Продуктовий дизайнер з самого початку має бачення проектованого сервісу. Я довго думав звідки береться бачення і зупинився на наступному:

Бачення — це синтез досвіду та отриманих знань.

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

Яким чином можна знайти “правильне” бачення сказати складно. Непогана ідея — надихатися чужим: читаючи книги великих інноваторів і вивчаючи успішні продукти. Для початку цього може бути цілком достатньо, а далі все буде залежати від вашої здатності аналізувати досвід і на основі нього приймати грамотні рішення.

Досвід — ключова річ не тільки в логіці, але і творчості. Тому набирайтеся його щодня, осмислюйте отримані знання і не зупиняйтеся.

Терпіння — ключ до всього.

Related Articles

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Close