Телеграм канал «interfaces.prjctr | hladynets week»

Тіме, щиро дякуємо за цей тиждень! Було змістовно й корисно. Сподіваємося, NDA не порушено 🤝️️️️️️

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

Будемо раді бачити тебе знову!
Залишаємо LinkedIn Тіма та залишаємося на звʼязку 💙

Що ж, от і підійшов мій тиждень до кінця. Був радий провести його із вами, сподіваюсь було цікаво.

Якщо щось - ось мій Linkedin, Insta та Medium, де я інколи публікую корисності.

Всім мирного неба 😌

Object-Oriented User Experience

Одну з двох книг у замовленні ще навіть не відправили читачеві, а система вже показувала статус «частково повернено».

Це був один із моментів, коли я зрозумів, що міграція бібліотеки KyivUX на Notion не буде легкою прогулянкою.

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

Так я думав, поки не почав будувати бази даних.

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

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

Тоді я й згадав про OOUX. Про Object-Oriented UX я колись читав у Софії Прейтер, але в реальному проєкті ще не застосовував. Схоже настав час.

Я відклав бази й описав бібліотеку через ORCA (Objects, Relationships, Calls-to-Action, Attributes). Виписав на стікери об'єкти, їхні атрибути, зв'язки й дії. Сформувати дії мені допоміг фреймворк CRUD. Так склалася модель із п'яти об'єктів: книги, примірники, читачі, замовлення та оренди.

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

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

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

Щойно об'єкти й зв'язки стали явними, статуси нарешті склалися. Замість латати помилки формулами, я описав правила, яким підкоряється вся система.

Ця модель визначила не лише структуру баз, а й інтерфейс читача. Сторінка книги на сайті - це по суті атрибути й дії об'єкта "Книга".

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

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

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

І жодна автоматизація не врятує, якщо ти сам до кінця не розумієш, як вона має працювати.

Дякую нашій чарівній засновниці KyivUX Тані Зав'яловій за довіру, а тіммейтам Богдану, Наталці, Олені, Вероніці й Карині - за час і сили, які вони знаходять для цього проєкту між work-life balance і тривогами.

Дуже подобається такі креативні інтро 😍
https://www.instagram.com/reel/DepBm5kCnJI/?exln=MTg4cGY2YWliMGlxcA==

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

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

Хочу показати два приклади, де ШІ допомагає вийти за межі звичних дизайн-інструментів.

Рефакторинг макетів

На обкладинці - приклад зміни структури навігації. Адаптувати один екран досить просто. Але як оновити сотні таких екранів без купи ручної роботи?

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

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

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

Прототипування

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

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

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

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

Але давайте не забувати, що токени коштують грошиків)

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

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

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

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

Готовий прототип можна розгорнути на хостингу на кшталт Netlify чи Vercel, захистити паролем від чужих очей і дати респондентам посилання. Усі дані в прототипі деперсоналізовані, а розміщення відповідає правилам безпеки організації.

Можна ще й аналітику прикрутити та збирати метрики.

А що з рештою задач?

Їх теж вистачає: ШІ допомагає нам підганяти чорнові тексти під ToV, шукати edge-кейси та критикувати дизайн-рішення.

У дослідженнях він допомагає з підбором методів і метрик, тематичним аналізом тощо.

Раніше для частини цих задач мені знадобилася б допомога розробника або значно більше часу.

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

А які сценарії використання ШІ прижилися у вас?