Дизайн цифрових продуктів. Мета, роль, метод

Мені довелося створити з нуля підрозділ дизайну в Альфа-Банку і попрацювати дизайн-директором. На це пішло п’ять років. В результаті у нас вийшла дизайн-система (в коді) та підхід до диайну цифрових продуктів. Власне, цей підхід я і розповім тут. Точніше, це текст лекції, яку я читав на початку 2018 року в Москві, Пермі, Новосибірську і Петербурзі. У травні я прийняв рішення залишити банк, тепер дійшли руки опублікувати текст лекції.

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

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

В кінці 2017 року в Лабораторії було близько 30 команд (може більше), і майже для кожної потрібен був свій дизайнер. Навіть на такому відносно великому масштабі важливіше працювати на рівні стратегії, верхнеуровневых понять і підходів, бо то «контролювати» роботу 30 дизайнерів, які працюють над різними продуктами і в різних командах і з різною швидкістю технічно якісно не вийде. Тактику визначає кожна команда самостійно, в цьому вся принадність.

1. Мета: Працюючий продукт, яким користуються люди

Така проста мета. Розберемо кожне слово, адже вона не просто так сформульована саме цими словами.

Зверніть увагу на відсутність слів-процесів, таких як «створення», «проектування» та інше. Процеси — це зовсім не мета. Метою може бути тільки результат, а не процес. Але дизайнери всього світу потрапляють в ментальну пастку процесів, тому результатами їх роботи стають артефакти процесів, а не працюють продукти.

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

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

Занудне пояснення на тему процесів і обурення

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

Будь-яка професійна надбудова для «прискорення» чи «вдосконалення процесів часто просто (вже будучи надбудовою, тобто фактично надмірною явищем) додає процесів і бюрократії, не вирішуючи завдання і не рухаючи команду до мети, а віддаляючи від неї. Взяти той же прототипирование1: замість розробки, ми створюємо емулятори, які дають від сили 10-30% досвіду, який буде в продукті. І проектування. І дослідження. І макети. І вайрфреймы ДО макетів (деякі відрізняють цю стадію від проектування і вкладають в одні і ті ж терміни різні смисли). Потім опис гайдів. І ще «авторський нагляд» (дуже вульгарне назва підглядання за роботою розробників і бурчання — тут розкривається мільярд неврахованих у всіх цих «дослідженнях» і «прототипах» нюансів). Так, замість того щоб прагнути до результату у вигляді продукту, дизайнери або менеджери створюють масу високовитратної метушні. Виростають окремі професії типу «проектувальник», «дизайнер інтерфейсів», «UX/UI-дизайнер», «дослідник» і так далі. На конференціях цілком серйозно починають обговорювати легітимність склеювання UX і UI, мовляв цим мають різні люди займатися, різні інструменти і завдання. Замість фокусу на працюючому продукт виходить фокус на процесах, і кожна надбудова тільки віддаляє від реальної мети.

Треба розуміти, що тут мова йде лише про процеси, найбільш тісно пов’язаних з роботою людей, яких ми називаємо дизайнерами (що б хто в це збірне поняття не вкладав). Про сталих процесах всередині давно існуючої компанії, які називаються «бізнес-процесами», і які найбільш сильно впливають на продукт і досвід користувача, тут мови не йде.

Anyway, повернемося до формулюванні.

1. Працюючий продукт — той, яким можна користуватися, вирішувати завдання. Мова про технічну можливість вирішити задачу використовуючи продукт.
2. Продукт — якась закінчена сутність, цільна, в сумі інгредієнтів володіє більшою цінністю, ніж всі вони взяті окремо.
3. Користуються — говорить про затребуваність і зручність.
4. Люди — більш широке поняття, ніж «клієнти», «користувачі», «співробітники» і т. д. Працюючи для людей, ми враховуємо ергономіку і які-ніякі але стандарти.

Припустимо, продукт не працює. Тут все зрозуміло: користуватися ним (як мінімум за призначенням) не будуть.

Або це не продукт: набір розрізнених компонент, не пов’язаних між собою ні за якою ознакою (таке теж буває).

Або продукт є, але їм не користуються (зовсім). Теж провал, може бути чиє завгодно: відсутність маркетингу, незручний, гальмує.

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

Цю думку з різних сторін обговорюють і коли говорять про Agile, і про часті поставки, і про Скрам і про роботу в командах, але навіть при таких практиках дизайнери чомусь іноді скочуються в затишну колію «процесів». Допускаю такі причини:

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

P. S. Посилання на описи перерахованих методологій, Вікіпедія:

• Agile (Аджайл) — Гнучка методологія розробки
• Scrum (Скрам) — фреймворк гнучкої розробки ПО (робота команди)
• Kanban (Канбан) — система організації виробництва і постачання, що дозволяє реалізувати принцип «точно в термін»

2. Роль дизайнера в скрам-команді

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

(Правильно мислити від результату, категоріями мети.)

Розробник, просто зробивши все відповідно до стандартів і специфікацій швидше за все вирішить завдання краще, ніж якщо пройдеться по макетів дизайнера. Ймовірно, навіть продуктові метрики будуть краще. При повній відсутності дизайнера.

«Ми чекаємо макети» — якщо таке звучить, значить процеси в команді організовані неправильно.

(На жаль, розробники та дизайнери не знають про стандарти — хоча б W3C для вебу, а там закладено дуже багато фундаментальних принципів, які допомагають будувати кращий досвід. За аналогією існують опису/стандарти для провідних мобільних і настільних платформ iOS, Material.)

Зверніть увагу на стартапи — Facebook, Вконтакте, Однокласники і ті ж Apple з Microsoft: в їх основі лежать інженерні рішення (Возняк, Гейтс), до яких згодом приєдналися дизайнери. Вони створювали продукти у відповідності з Метою.

Спочатку — працюючий продукт.

(Красивий, справледивости заради, зробили ідейні хлопці в лабораторії Xerox, але масштаб наслідків зовсім іншою.)

•••

У чому ж тоді роль дизайнера?

У тому, щоб додати цінність.

Додати можна до чогось існуючого, зверніть увагу.

Цінність в очах клієнтів, користувачів.

•••

Часто послідовність перевертають з ніг на голову і «чекають дизайн». Це, звичайно, говорить про незрілість команди і неадекватному менеджменті цієї самої команди.

•••

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

Починайте з коду замість макетів.

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

Саме тому просунуті дизайнери мігрують у прототипи з реальними даними. Чи добре це? Вважаю, це надлишково — навіщо програмувати прототип, коли можна (і логічно) відразу програмувати продукт?

Краще відразу рухатися від розробки дизайну. Починати саме з коду — прототипу, що виконує завдання клієнта в мінімальному вигляді. Прототип, який може піти в робочу постачання (згадаємо пізніше про Customer Development).

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

Ліричний відступ: приклад з фізичного світу

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

Уявіть собі що працюючий продукт це контент видання (книги, журналу, газети). Важливо його правильно «упакувати» і представити читачеві. Без вмісту сенс в оформленні відсутня. Порожня книга не задовольняє читача. Роль розробника порівняй ролі автора. А без гарного оформлення зміст книги все одно має цінність.

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

(До речі про дизайн-системах: це стильові рішення для швидкого оформлення контенту. Інструмент розробки, а не оформлення.)

Takeaway

Усвідомте завдання користувача.

Почніть з розробки. Працюєте в парі з розробником (як арт-директор і копірайтер).

Вдосконалюйте працюючий продукт замість макетів.

Мисліть категоріями мети, результату замість процесів.

Дизайнер продукту створює продукт, а не макети.

3. Метод

Цей метод разом з бібліотекою компонентів став базою банківської дизайн-системи.

Пропоную працювати у такій послідовності:

1. Усвідомити завдання клієнта (користувача) і зафіксувати у вигляді User Story.
2. Визначити метрики. Як ми розуміємо, що завдання користувача вирішена? Зафіксувати.
3. Сформулювати гіпотези. Зафіксувати.
4. Customer Journey Map.
5. Працюючий прототип. MVP. Customer Development.
6. Макети. (При злагодженій роботі команди та існуючої дизайн-системі можна обійтися без макетів).

Завдання клієнта

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

Завдання клієнта виявляють або на підставі скарг («біль клієнта»), або досліджень потреб.

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

Коли завдання усвідомлена, вона записується у вигляді User Story. Про це написано багато статей і книг, тому я тут повторюватися не буду — вивчіть самостійно.

Для занурення в питання настійно рекомендую книгу User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton and Peter Economy).

Два типи метрик (важливо фіксувати обидва!)

1. Сформульований відповідь на питання «Як ми розуміємо, що завдання користувача вирішена». Що ми хочемо отримати у вигляді рішення.
2. Цифрові: відносні і абсолютні величини. Частіше про кількісні показники (фінансові, швидкість, клієнти, час). Як ми зрозуміємо що вдале рішення. Тут є пастка: часто у презентаціях за відносними величинами приховують, перебільшують або втрачають об’єктивний масштаб рішення. Наприклад, «приріст аудиторії склав 3%» — це багато чи мало? Якщо це 150 000 осіб (селище міського типу, зі школами та садочками, магазинами і своєю адміністрацією) — то вже значне число, хоча здається що дрібниці. З іншого боку, «зростання прибутку 300%», якщо це 300 рублів за місяць — вже сумнівний показник. І знову, якщо 150 000 осіб — статистична похибка в розмірах аудиторії всього продукту (припустимо, відвідування головної сторінки пошукача в рік), то цими розмірами швидше за все можна знехтувати, хоча мова про населення того самого селища міського типу.

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

Анекдот про лучника

Кращий в світі лучник

Жив-був найкращий в світі лучник. Припустимо, справа було в Японії — для гостроти сюжету. Він міг уразити ціль краще всіх з найбільшої дистанції, і навіть як Робін Гуд потрапити у власну стрілу. Лучник подорожував по країні і дивував своєю майстерністю оточуючих, ділився досвідом.

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

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

— Що сталося, Лучник? — здивувався селянин.

— Я виявив, що у вашому поселенні живе Великий Майстер, який значно перевершує мене в умінні, тому моя місія виконана і я можу залишити цей світ.

— Ти напевно говориш про уражені цілі в найдивніших місцях? — раптом здогадався селянин.

— О так, ти правий — з жалем мовив Стрілець.

— Про Лучник! Знай: це — витівки місцевого дурника. Він випускає стріли навмання, а мішені обводить пізніше. Ми всі жалкуємо його. Ти помиляєшся.

Гіпотеза — відповідь на питання про швидкий спосіб вирішити завдання користувача

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

Проведіть ментальну роботу і придумайте, як мінімум, три різних рішення.

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

Для простоти спробуйте три підходу:

1. Інтерфейсне рішення. Їх теж може бути кілька.
2. Автоматичне (наприклад, на сервері виконується завдання щодо настання якоїсь події) — без участі користувача.
3. Процеси, що можна змінити в процесах так, щоб користувач з завданням не стикався зовсім, але отримував рішення в потрібний момент.

Найкраще рішення виключно емпіричним шляхом (див. «Науковий метод»). Будь-яке, навіть саме дике на перший погляд рішення/ідею необхідно перевіряти. Гіпотези треба перевіряти. Ідеальний випадок — перевірка всіх трьох гіпотез, виконаних у вигляді MVP. Для цього ви зробите прототип.

Customer Journey Map занурює в контекст

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

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

Про CJM написано досить багато, це необхідно вивчити самостійно і застосовувати в роботі.

Почати можна з книги «історії» Джеффа Паттона.

Працюючий прототип. MVP. Customer Development.

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

Детальніше про все це читайте у книзі Еріка Рису «Бізнес з нуля. Метод Lean Startup для швидкого тестування ідей та вибору бізнес-моделі». Переказувати книгу немає сенсу.

Якщо ви не знайомі з терміном MVP, почніть зі статті на Вікіпедії. Однак книга набагато корисніше.

Обійдемося без макетів, тому що є готовий продукт

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

Takeaway

User Story
Як визначаємо успіх
Гіпотези (способи рішень)
CJM
Прототип, MVP, Customer Development
Макети (якщо потрібно)

До відома

Найбільше, на що ви здатні

Останнім часом все частіше доводиться повторювати, що продукт/компанія гарний настільки, наскільки добре може відпрацювати його найгірша складова частина. На лекціях повторював, і новим співробітникам кажу.

Доведеться пояснити.

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

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

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

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

Думаю, думка вже давно зрозуміла.

Виявляється, багатьом це не зрозуміло.

Навіщо писати про це?

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

Принцип застосовується скрізь, не тільки до продуктів.

Навпіл

Дивлячись на макет: Як вирішити завдання половиною елементів інтерфейсу?

Прибрати половину тексту? Сформулювати в два рази коротше?

Як вирішити задачу за половину відведеного часу?

Провести зустріч за 30 хвилин замість години? Взагалі скасувати її?

Прибрати графіком? Не робити її взагалі, спочатку?

Потрібні іконки?

Що буде, якщо прибрати половину пунктів в навігації?

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

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

Делі на два.

У більш широкому сенсі рекомендую ознайомитися з принципом «Бритва Оккама», якщо ще не знаєте що це таке.

Науковий метод

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

Цитата з Вікіпедії, щоб два рази не вставати

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

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

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

В моєму трактуванні ідея принципу проста: справедлива лише розвідка боєм.

Придумали рішення? Выкатывайте на клієнтів. Наполягаєте на іншому тлі? В бій.

Всі заяви повинні перевірятися та підтверджуватися експериментальним шляхом. В цивілізованій середовищі вони називаються гіпотезами, в аматорських групах — «думкою» 🙂

Умови експерименту повинні бути прозорими і при необхідності відтворюватися іншими людьми.

Для перевірки є купа інструментів і методів. Всі результати можна оцифрувати: воронки, швидкість, суми суб’єктивних оцінок і так далі.

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

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

Виходячи з цього принципу я приходжу до таких міркувань:

1. Будь-який учасник команди може висувати гіпотезу і тестувати її, безвідносно формальної ролі: дизайнер, продакт-оунер, розробник чого завгодно (фронту/бека/мідла і чого ще буває). Всі можуть робити свій внесок у досягнення результату. Командам слід продумати прозорий і простий механізм обліку та порядку запуску таких ідей (якщо їх багато).
2. У дизайнера немає індульгенції, права бути правим просто тому, що він — дизайнер. У деяких командах я спостерігаю цей перекіс, причому в обидві сторони: розробники і продакты маніпулюють тим, що «чекають, поки дизайнер зробить дизайн» (відмовляються думати самостійно), в той же час дизайнери часто користуються тим, що у них на посаді прописано «дизайнер», і для деяких назва посади є аргументом у суперечках. Продукт — сукупність зусиль усіх фахівців.
3. Буває таке, що самі дикі і нелогічні на перший погляд рішення працюють краще всього. Ми оточуємо себе упередженнями і не можемо вибратися з них, подивитися з іншого боку — це і правда дуже складно. Завжди буде включатися опір змінам — як всередині команди/організації, так і клієнтами. Єдиний чесний вихід — рішуче діяти, вміти ризикувати, тестувати боєм, збирати зворотний зв’язок, спостерігати результати і реагувати на них. По-іншому нічого цікавого не з’являється. Помічено і доведено, що все незвичайне позавчора стає нормою сьогодні і буденністю завтра — див. «Вікно Евертона».

Разом

1. Тестувати боєм — виходити хоча б на частину аудиторії і перевіряти всі гіпотези.
2. Всі оцифровувати — результати повинні бути прозорими.
3. «Шалені» гіпотези теж треба вміти перевіряти.
4. Все, що підкріплюється тільки «експертною думкою» та «досвідом» (у конкретних інтерфейсних/продуктових рішеннях) сміливо відправляється на смітник — треба орієнтуватися тільки на спостереження за поведінкою реальних користувачів.

***

Дизайн цифрових продуктів — обіцяний текст лекції з трьох частин:

1. Мета дизайнера цифрових продуктів
2. Роль дизайнера в продуктовій команді
3. Метод — як працювати над продуктом. Цей метод був описаний для дизайнерів в Альфі, щоб донести до новобранців суть роботи і очікування.

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

***

Трійка принципів: чим я часто керуюся в роботі над продуктом:

• Науковий метод
• Навпіл
• Найбільше, на що ви здатні

***

Інструкції або «Секретний секрет успішного успіху в успіху» — чому у вас не працює той, що працює в інших і як ми себе навчилися обманювати.

***

Пастка корпорації

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

***

Рекрутмент як продукт або «Ваня, знайди нам дизайнерів!» —

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

Пост я приправив посиланнями на всі артефакти процесу — наші пости, публікацію Молиноса, статтю в Комерсанті і так далі. Мені самому було цікаво порівняти те, як я думав рік тому з тим, що я написав через рік після запуску проекту. Цей феномен описаний в одній з наукових публікацій Умберто Еко, а тут я подивився як це працює на своєму прикладі. Цікаво.

***

Мій перший продукт —

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

***

І про спорт

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