interfaces.prjctr | pasichnyk week

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

Ось і добіг кінця мій тиждень, сподіваюсь вам було корисно. Якщо що, пишіть — @safonov Та підписуйтесь на мій паблік @good_design_manager Це був цікавий досвід строчити по декілька раз на день))

Років 10 тому мені попався набір послідовних тверджень, який грунтовно пояснює, як працюють компанії і команди. 1) Продукт – це те, що компанія продає. Продукт – це те, що приносить їй гроші. Продукт — це не лише його форма (хоча більшість думають тільки про це), а й цільова аудиторія, цінність, просування та позиціонування на ринку. Без всього цього це непотрібна залізяка або набір коду. Продукт є в різних компаніях: - Для торгівельної — це зручність та швидкість постачання. - Для сервісної — послуга для клієнта. - Для аутсорсної — час і компетенції людей. - Для аутстафу — послуга зі зняття геморою в оформлені і організації праці людей. - В продуктовій компанії — фізичні або цифрові продукти. 2) Усі співробітники компанії працюють над створенням продукту. Кожен на своєму місці. Незалежно від позиції та спеціальності. Про це також часто забувають, що кожна людина в компаній (не тільки дизайнери, девелопери і менеджери) вносять свій вклад в створення продукту компанії. Десь або економлять гроші, або заробляють, або знімають певний геморой. Навіть родичі фаундера котрі можливо нічого не роблять, але в той же час десь при справі і це приносить йому спокій. Також це підводить до думки, що можна проаналізувати їх вплив і покращити його. 3) Спільне розуміння продукту дозволяє поєднувати зусилля всіх співробітників для досягнення більшого результату. Той самий alignment, або "узгодження" команди по цілях і задачах. Якщо команда не розуміє, навіщо вона щось робить, це просто руки, якими керує менеджер, котрий не завжди сам розуміє суть. Інвестиція в розуміння задачі дозволяє використовувати здібності команди, а не просто закривати мутний беклог. В Readdle ми це називали ‘stay on the same page’. 4) Співробітники будь-яких спеціальностей без розуміння продукту – це центр витрат. Співробітники з розумінням продукту стають центром прибутку. Ті, хто не розуміє продукту, витрачають гроші компанії на херню. Роблять мутний беклог з нікому не потрібних фічей, витрачають час на дії котрі не приносять продукту ніхера, використовують фреймворки які не мають сенсу в контексті. Ну і ті хто шарять що і навіщо робить компанія: можуть продертися через всі перепони, а також сфокусуватися і сфокусувати інших навколо дійсно важливих речей. 5) Розуміння продукту виражається в конкретних діях, спрямованих на покращення продукту. Тобто якщо ви не розумієте бізнес, продукт, ситуацію, і свою задачу — ви не покращуєте продукт. 6) Покращення продукту виражається в вимірюваних величинах – метриках, важливих для компанії на даний момент. Покращувати можна тільки те, що можна виміряти. Дата-дрівен мабуть перше, шо спаде всім на думку, але все значно простіше: шо конкретно нам дасть це покращення? 7) Кар’єрне зростання забезпечується не зростанням компетенцій, а збільшенням внеску в створення продукту. Не навчатись непотрібним компетенціям, а фокусуватися на корисних діях.

Говорили тут, як зрозуміти на співдесіді хороший менеджер чи таке-собі, ось ще підзібрав думок. У більшості випадків, з якими я стикаюся, команди й компанії промоутять до ролі головного дизайнера найсильнішого дизайнера. Але сильніший дизайнер — рідко сильніший менеджер. І таким чином можна одночасно втратити найкращого дизайнера й отримати слабкого менеджера. Іноді людина вже офіційно «керівник», але насправді — ні. Вона досі в минулій ролі, тільки тепер із додатковим чатом у Slack і купою зустрічей, які не розуміє, навіщо відвідує. Так народжується незрілий дизайн-менеджер. Не поганий, не токсичний, не лінивий. Просто не той, хто доріс до ролі. І, можливо, не той, хто взагалі хоче чи може її тягнути. І не те щоб є час рости й розвиватися — старі задачі забирають весь ресурс. Що він(вона) робить (або не робить) Він багато працює — це точно. Але не там, де треба. Бачив кейси шаленого нічного овертайму. Він тягне на себе складні або цікаві таски, бо «хто як не я». При цьому команді — фідбеку майже нема, ріст — спонтанний, пріоритети — не артикульовані. Але фігма відкрита, він «завжди поруч» і в курсі всього. Він уникає жорстких розмов. Бо незручно. Бо «це ж дорослі люди, самі розберуться». Делегує — але без зворотного зв’язку. Критикує — мимо контексту. Іноді підтримує, іноді знецінює. На зустрічах із продактами — пасивний. Або навпаки — занадто активний, захищаючи кожну піксельну ідею, бо це єдине, у чому впевнений. Ролі як такої він не побудував. Просто переклав її на плечі інших. На команду. Конкретніше 1. Звикнувши до ролі дизайнера, затягує з ухваленням менеджерських рішень, оскільки він відчуває більшу впевненість у дизайнерській роботі. 2. Критикує ідеї підлеглих, вважаючи свої рішення єдиними правильними. 3. Не вміє розподіляти робочий час між дизайнерськими задачами й менеджерськими обов'язками, що призводить до перевантаження і стресу. 4. Не приділяє достатньо часу людям, та не будує з ними комунікацію потрібного рівня. 5. Не надає підлеглим можливості професійного росту, тому що сам займається найскладнішими проєктами, та і не знає як ті можливості надавати. 6. Ігнорує важливість зворотного зв'язку — проблеми в команді залишаються невирішеними, а підлеглі не отримують конструктивної критики для свого розвитку. 7. Схильний до мікроменеджменту, оскільки він вважає, що знає краще, як виконати дизайнерські задачі. 8. Цінує свою роботу як дизайнера більше, ніж роботу своєї команди. 9. Не встановлює рамки та очікування. Команда живе в режимі «самоорганізації», тому що ніхто не пояснив, що і як очікується. 10. Приймає все «згори», не фільтрує, не виступає буфером, не зменшує навантаження. Або навпаки — конфліктує з усіма навколо. 11. Не будує прозорість в комунікації. Може щось знати, але не ділиться. Може щось пообіцяти, але не фіксує. 12. Не бачить проблем, поки не палає. Все окей, поки люди не йдуть, поки не зривається дедлайн, поки не приходить продакт із претензіями. Що відбувається з командою З боку може здаватися, що все працює. Але всередині — повільна деградація. Команда не росте, бо немає для цього умов. Ніхто не впевнений, що таке «добре», бо ніхто не сказав. Комунікація з іншими функціями — вкрай складна. Мотивація — хаотична. Системи нема, рішення ситуативні, пріоритети змінюються. Одні стараються, інші пасують, а результат — непередбачуваний. В команді зростає недовіра — бо людям незрозуміло, на що спиратись. Хто виплив — з часом стає токсік і зневажливим до тих, хто не витягує. Можливо, ви впізнали себе. А може — свого менеджера. Хороша новина: ніхто не заважає вам працювати над собою.

Чи повинен дизайн бути красивим? Розповсюджений топік в нас на курсі по дизайн-менеджменту і менторшип-сесіях, це як боротись з іншими відділами за якість і красоту дизайну. Справа звісно благородна, але в переважній більшості випадків дизайн-лідери не намагаються розібратися звідки береться ця боротьба, і нафіга їм самим взагалі той КРАСИВИЙ ДИЗАЙН. Красивий дизайн Краса це питання мистецтва. Краса в дизайні недосяжна. Красивий дизайн це один з варіантів ринкової диференціації, котрий потрібен не такий великій кількості бізнесів і продуктів. Сказати шо він потрібен абсолютно всім, це брехати самому собі. Давайте згадаємо хто з відомих продуктів використовує дизайн як диференціацію: Apple, Craft.do, всі продукти MacPaw, Mono. А скільки ще успішних продуктів ви цінуєте взагалі не за дизайн? Reddit, Stripe, LinkedIn, Discord, Zoom. Якщо ви починаєте цю субʼєктивну гру в красу дизайну, то чому б її не почати і вашим колегам недизайнерам. Той рівень краси, котрий дизайнер зазвичай бажає — не потрібен а ні бізнесу, а ні користувачу, а ні колегам. Ніхто з них не помітить тієї різниці і не зацінить рівень. Еволюція якості Досягнення якості, по-перше, повинно відповідати цілям вашим та компанії, а по-друге — це еволюція. Я виділив для себе наступні фази еволюції продукту і бізнесу: 1. Корисно — те шо ви робите, має сенс, вирішує проблему. 2. Рівно. Якщо користь вже є, можна зробити все більш менш рівно, шоб нормально виглядало. Корисний і рівний продукт, це вже заявочка на успіх з усіх боків — і більшість відомих нам продуктів знаходиться на цьому етапі. 3. Зручно. Корисний і рівний продукт вже може нормально заробляти і витрачати багато часу і грошей на підвищення зручності. 4. Захоплення/насолода/delight. На цьому етапі вже можна упоротись і додати в продукт емоції через анімації, звуки, вібрації, мікрореакції, пасхалочки і все шо може викликати захват. Всі успішні продукти в яких я працював, проходили по цих етапах. Ті які зафейлилися, намагались перескочити і пропустити якісь етапи. Тож якщо ви боретесь за красу, варто розібратися — нащо ви це робите. А тоді і боротись буде легше.

5 типових помилок дизайнерів, котрі я регулярно бачу 1. Гонитва за ідеалом Багато дизайнерів (в шикрокому сенсі) думають, що їхня робота — зробити ідеально. І дуже засмучуються, коли це не виходить. Насправді головне — створити рішення, яке принесе цінність бізнесу і клієнтам. Ідеальність — це утопія. До того ж субʼєктивна — навіть самі дизайнери не можуть між собою домовитися в тому що таке "ідеально". В реальному світі важливо тестувати, адаптуватися і знаходити компроміси, які вирішують проблеми і приносять гроші. І з кожним роком це потрібно робити значно швидше. 2. Ілюзія можливості довгострокового рішення Деякі дизайнери вважають, що можуть спроектувати щось “на роки” — інтерфейс, інфраструктуру, дизайн-систему. Легко і невимушено зробити так, щоб проблема більше ніколи не зʼявилася. Зекономити собі-майбутньому купу грошей. Але реальність така, що: - Продуктові стратегії змінюються швидше, ніж здається. - Команда сьогодні і команда через рік — це різні рівні експертизи і часто різні люди. Під час скейлу, наймають нових спеціалістів з досвідом більшого масштабу. - Якщо продукт буде успішним, у компанії з’являться ресурси на вирішення проблем масштабування. Я бачив, як дизайнери витрачали купу часу на можливість перекладу інтерфейсу на всі мови — а продукт навіть не дожив до релізу. Те ж саме з дизайн-системами: вони все одно будуть змінюватися. Ніхто не знає, які проблеми з’являться через кілька років, а передбачати їх усі — марна трата часу. Цей час можна було б направити на каст-дев, тестування більшої кількості гіпотез по продакт-маркет фіту і т.д. 3. Передача відповідальності менеджерам Багато хто сліпо приймає пріоритети, які дає менеджмент, не вникаючи в контекст. Менеджери приймають рішення не тільки виходячи з доступної інформації і бізнесових реалій, а і своїх упереджень, упереджень їх менеджерів, настрою, ідолопоклонництву данним або фреймворкам, і тд. Якщо команда не ставить правильні питання і не допомагає уточнити мотивацію рішень — виходять дурниці, а час і енергія людей вилітають в трубу. Ваша кар’єра і результати напряму залежать від того, наскільки інші добре роблять свою роботу. Чи хочеться вам грати в лотерею на роки свого життя і карʼєру? 4. Думка, що дизайн говорить сам за себе Будь-яку ідею треба продати і пояснити її цінність — інакше ніхто з команди її не зрозуміє і не "купить". Як результат буде "я запропонував класну ідею, але ніхто з команди її не підтримав, їм не має сенсу нічого пропонувати". Світ змінюється: людям буде важливо не те, наскільки ви вмієте користуватися тулами, а наскільки у вас є власне бачення, наскільки ви можете його продати, реалізувати разом із розробниками і допушити все до результату. 5. Відсутність (розуміння) пріоритезації Я бачу, що багато хто сприймає успіх як "зробити все" з беклогу. Тобто це або "0", або "1". Нещодавно на лекції задавали питання щодо дизайн боргу, мовляв список багів і проблем величезний, але менеджмент на нього не зважає, а девелопери теж не рухаються, бо “якщо це не хвилює менеджерів, то нам яка різниця?”. Я вважаю, що проблема тут в тому, що дизайнери хочуть закрити весь список, замість того щоб визначити ключові проблеми, які реально впливають на бізнес, і сфокусуватися тільки на них. А треба було б знайти їм підходящу аргументацію і час. Може в вас є ще щось на думці цікаве?

Дизайн — це найдешевший спосіб зазирнути у майбутнє. Шо це означає? Якщо сприймати дизайн просто як «роботу руками», він зводиться до технічного створення макетів на замовлення. У такому підході дизайнер — це виконавець чужих ідей, а запит від менеджменту виглядає як “намалюй мені отак.” Це обмежує не лише можливості команди, але й потенціал самої компанії, бо дизайн зводиться до механіки, а не до мислення. Але якщо сприймати дизайн як засіб заглянути в майбутнє, усе змінюється. Це вже не просто створення макетів — це процес пошуку, валідації ітерацій найкращого варіанту майбутнього. Тут запит до дизайнера чи команди вже звучить інакше: «Як взагалі ця штука може виглядати?» «Як ми можемо зробити її краще?» «Що допоможе нам досягти наших бізнес-цілей?» У такому підході дизайн стає не інструментом виконання, а способом дослідження і прийняття рішень. Це про стратегію, не про декор. Що ще? Експериментальний дух Дизайн дозволяє “факапити швидко і дешево” (fail fast), але зробити це з розумінням причин. Як там в Google ventures design spring. Замість Idea — Build — Launch — Learn, одразу Idea — Learn. Як сказали мені якось на одному курсі: «Приготуйтеся: ми будемо багато факапити». Дизайнер-візіонер і дизайнер-виконавець Роль дизайнера не завжди однозначна. На різних етапах проєкту і навіть на різних задачах дизайнер може бути: 1. Візіонером, який генерує нові ідеї, ставить питання, що кидають виклик статус-кво, і прокладає шлях до майбутнього. 2. Виконавцем, який реалізує бачення, запропоноване бізнесом, менеджерами чи іншими членами команди. 3. Обидві ролі одразу, коли він одночасно розробляє рішення від себе і рішення від інших. А потім скоріш за все з обох результатів береться найкраще. Дизайн — це інструмент не тільки реалізації, але й формування майбутнього. І саме здатність змінювати свою роль (від візіонера до виконавця і назад) робить дизайнерів і цінними, і складними одночасно. Мотиваційний аспект Коли вимогливий замовник, чи менеджер дає вам чіткий віжн під проробку, це не обовʼязково мікроменеджмент і нерозуміння ролі дизайну (хоча часто і вони). Просто в нього є баченя майбунього, і гроші на спробу його реалізувати. В такій перспективі, робота дизайнера допомагає матеріалізувати це бачення, і очевидно роль і задача стає важливіше ніж «нафігачити макетів». Робота в стіл В такій перспективі робити макети і прототипи в стіл, і ні де їх не використати — перестає бути проблемою. Ви моделювали майбутнє, і воно вам не сподобалось, упс. Бізнес-цінність Ця ідея може допомогти менеджерам і топам компанії бачити дизайн як бізнес-інструмент, а не як витрати. Вона спрощує пояснення вартості дизайн-роботи і отримання підтримки для дизайн-команд. Можливість подивитись в майбутнє має стратегічну цінність. А дизайн не просто дивиться в майбутнє, а будує місток до цього майбутнього. Партнерство і комунікація Дизайн дозволяє знизити рівень напруги у стосунках із клієнтами і всередині команди, бо через візуальні рішення простіше пояснити ідеї. Інколи не потрібні і макети, достатньо заворкшопити і заалайнити всіх в фіг-джемі. Інші способи зазирнути в майбутнє Доречі, різні фреймворки, такі як Lean Canvas, Business Model Canvas, та будь-які інструменти моделювання — це теж спосіб “зазирнути в майбутнє,” але на концептуальному рівні. Дизайн, у цьому контексті, є практичним продовженням цього процесу, що дозволяє візуалізувати і тестувати ідеї у формі продуктів, послуг чи інтерфейсів.

Вихідні хороший час шоб почитати, тож порекомендую шось Мета. Процес безперервного вдосконалення Джефф Кокс, Еліягу Ґолдратт Якби я міг порекомендувати тільки одну книжку, то це була б вона. Це основа основ, на ній земля тримається. Вона одночасно є художнью книжкою — про життя героя і проблеми з якими він стикається (постійно), а також бізнесовою — з глибоким пояненням тонкощів "як прикладати зусилля до справді важливих речей з максимальним імпактом”. Теорія обмежень стверджує, що в кожній системі існує щонайменше одне ключове обмеження, яке визначає максимальний темп продуктивності або ефективності системи. Тобто воно сповільює темп і рух всієї компанії. І якщо працювати не над ним, то результативність буде лайно. Як коли вирішуєш не ті проблеми котрі потрібно, а ті котрі розумієш як. Навчила мене правильно вибирати точку зусиль.

Цікаво, як би зрозуміти що перед тобою хороший менеджер на етапі інтерв’ю? Якщо ти на етапі вибору роботи чи команди — звертай увагу не тільки на бренд, продукт або зарплату. Інтервʼю — це не тільки ти на співбесіді, це ще й шанс перевірити, хто буде вести команду. На що звернути увагу: 1/ Як говорить про команду. Якщо більшість історій про те, як він сам зробив складний дизайн — це скоріше сильний дизайнер, а не менеджер. Хороший менеджер більше говорить про людей, їх ріст і результати команди. 2/ Як описує свою роль. Якщо роль зводиться до “контролю якості дизайну”, часто це означає, що він досі працює як дизайнер. Менеджер зазвичай говорить про пріоритети, розвиток людей, комунікацію з продуктом і бізнесом. Якщо це лід-дизайнер, то тут зазвичай розповідь десь 50/50. 3/ Як говорить про складні ситуації. Наприклад: конфлікти, слабкі перформанси, зміну пріоритетів. Якщо у відповідях є конкретні приклади — це хороший знак. 4/ Чи є чіткі очікування. Хороший менеджер може пояснити, що означає “хороша робота” в його команді і як люди ростуть. І на співбесіді може чітко сказати, кого саме шукають і під які задачі, а не просто “шукаємо сильного дизайнера”. Які ще сигнали можуть бути 5/ Може пояснити, як приймаються рішення. Хороший менеджер може описати процес: як команда вирішує, що робити, як пріоритизуються задачі, як проходять дизайн-рев’ю. 6/ Говорить про розвиток людей. Якщо менеджер не може пояснити, як ростуть дизайнери в команді — часто це означає, що системи росту просто нема. 7/ Визнає складність менеджерської ролі. Хороші менеджери зазвичай відкрито говорять про складні ситуації: конфлікти, слабкий перформанс, помилки. 8/ Говорить про взаємодію з продуктом і бізнесом. Менеджер зазвичай багато говорить про роботу з PM, engineering, пріоритети продукту. Взаємодія з партнерами, це те що зазвичай точно питають коли беруть менеджерів на роботу — бо це ключова частина роботи. 9/ Не уникає теми фідбеку. Якщо тема фідбеку звучить абстрактно або дуже загально — часто це означає, що його дають нерегулярно. Питання, які варто задати на інтерв’ю Про роль менеджера - Як виглядає ваша роль у команді? - Скільки часу ви витрачаєте на менеджмент і скільки на дизайн? Про розвиток людей - Як ви допомагаєте дизайнерам рости? - Як виглядає шлях від middle до senior у вашій команді? Про фідбек - Як часто ви проводите 1-1? - Як зазвичай виглядає дизайн-рев’ю? Про прийняття рішень - Як у команді приймаються дизайн-рішення? - Хто зазвичай ставить пріоритети для дизайнерів? Про складні ситуації - Можете розповісти про ситуацію, коли дизайнер у команді не справлявся? - Як ви вирішуєте конфлікти між дизайном і продуктом? Про очікування - Що означає “хороша робота” для дизайнера у вашій команді? - За що дизайнер у вас може отримати підвищення? - Уявімо що ви мене взяли, і я класно справився — як це виглядає? Ідеально буде також написати в лінкедині і спитати поточну команду шо їм і як. Хтось не відповість, хтось відповість. Якщо команда вже на грані — вам точно відпишуть і точно натякнуть. Ось що має насторожити або навпаки — надихнути: - Чи виростив цей менеджер когось помітного? - Чи може чітко сформулювати, як розвиває людей? - Чи відгукуються тобі люди, які вже з ним працювали? - Чи є в нього/неї бачення, що буде з тобою і роллю за рік? - Чи є за останній рік-два якісь помітні перемоги, чи все херня якась? - Чи це цей менеджер не "жорсткий, але справедливий", як батя з ПТСР? Якщо маєш змогу вибирати — вибирай менеджера, не офер. А і ще хто проходив мій з колегою паном Іваном курс по дизайн-менеджменту в Проджі теж втягнулись в двіж.

Суботній чіловий байт на коменти: Який вам згадується один з ваших найбільших дизайнерських факапи? Почну з себе На першій дизайнерській фултайм роботі, мені повезло розжитись 27-дюймовим маком. В якийсь момент я знайшов в ньому налаштування "підвищити скейл всього на екрані" чи шось таке, і подумав "о клас, я тепер буду краще бачити, інтерфейс скетча стане більше". Через якийсь час я помітив шо я намалював якийсь крупнуватий продукт, все таке велике, і фонти, і іконки, і елементи... Шось я трохи провтикав.. І перемалював на менше поки був час. А потім до мене прийшла команда і каже "слухай а тут заверстали ми нарешті все і чо воно таке мікроскопічне?". Коротше так я поняв шо той скейл мені не тільки інтерфейс збільшив, а взагалі все на екрані. Довелось швидко перемальовувати все назад. З тих пір я зі скейлами не граюсь.

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

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

Зайшов слайд зі старої лекції про лідершип)

З бісяків ще добротних: "коли вкладаєш кіпу часу і сил у супер пупер важливу фічу, і тут зненацька виявляється, що вона більше не пріоритет, її відкладають у довгий ящик і потім так і не імплементують" "задачі на вчора і ніхто не знає що потрібно але потрібно вже)" І ще пакован подібних на тему херового планування. Це дуже популярна штука. В тому чи іншому ступені така проблема у всіх. Це одразу і проблема планувального скіла, і фокусу, і освіти, і настрою. Скіл Є купа технік планування, про котрі всі чули, але ніхто не використовує. Особливо печально коли це не роблять менеджери. З того що в мене постійно під рукою це колбаски діаграм ганта і візуалізовані дедлайни. Шоб розуміти що в нас коли, і скільки часу є. Це мені допомагає розтягнути процес з "нам на завтра, робим як вийде", до "так, через півтора місяці нам треба віддати таку фічу, давайте поки шо ковирнемо досвід користувачів повільно". Також це допомагає не ломать процес дедлайнів. Але для цього мені доводиться проводити багато розвідувальної роботи. Бо якщо ви тільки дізналися про якийсь дедлайн чи задачу, то хтось про нього точно знав раніше — питання хто, і як з нього це вчасно дістати. Знаю команди які працюють з дизайном для конференцій і все роблять з горящею сракою в останній момент. Хоча план конференцій зазвичай закладається мінімум на рік вперед. Фокус Ой та шо то планування, є купа питань гарячих шо зараз треба рішать. Планування це тактична і стратегічна діяльність, а людям зазвичай простіше вирішувати проблеми по мірі їх появлення. Тут дзвінок, там спитали, тут задачка срочна. Це треба окремо качати і пушити. Освіта Люди люблять фокусуватися на зрозумілому. Я виділяю 4 стовпи де можна упоротися. Дата-дрівен — дата це головне, вона нам все скаже, як дата скаже так і зробимо. Якщо не вийшло — ну то дата була погана. Юзер-дрівен — юзери головне, вони все скажуть, ми їх спитаємо. Якщо фіча провалилась — ну юзери просто сказали так, а ми шо ми нічо. Фреймворк-дрівен — зараз все зробимо по аджайлу/дабл-даймонду чи ще чимось і буде топ! Просто слідуємо за процесом. Віжн-дрівен — я так бачу, давайте так робить, або фаундер сказав. Я думаю шо driven це не підхід в загалі. Це все дає якусь інформацію, але рішення треба приймати нам. Тому для мене основний підхід — informed. Але людей котрі фокусуються більше ніж на одному тулі — одиниці. Настрою Банально якшо людина демотивована, або задрочена, ій буде важко приділяти увагу плануванню. Є просто грусні люди, котрим все по життю не цікаво і не треба. Моя позиція яка, і вона мені впринципі і драйвила всю мою карʼєру, це розбиратись і виясняти це все самому. Бо я тревожник ще, мені треба знати заздалегіть і готуватись. Бо чи готові ви в цій ситуації, людям котрі міксують всі ці фактори довірити свій розвиток, свою карʼєру, свій дохід, роки життя, і свою менталочку? Я — ні.

Пʼятничний клікбейт поки я роздуплюсь: Хто для вас такий Senior designer? Чим відрізняється від попередніх рівнів?

Попушу ще темку розвитку через еволюцію дизайнера, через способи думати Тема розвитку складна, її важко аналізувати, і ще важче екзекьютити. Але вона ключова і впливає на все інше. У більшості компаній розвиток дизайнера формально виглядає як перехід між тайтлами чи грейдами. Але в реальності це майже нічого не означає. Хтось має класний тайтл, але мислить як сервісний виконавець, а хтось без тайтла впливає на продукт більше, ніж ціла команда. Ось моя версія руху. 1/ Сервісний рівень (Craft / Execution) Навчися робити свою роботу нормально і не мучити команду. Людина швидко робить макети, розуміє дизайн-патерни. Вона стабільна, прогнозована і не створює проблем. По суті це про "робити свою довбану роботу". Багато хто не досягає і цого рівня: створюють проблеми і конфлікти для команди, роблять херові макети, приймають рішення котрі потім потребують дофіга правок. Мислення зводиться до екранів, або невеликих флоу, потрібна більш-менш чітка задача, впевненість спирається на тули, робота це “намалювати, узгодити, передати”. Проблема в тому, що на цьому рівні складно зрозуміти, ЧОМУ взагалі ми робимо саме це завдання. І саме тому більшість дизайнерів ніколи не виходять за межу “виконавця”. Ще доречі класичний паттерн для цього рівня, це "екзеки і менеджери не шарять, ніхто нічого не вміє". 2/ Продуктовий рівень (Problem-solving / Partner) "Розумію, що ми робимо і навіщо. Можу бути партнером продукту." На цьому рівні дизайнер перестає чекати чітких інструкцій. Він починає формулювати завдання разом з продуктом. Цей рівень легко переплутати з попереднім, бо "намалювати, узгодити, передати" може відчуватись як "формулювати завдання разом з продуктом". Дизайнер починає працювати з поведінкою, сценаріями, метриками, пропонує варіанти рішень, а не один варіант макету, думає через причинно-наслідкові зв’язки. Це рівень, де з’являється справжнє партнерство і дизайнер починає впливати на продукт, а не тільки на інтерфейс. Як перейти далі: побачити систему, а не окрему фічу. Навчитися аргументовано пояснювати чому певні задачі мають сенс. 3/ Системний рівень (Enabler) “Створюю умови, в яких вся команда працює краще.” Це рівень, де дизайнер перестає бути індивідуальним виконавцем. Він стає тим, хто будує основу для роботи інших. Мова не про управління людьми, а про вплив на систему: процеси, стандарти, прозорість рішень, швидкість і передбачуванність роботи команди, зменшення ризиків для компанії. На цьому рівні дизайнер бачить команду і продукт як єдиний механізм. Це про організаційний вплив. Як перейти далі: почати працювати з “навіщо”. Навчитися ризикам, пріоритизації, сценарному мисленню. 4/ Стратегічний рівень (Vision / Direction) “Визначаю, які проблеми варто вирішувати. Допомагаю команді рухатися в правильний бік.” Це рівень, де дизайнер впливає не на UI, не на процес і навіть не на команду, а на напрямок продукту. Це про формування бачення, аналіз ринку і конкурентів (не той шо на рівні крафту "шо можна поцупити"), розуміння бізнес-моделі і P&L, роботу зі ставками та ризиками, створення ясності у ситуаціях невизначеності. Як рости далі: навчитись аргументувати рішення мовою грошей, ризиків і сценаріїв. Бачити наслідки, а не тільки можливості. Що насправді рухає дизайнерів вперед Не Figma і навіть не UX-методи. Рухає здатність бачити проблему, а не екран, здатність створювати ясність, здатність зменшувати ризики, здатність бачити наслідки рішень, вміння думати ширше, ніж власна задача, відповідальність за продукт, а не за макет. Кожен новий рівень — це не набір навичок, а зміна способу мислення. Дизайнерам часто здається, що вони вже мислять стратегічно і “бачать ширше”, бо користуються методами, фреймворками чи тестами, чи подивилися багато рефів. Але це все одно робота на рівні екранів. І те саме з відповідальністю: її не видає компанія, її беруть самостійно, коли починають розв’язувати проблеми, які ще ніхто не формулював.

Так з бісяків випливає шо непогано би розібратись шо таке "нормальна робота" Темп і ритм Комусь потрібен спокій, час на подумати. Комусь важливий драйв і шалений темп. Після вигорання хочеться передишки. Після стагнації — руху. Мені вже давно хочеться двіжу і як ніяк його не знайду. Але теж, крайності швидко приводять до проблем. Команда і взаємодія Адекватні люди, яким не все одно, — безцінно. Там де культивується байдужість або мікроагресія теж можна довго протриматись, але блін... Чи є в команді люди, з якими цікаво? Сенс і місія Чи не шкода витрачати сили на те, що робить світ гіршим? Не кожен проєкт має рятувати планету, але хоча б не погано було б не бути повною дичиною. Мало хто хоче шоб йому було соромно розказувати про свою роботу. Фаундери, C-level, менеджмент Чи роблять свою частину роботи? Чи ховаються від рішень? Чи є бачення і фокус — чи постійні “повороти” і стратегії раз на тиждень? Без “несучої конструкції” навіть найкращі команди починають хитатись. Гроші і визнання Наче ніхто не йде працювати за «недостойну оплату», але тут теж є свої компроміси. Багато людей вибирають спокій і стабільність, за невеликі гроші. Розвиток Розвиток “для галочки” наче зараз є скрізь: курси, нові задачі, нові ролі. Але чи ти ростеш у тому напрямку, який тобі потрібен? Можливість впливати Відчуття впливу — один із факторів мотивації. Коли все “спускається згори”, швидко втрачаєш бажання і енергію шось робити. Чи є місце для ідей, ініціатив, зворотного зв’язку? Прозорість і комунікація Розумієш, що вібдувається в компаніх? Як тебе оцінюють? Які в тебе перспективи? Що зараз пріоритет? Якщо ні — включається “тривожний режим”, навіть коли все інше нормально. Процеси і порядок Не всі хочуть структури, не всі хочуть свободи. Але важливо, щоб команда сама розуміла, де вона. Ідеально — коли хаос визнано, і є план його приборкати. А не коли “все летить” і це називається “динамічне середовище”. Емоційна безпека Чи можна сказати “я не знаю”? Чи можна обговорити фейл без страху? Зріле середовище не вдає, що всі ідеальні.

З вчорашніх бісяків: Бісять темпи з якими несеться розвиток АІ в нашій галузі. Поки в мене дійшли руки щось вивчити/освоїти, це вже стає неактуальним. Теж бісить)) Але я заспокоюю тут себе тим, що може якщо шось стає неактуальним то і хорошо, значить не витратили час зря. Якщо в будь-яку новацію вриваться, це ж часу не лишиться на життя. Є в продуктовому менеджменті є така темка як Крива адопшну іновацій. Є 2,5 відсоткі іноваторів котри вриваються у все новеньке, і шукають як це використовувати-приміняти. Памʼятаєте тіх кто купляв окуляри від Епла наприклад. Ну чи зараз АІшкі які зʼявилися ось прям сьогодні. Потім ранні адоптери, їх вже трохи більше. І в них там є великий провал, котрий означає для продуктів шо технологія могла не прижитися і не піти далі в народ. Ну а далі вже більш популярні "рання більшість", "пізня більшість", і відстаючі. От мені з АІшкою норм десь в ранній більшості, коли і якісь відоси зʼявляються, і стає більш зрозуміло як для себе користь отримати.

Трохи ранкового клікбейту, поки я тулю дітей до школи: А шо вам подобається в вашій роботі? Вам же шось подобається, правда?

Рубріка Бісяків з коментів: Компанії шукають продуктового дизайнера без розуміння, нащо він їм потрібен, бо все зводиться до виконання інтерфейсу за бажанням замовника (було таке в досвіді) Зневага до досліджень, виконання задач завжди пріоритетніше Постійні обіцянки «так, ми відкриті до твоїх пропозицій і ініціатив» які насправді нічого не означають, бо проект все одно не збирається приділяти багато часу дослідженням, тестуванню чи будь-якій іншій активності окрім крафту у фігмі По пошуку: Так є купа компаній котрі шукають юай-юекс діза, простого виконавця, але називають це по модному "продакт дизайнер". Звідки в них зʼявиться розуміння, що це таке, якщо вони ніколи не бачили)) Згоден бісить, треба задавати питання. Ну і шо б це був реальний продукт звісно. Про зневагу до досліджень: Хороша темка, клас. Ну поперше звідки повинна взятися повага до досліджень? Дослідження вирішують проблему. Якщо є ризиковане рішення, і ризик буде коштувати багато грошей — логічним кроком буде шось досліджувати. Але при цьому, може бути людина, котра готова брати на себе цей ризик. Може вона звісно просто не розуміє шо робить, але це проблема того хто її туди ставив. Проблема більшості дизайнерів в тому, що вони думають шо рафінований процес дослідження котрий вони вивчили на курсах, підійде для будь-якого кейсу і для будь-якої компанії. Звідси йде і зневага, бо команда бачить шо людина не розуміє що пропонує. Виконання задач звісно завжди пріоритетніше. Але якщо дослідження частина задачі.... Сьогодні обговорював з командою, що вони зробили 5 класних досліджень за лютий, і дизайнер каже "ну так нам ніхто не забороняв і не ставив палки в колеса..". А я кажу "це не тому що всі добрі, а тому що ці дослідження не ламали процес і не зривали строки". Тобто якщо їх коректно інтегрувати в роботу — все стає одразу на свої місця. Про обіцянки і ініціативу: Ох, це популярний бісяк, але він впирається на мій погляд в мачуріті дизайнера. Люди собі як це представляють, що можна запропонувати будь-що, не думати про практичну сторону, а потім це стане проблемою тих кому ідея була озвучена. Тому коли йдеться мова про "ми відкриті" то це значить ще "до практичних, продуманих і адекватних". І отут ключовий конфлікт.