Менше кліків не завжди легше
З 1890 року, відколи Вільям Джеймс описав увагу як зусилля, дослідження раз у раз підтверджують: розумове зусилля обмежене, людина його відчуває і намагається уникати. Тож цілком логічно, що ми дедалі більше розвантажуємо голову. Що складніший світ, то більше доводиться тримати в пам'яті, і це заважає залишатись ефективним. Та й сенсу пам'ятати все немає. Частину цієї роботи ми виносимо в нотатки, автоматизуємо, делегуємо інтерфейсам - адаптуємось під реалії.
І саме тут починається ергономіка. Для мене вона про ціну, яку людина платить за кожну дію в інтерфейсі рухом руки, увагою, пам'яттю. А недооцінити її легко, бо найпростіше рахувати кліки. Але клік фіксує тільки сам факт дії. Що людина мусила перед ним пригадати чи обдумати, в аналітиці ми цього не побачимо. Ми з Ольгою Тушич вже писали про це в блозі Rozetka Pay, те ж саме я побачив на власному тесті з користувачами.
Ми переносили в новий кабінет ПУМБ Бізнес друк по дві платіжки на сторінку. Бухгалтери великих компаній давно про нього просили: менше паперу і вдвічі легший PDF. Я зробив два варіанти.
- Дві іконки принтера з цифрами 1 і 2, друк в один клік, як у старому кабінеті.
- Одна кнопка принтера, яка відкриває список з пунктами «Друкувати по 1 платіжці на сторінку» і «Друкувати по 2 платіжки на сторінку». Тобто два кліки.
У Maze кожен варіант проходила своя гомогенна група з 20 людей. Завдання виконали всі, і оцінили обидва варіанти майже однаково. Але з меню люди впорались на 21,6 с швидше (27,7 секунди проти 49,3 с з двома окремими іконками).
По тепловій карті я зрозумів, чому так відбувалось. Люди виділяли платіжки, знімали виділення, поки не лишалось рівно дві, і тільки тоді натискали на іконку друку з цифрою 2. Припускаю, що вони сприймали цифру 2 в іконці друку як лічильник виділених рядків. Тултіп про значення цих іконок з'являвся лише при наведенні. А от у випадаючому меню підпис видно одразу, його досить легко розпізнати. Іконку ж цифрою треба було розгадувати, і замість швидкого автоматичного мислення вмикалось повільне. Тому один клік когнітивно коштував людям більше, ніж два.
Іконки з цифрами всередині повторювали старий кабінет, тож для частини клієнтів вони знайоміші. Але більшість уже працює в новому, а нові клієнти старого не бачили взагалі. Ми ж проєктували інтерфейс, який буде зрозумілий для всіх. Я очікую, що ті, хто звик до іконок, звикнуть і до меню.
Після релізу минуло три місяці. Жодної скарги на друк ні в підтримці, ні в NPS. Аналітику тут ми міряти не можемо через комплаєнс нажаль, але це вже хороший знак.
Що я виніс: перш ніж оптимізовувати кількість кліків варто порахувати, що людині доведеться для цього пригадувати, розгадувати й перевіряти. Частину цих зусиль можна оцінити ще до тесту. Курс Projector UX Design Advanced познайомив мене з предиктивною моделлю GOMS, і тепер я ще до того, як запускати тестування з реальними користувачами можу порахувати мінімальний час виконання завдання для кожного варіанту дизайну.
Це звісно ж не остаточний доказ, а всього лиш бенчмарка, яка допоможе сформувати припущення 😉
З 1890 року, відколи Вільям Джеймс описав увагу як зусилля, дослідження раз у раз підтверджують: розумове зусилля обмежене, людина його відчуває і намагається уникати. Тож цілком логічно, що ми дедалі більше розвантажуємо голову. Що складніший світ, то більше доводиться тримати в пам'яті, і це заважає залишатись ефективним. Та й сенсу пам'ятати все немає. Частину цієї роботи ми виносимо в нотатки, автоматизуємо, делегуємо інтерфейсам - адаптуємось під реалії.
І саме тут починається ергономіка. Для мене вона про ціну, яку людина платить за кожну дію в інтерфейсі рухом руки, увагою, пам'яттю. А недооцінити її легко, бо найпростіше рахувати кліки. Але клік фіксує тільки сам факт дії. Що людина мусила перед ним пригадати чи обдумати, в аналітиці ми цього не побачимо. Ми з Ольгою Тушич вже писали про це в блозі Rozetka Pay, те ж саме я побачив на власному тесті з користувачами.
Ми переносили в новий кабінет ПУМБ Бізнес друк по дві платіжки на сторінку. Бухгалтери великих компаній давно про нього просили: менше паперу і вдвічі легший PDF. Я зробив два варіанти.
- Дві іконки принтера з цифрами 1 і 2, друк в один клік, як у старому кабінеті.
- Одна кнопка принтера, яка відкриває список з пунктами «Друкувати по 1 платіжці на сторінку» і «Друкувати по 2 платіжки на сторінку». Тобто два кліки.
У Maze кожен варіант проходила своя гомогенна група з 20 людей. Завдання виконали всі, і оцінили обидва варіанти майже однаково. Але з меню люди впорались на 21,6 с швидше (27,7 секунди проти 49,3 с з двома окремими іконками).
По тепловій карті я зрозумів, чому так відбувалось. Люди виділяли платіжки, знімали виділення, поки не лишалось рівно дві, і тільки тоді натискали на іконку друку з цифрою 2. Припускаю, що вони сприймали цифру 2 в іконці друку як лічильник виділених рядків. Тултіп про значення цих іконок з'являвся лише при наведенні. А от у випадаючому меню підпис видно одразу, його досить легко розпізнати. Іконку ж цифрою треба було розгадувати, і замість швидкого автоматичного мислення вмикалось повільне. Тому один клік когнітивно коштував людям більше, ніж два.
Іконки з цифрами всередині повторювали старий кабінет, тож для частини клієнтів вони знайоміші. Але більшість уже працює в новому, а нові клієнти старого не бачили взагалі. Ми ж проєктували інтерфейс, який буде зрозумілий для всіх. Я очікую, що ті, хто звик до іконок, звикнуть і до меню.
Після релізу минуло три місяці. Жодної скарги на друк ні в підтримці, ні в NPS. Аналітику тут ми міряти не можемо через комплаєнс нажаль, але це вже хороший знак.
Що я виніс: перш ніж оптимізовувати кількість кліків варто порахувати, що людині доведеться для цього пригадувати, розгадувати й перевіряти. Частину цих зусиль можна оцінити ще до тесту. Курс Projector UX Design Advanced познайомив мене з предиктивною моделлю GOMS, і тепер я ще до того, як запускати тестування з реальними користувачами можу порахувати мінімальний час виконання завдання для кожного варіанту дизайну.
Це звісно ж не остаточний доказ, а всього лиш бенчмарка, яка допоможе сформувати припущення 😉
🔥5❤2👍2
Доречі, я тут забігався - а через 6 хв стартує Мітап про Accessibility від ГО "Доступність Цифрова".
Тема - "Тулзи для Digital Accessibility".
Залітайте - Ось тут міт
Тема - "Тулзи для Digital Accessibility".
Залітайте - Ось тут міт
🔥4
Точити ляси це теж робота
Мій звичайний день починається з двох дейліків поспіль, бо я працюю у двох командах одночасно. Далі сінк із QA і фронтом по поточній задачі, обід, ще пара дзвінків, і десь о 17:00 я закриваю останній мітинг. На сам проєкт часу вже не лишилось 😄
Дзвінки забирають від пари годин до шести на день. Звучить як жах, особливо для інтроверта. Але в ПУМБ працює дофіга людей, і без частих розмов цей корабель просто не полетить. Таке собі необхідне «зло». А для дизайнера ще й спосіб вплинути на рішення: коли з PO та аналітиками ми розбираємо нову задачу, я дивлюся на аналіз і бізнес-схеми та бачу, де загубилась логіка або що можна оптимізувати.
Уявіть, що всі рішення проходять через одного менеджера з 20 людьми в підпорядкуванні. Кожне питання він має перевірити, засінкати з бізнесом і повернути назад. Коли все зав'язано на одній людині, вона б швидко збожеволіла, а ми цілими днями тільки й робили б, що синхронізувались через неї. Провальний експеримент Google тому доказ.
Тому в нас робоча команда складається не більше ніж із 10 людей з мінімально необхідною експертизою, щоб довести фічу до релізу. У моїх скводах це PO, аналітики, бекенд- і фронтенд-розробники, QA, еджайл-коуч і я як дизайнер. Рішення команда ухвалює сама, в межах конкретної цілі та наявних ресурсів. Саме так ми встигаємо релізити регулярно.
Ця структура називається Spotify-моделлю. У 2012 році її описали Хенрік Кніберг і Андерс Іварссон, і йдеться в ній не про ритуали, а про те, як організувати людей навколо роботи. Кілька термінів, які варто знати про цю модель:
1️⃣ Сквод: автономна крос-функціональна команда зі своєю місією. Один мій сквод займається валютними операціями. Другий зібрали спеціально під міграцію легасі: він досліджує, що з функціоналу старої системи справді потрібно клієнтам, і переносить тільки це.
2️⃣ Трайб: кілька скводів у суміжній області продукту. Я працюю в трайбі Діджитал банкінгу, а поруч є, наприклад, трайб, що відповідає за сайт банку, і трайб клієнтського досвіду.
3️⃣ Чаптер: люди однієї спеціальності всередині трайбу, які разом тримають спільні стандарти. У нас є веб- і мобайл-дизайн чаптери, де ми постійно вдосконалюємо своє ремесло.
4️⃣ Гільдія: добровільна спільнота за інтересом, що проходить крізь усю компанію. Наша дизайн-гільдія збирається раз на місяць, щоб поділитися успіхами та знахідками, корисними в роботі.
Чому це варто розуміти дизайнеру? Бо так ти знаєш, до кого йти з конкретними питаннями, а не задовбуєш постійно PO.
Типова ситуація: моя фіча зачіпає функціонал іншої команди. Спершу я йду до їхнього дизайнера. Питаю, як у них прийнято з цим працювати, на що вплинуть мої зміни, чи знадобляться доробки на їхньому фронті або бекенді. Це просто синк, остаточне рішення я, звісно ж, делегую PO, бо це його зона відповідальності.
Якщо ж треба змінити робочий компонент дизайн-системи, збираємо ширший дзвінок: мій PO, PO команди, яку я зачіпаю, дизайн-лід і розробник, відповідальний за дизайн-систему.
Звідси й ті шість годин. Але кожен такий дзвінок закриває конкретне питання між людьми, яких воно стосується, а не чекає відповіді від одного менеджера.
І саме такий сетап дає рости. Ніхто не водить тебе за руку між командами: ти сам бачиш, кого зачіпають твої зміни, і сам збираєш потрібних людей. Так фокус тримається на цілях компанії, а не лише на твоїй задачі. А з часом інші команди самі кличуть тебе, коли працюють над чимось схожим на те, що ти вже робив.
👉 Тут доречі замахнулись на цю модель і зробили щось нове
Мій звичайний день починається з двох дейліків поспіль, бо я працюю у двох командах одночасно. Далі сінк із QA і фронтом по поточній задачі, обід, ще пара дзвінків, і десь о 17:00 я закриваю останній мітинг. На сам проєкт часу вже не лишилось 😄
Дзвінки забирають від пари годин до шести на день. Звучить як жах, особливо для інтроверта. Але в ПУМБ працює дофіга людей, і без частих розмов цей корабель просто не полетить. Таке собі необхідне «зло». А для дизайнера ще й спосіб вплинути на рішення: коли з PO та аналітиками ми розбираємо нову задачу, я дивлюся на аналіз і бізнес-схеми та бачу, де загубилась логіка або що можна оптимізувати.
Уявіть, що всі рішення проходять через одного менеджера з 20 людьми в підпорядкуванні. Кожне питання він має перевірити, засінкати з бізнесом і повернути назад. Коли все зав'язано на одній людині, вона б швидко збожеволіла, а ми цілими днями тільки й робили б, що синхронізувались через неї. Провальний експеримент Google тому доказ.
Тому в нас робоча команда складається не більше ніж із 10 людей з мінімально необхідною експертизою, щоб довести фічу до релізу. У моїх скводах це PO, аналітики, бекенд- і фронтенд-розробники, QA, еджайл-коуч і я як дизайнер. Рішення команда ухвалює сама, в межах конкретної цілі та наявних ресурсів. Саме так ми встигаємо релізити регулярно.
Ця структура називається Spotify-моделлю. У 2012 році її описали Хенрік Кніберг і Андерс Іварссон, і йдеться в ній не про ритуали, а про те, як організувати людей навколо роботи. Кілька термінів, які варто знати про цю модель:
1️⃣ Сквод: автономна крос-функціональна команда зі своєю місією. Один мій сквод займається валютними операціями. Другий зібрали спеціально під міграцію легасі: він досліджує, що з функціоналу старої системи справді потрібно клієнтам, і переносить тільки це.
2️⃣ Трайб: кілька скводів у суміжній області продукту. Я працюю в трайбі Діджитал банкінгу, а поруч є, наприклад, трайб, що відповідає за сайт банку, і трайб клієнтського досвіду.
3️⃣ Чаптер: люди однієї спеціальності всередині трайбу, які разом тримають спільні стандарти. У нас є веб- і мобайл-дизайн чаптери, де ми постійно вдосконалюємо своє ремесло.
4️⃣ Гільдія: добровільна спільнота за інтересом, що проходить крізь усю компанію. Наша дизайн-гільдія збирається раз на місяць, щоб поділитися успіхами та знахідками, корисними в роботі.
Чому це варто розуміти дизайнеру? Бо так ти знаєш, до кого йти з конкретними питаннями, а не задовбуєш постійно PO.
Типова ситуація: моя фіча зачіпає функціонал іншої команди. Спершу я йду до їхнього дизайнера. Питаю, як у них прийнято з цим працювати, на що вплинуть мої зміни, чи знадобляться доробки на їхньому фронті або бекенді. Це просто синк, остаточне рішення я, звісно ж, делегую PO, бо це його зона відповідальності.
Якщо ж треба змінити робочий компонент дизайн-системи, збираємо ширший дзвінок: мій PO, PO команди, яку я зачіпаю, дизайн-лід і розробник, відповідальний за дизайн-систему.
Звідси й ті шість годин. Але кожен такий дзвінок закриває конкретне питання між людьми, яких воно стосується, а не чекає відповіді від одного менеджера.
І саме такий сетап дає рости. Ніхто не водить тебе за руку між командами: ти сам бачиш, кого зачіпають твої зміни, і сам збираєш потрібних людей. Так фокус тримається на цілях компанії, а не лише на твоїй задачі. А з часом інші команди самі кличуть тебе, коли працюють над чимось схожим на те, що ти вже робив.
👉 Тут доречі замахнулись на цю модель і зробили щось нове
❤8💘2🔥1🤓1
ШІ дає змогу братися за складніші задачі, швидше розбиратися в незнайомих доменах і працювати на перетині дизайну та розробки.
Банкінг - сильно зарегульоване середовище з високим рівнем відповідальності, тому у використанні ШІ є жорсткі обмеження. Персональні дані, банківська таємниця та конфіденційні матеріали не мають потрапляти в зовнішні сервіси. Це стосується і макетів, і текстів, і всього іншого.
Хочу показати два приклади, де ШІ допомагає вийти за межі звичних дизайн-інструментів.
Рефакторинг макетів
На обкладинці - приклад зміни структури навігації. Адаптувати один екран досить просто. Але як оновити сотні таких екранів без купи ручної роботи?
Компонент у дизайн-системі концептуально змінився. Просто підтягнути нову версію в усі макети - не завжди рішення. У цьому випадку властивості одного компонента переїхали в інший, і під час звичайного оновлення інстансів виділений таб скрізь злетить на перший у списку. Щоб це виправити, потрібно було пройтися сотнями макетів і замінити налаштування нових інстансів на відповідні контексту конкретного екрана чи флоу.
Саме тому я й вирішив створити кастомні ШІ-скіли - набори інструкцій і правил, за якими агент знаходить потрібні інстанси, аналізує їхні властивості та візуальний контекст і адаптує компоненти під конкретні екрани.
Тепер оновлення макетів цілого розділу займає не години, а десятки хвилин. І поки агент працює, я можу спокійно піти попити кави, а коли він маякне про готовність - перевірити результат.
Прототипування
Інша задача, де можливості звичних інструментів починають обмежувати дизайнера, - підготовка прототипів для користувацьких досліджень.
Особливо коли йдеться про складні B2B-продукти, де важливо перевірити не лише навігацію між екранами, а й реальну поведінку інтерфейсу з реалістичними даними.
Складний Figma-прототип із таблицями, формами, залежними станами та десятками переходів перетворюється на монстра. Його важко підтримувати, він глючить і створює проблеми під час роботи в Maze. Починаються танці з оптимізацією, детачем інстансів, спрощенням сценаріїв та растеризацією візуалу.
Тому для таких сценаріїв я використовую Claude Code, щоб генерувати реалістичні прототипи за макетами та компонентами дизайн-системи. Такий прототип значно легший за Figma-прототип і ближчий до реальної поведінки продукту: введення даних, валідація, умовна логіка, зміни станів. А ще його набагато швидше зібрати: у Figma я робив би такий прототип щонайменше тиждень, а з ШІ - години.
Але давайте не забувати, що токени коштують грошиків)
Спершу я визначаю межі роботи ШІ: яку гіпотезу тестуємо, які сценарії, екрани, стани та інтеракції потрібні, що слід виключити і за якими критеріями перевіримо результат.
Тестуємо лише десктоп? Отже, не генеруємо мобільну версію. Компонент суто інформаційний? Не реалізуємо зайві стани.
Окрім скоупу генерації, важливо визначити, які рішення агент може ухвалювати самостійно. Наприклад, він може оптимізувати код, але не змінювати логіку дослідницького сценарію без погодження.
Потім перевикористовую вже згенероване. Спільний код, правила, сценарії та відмінності між версіями зберігаю в md-файлах. Навіть те, що прибрали з поточного тесту, можна зберегти для наступного. Так поступово формується база готових елементів.
Готовий прототип можна розгорнути на хостингу на кшталт Netlify чи Vercel, захистити паролем від чужих очей і дати респондентам посилання. Усі дані в прототипі деперсоналізовані, а розміщення відповідає правилам безпеки організації.
Можна ще й аналітику прикрутити та збирати метрики.
А що з рештою задач?
Їх теж вистачає: ШІ допомагає нам підганяти чорнові тексти під ToV, шукати edge-кейси та критикувати дизайн-рішення.
У дослідженнях він допомагає з підбором методів і метрик, тематичним аналізом тощо.
Раніше для частини цих задач мені знадобилася б допомога розробника або значно більше часу.
Власне, у цьому я й бачу головну цінність ШІ: не просто робити звичні речі швидше, а розширювати те, що я взагалі можу зробити як дизайнер.
А які сценарії використання ШІ прижилися у вас?
Банкінг - сильно зарегульоване середовище з високим рівнем відповідальності, тому у використанні ШІ є жорсткі обмеження. Персональні дані, банківська таємниця та конфіденційні матеріали не мають потрапляти в зовнішні сервіси. Це стосується і макетів, і текстів, і всього іншого.
Хочу показати два приклади, де ШІ допомагає вийти за межі звичних дизайн-інструментів.
Рефакторинг макетів
На обкладинці - приклад зміни структури навігації. Адаптувати один екран досить просто. Але як оновити сотні таких екранів без купи ручної роботи?
Компонент у дизайн-системі концептуально змінився. Просто підтягнути нову версію в усі макети - не завжди рішення. У цьому випадку властивості одного компонента переїхали в інший, і під час звичайного оновлення інстансів виділений таб скрізь злетить на перший у списку. Щоб це виправити, потрібно було пройтися сотнями макетів і замінити налаштування нових інстансів на відповідні контексту конкретного екрана чи флоу.
Саме тому я й вирішив створити кастомні ШІ-скіли - набори інструкцій і правил, за якими агент знаходить потрібні інстанси, аналізує їхні властивості та візуальний контекст і адаптує компоненти під конкретні екрани.
Тепер оновлення макетів цілого розділу займає не години, а десятки хвилин. І поки агент працює, я можу спокійно піти попити кави, а коли він маякне про готовність - перевірити результат.
Прототипування
Інша задача, де можливості звичних інструментів починають обмежувати дизайнера, - підготовка прототипів для користувацьких досліджень.
Особливо коли йдеться про складні B2B-продукти, де важливо перевірити не лише навігацію між екранами, а й реальну поведінку інтерфейсу з реалістичними даними.
Складний Figma-прототип із таблицями, формами, залежними станами та десятками переходів перетворюється на монстра. Його важко підтримувати, він глючить і створює проблеми під час роботи в Maze. Починаються танці з оптимізацією, детачем інстансів, спрощенням сценаріїв та растеризацією візуалу.
Тому для таких сценаріїв я використовую Claude Code, щоб генерувати реалістичні прототипи за макетами та компонентами дизайн-системи. Такий прототип значно легший за Figma-прототип і ближчий до реальної поведінки продукту: введення даних, валідація, умовна логіка, зміни станів. А ще його набагато швидше зібрати: у Figma я робив би такий прототип щонайменше тиждень, а з ШІ - години.
Але давайте не забувати, що токени коштують грошиків)
Спершу я визначаю межі роботи ШІ: яку гіпотезу тестуємо, які сценарії, екрани, стани та інтеракції потрібні, що слід виключити і за якими критеріями перевіримо результат.
Тестуємо лише десктоп? Отже, не генеруємо мобільну версію. Компонент суто інформаційний? Не реалізуємо зайві стани.
Окрім скоупу генерації, важливо визначити, які рішення агент може ухвалювати самостійно. Наприклад, він може оптимізувати код, але не змінювати логіку дослідницького сценарію без погодження.
Потім перевикористовую вже згенероване. Спільний код, правила, сценарії та відмінності між версіями зберігаю в md-файлах. Навіть те, що прибрали з поточного тесту, можна зберегти для наступного. Так поступово формується база готових елементів.
Готовий прототип можна розгорнути на хостингу на кшталт Netlify чи Vercel, захистити паролем від чужих очей і дати респондентам посилання. Усі дані в прототипі деперсоналізовані, а розміщення відповідає правилам безпеки організації.
Можна ще й аналітику прикрутити та збирати метрики.
А що з рештою задач?
Їх теж вистачає: ШІ допомагає нам підганяти чорнові тексти під ToV, шукати edge-кейси та критикувати дизайн-рішення.
У дослідженнях він допомагає з підбором методів і метрик, тематичним аналізом тощо.
Раніше для частини цих задач мені знадобилася б допомога розробника або значно більше часу.
Власне, у цьому я й бачу головну цінність ШІ: не просто робити звичні речі швидше, а розширювати те, що я взагалі можу зробити як дизайнер.
А які сценарії використання ШІ прижилися у вас?
🔥13❤3
Дуже подобається такі креативні інтро 😍
https://www.instagram.com/reel/DepBm5kCnJI/?exln=MTg4cGY2YWliMGlxcA==
https://www.instagram.com/reel/DepBm5kCnJI/?exln=MTg4cGY2YWliMGlxcA==
❤5
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 і тривогами.
Одну з двох книг у замовленні ще навіть не відправили читачеві, а система вже показувала статус «частково повернено».
Це був один із моментів, коли я зрозумів, що міграція бібліотеки KyivUX на Notion не буде легкою прогулянкою.
Спочатку я сприймав її як механічну задачу - перенести каталог, прив'язати наявні замовлення й читачів, відтворити поточну логіку. А вже потім братися за досвід читачів.
Так я думав, поки не почав будувати бази даних.
Книги, примірники, читачі, замовлення, оренди, черга й ще купа баз, частина з яких виявилася зайвою. Усе це було взаємопов'язане. Я кілька разів перебудовував тестову структуру, але щоразу знаходив нові логічні помилки. Виправляв одну - з'являлася друга, третя…
У якийсь момент стало зрозуміло, що проблема не у формулах чи ролапах. Notion рахував саме те, що я в нього вніс. Нелогічною була сама модель системи.
Тоді я й згадав про OOUX. Про Object-Oriented UX я колись читав у Софії Прейтер, але в реальному проєкті ще не застосовував. Схоже настав час.
Я відклав бази й описав бібліотеку через ORCA (Objects, Relationships, Calls-to-Action, Attributes). Виписав на стікери об'єкти, їхні атрибути, зв'язки й дії. Сформувати дії мені допоміг фреймворк CRUD. Так склалася модель із п'яти об'єктів: книги, примірники, читачі, замовлення та оренди.
Перше відкриття: книга в каталозі й книга на полиці - різні об'єкти. Читач обирає назву, а бібліотека видає конкретний примірник. Примірників у книги може бути кілька, і кожен у своєму стані: доступний, зарезервований, у читача чи взагалі втрачений.
Друге стосувалося замовлень. Одне замовлення може містити кілька книг, але кожна проходить свій шлях: одну вже відправили, другу ще готують, третю читач повернув. Тож замовлення треба було розкласти на оренди, по одній на кожну книгу, зі своїми датами й статусом. Примірник прив'язується до оренди, щойно звільняється, тому оренда може існувати й без нього. А вже зі статусів оренд складається статус замовлення.
Третє - кому належать властивості. ТТН і дату повернення логічно було б тримати в замовленні, якщо книги їдуть однією посилкою. Але вони можуть їхати й окремо, тож ці поля переїхали в оренду. А доступність книги ніде не зберігається: вона рахується зі станів її примірників.
Щойно об'єкти й зв'язки стали явними, статуси нарешті склалися. Замість латати помилки формулами, я описав правила, яким підкоряється вся система.
Ця модель визначила не лише структуру баз, а й інтерфейс читача. Сторінка книги на сайті - це по суті атрибути й дії об'єкта "Книга".
OOUX змушує дивитися на продукт не як на екрани й флоу, а як на систему: що в ній існує, як усе пов'язано і які дії мають сенс для кожного об'єкта.
Звісно, одного Notion не вистачило: публічний сайт не бачив внутрішньої бази. Довелося під'єднати допоміжні сервіси, дописати трохи коду й налаштувати автоматизації. Але з готовою моделлю було ясно, які дані де зберігати і за що відповідає кожен інструмент.
OOUX я давно знав у теорії, але зрозумів по-справжньому, лише коли моя модель почала ламатися об реальність. Тепер думаю, що такі підходи варто випробовувати на невеликих проєктах, перш ніж вони знадобляться у великих. Бо навіть невелика бібліотека може виявитися складною системою.
І жодна автоматизація не врятує, якщо ти сам до кінця не розумієш, як вона має працювати.
Дякую нашій чарівній засновниці KyivUX Тані Зав'яловій за довіру, а тіммейтам Богдану, Наталці, Олені, Вероніці й Карині - за час і сили, які вони знаходять для цього проєкту між work-life balance і тривогами.
❤13🔥4
Тіме, щиро дякуємо за цей тиждень! Було змістовно й корисно. Сподіваємося, NDA не порушено 🤝️️️️️️
Нам було цікаво спостерігати за твоїм досвідом і підходом до роботи. Особливо запамʼятався інсайт про зміни в продукті, з якими рано чи пізно стикаємося. Не завжди вистачає сміливості відстояти свою думку й донести її до інших. Тому ще раз нагадуємо собі, що дизайн-мислення розвивається разом із досвідом.
Будемо раді бачити тебе знову!
Залишаємо LinkedIn Тіма та залишаємося на звʼязку 💙
Нам було цікаво спостерігати за твоїм досвідом і підходом до роботи. Особливо запамʼятався інсайт про зміни в продукті, з якими рано чи пізно стикаємося. Не завжди вистачає сміливості відстояти свою думку й донести її до інших. Тому ще раз нагадуємо собі, що дизайн-мислення розвивається разом із досвідом.
Будемо раді бачити тебе знову!
Залишаємо LinkedIn Тіма та залишаємося на звʼязку 💙
Linkedin
Tim Roman - KyivUX Design Community | LinkedIn
UX/UI Designer with 16 years of experience delivering large-scale digital products for… · Experience: KyivUX Design Community · Education: Projector Institute · Location: Ukraine · 500+ connections on LinkedIn. View Tim Roman’s profile on LinkedIn, a professional…
❤4🔥2👍1😇1
Цього року наша Black Friday зі знаком плюс: купуєте один курс, а ще десять отримуєте в подарунок!
Обирайте перший курс під конкретні плани, а ще десять допоможуть опанувати все, що давно лежить у вішлісті 💙
Більше про Black Friday — https://bit.ly/47Wad9e
Як це працює?
1. Обирайте курс
Шукайте курс з позначкою Black Friday. Подайте заявку й оплатіть повну вартість до 30 листопада. Почати навчання можна в будь-якому потоці до 20 листопада 2027 року.
2. Додайте ще 10 безоплатно
Після оплати на пошту прийде анкета — оберіть в ній 5 курсів і 5 відеокурсів зі списку подарунків. Анкету заповнювати треба лише один раз.
3. Навчайтеся у своєму темпі
Доступ до подарункових курсів відкриється протягом 24 годин після заповнення анкети та діятиме до 20 листопада 2027 року.
Обирайте перший курс під конкретні плани, а ще десять допоможуть опанувати все, що давно лежить у вішлісті 💙
Більше про Black Friday — https://bit.ly/47Wad9e
🔥11❤3
Друзі, вітайте нову людину на каналі 💙
Марія Шниркова — копірайтерка в NovaPay, авторка каналу 404 | сторінку не знайдено
В маркетингу Марія понад 10 років. Починала волонтеркою в Мінекономіки часів ProZorro. Далі працювала з темами impact tech, health tech, legal tech
Найцінніший в карʼєрі проєкт — комунікація відкриття стартап-центру 1991 Mariupol
Марія, канал твій, успіхів 🫂
Instagram
LinkedIn
Марія Шниркова — копірайтерка в NovaPay, авторка каналу 404 | сторінку не знайдено
В маркетингу Марія понад 10 років. Починала волонтеркою в Мінекономіки часів ProZorro. Далі працювала з темами impact tech, health tech, legal tech
Найцінніший в карʼєрі проєкт — комунікація відкриття стартап-центру 1991 Mariupol
Марія, канал твій, успіхів 🫂
❤41🥰5
Друзі, привіт!
Маю велику радість вести цей канал для вас. Сподіваюся, буде корисно.
Колись у часи навчання в інституті я влаштовувала вечірки. Збирала людей, домовлялася про локацію, навіть грала як діджейка)
Так і почуваю себе зараз: ніби на великій сцені. Хвилююче, але дуже цікаво.
Почну з музики.
⛰️ Це ісландський гурт Sigur Rós, або «Троянда Перемоги». Цей трек моментально додає настрою – https://youtu.be/WgaQC7B3GIE?si=tNjaUd3TlcNBD89t
Запрошую послухати)
І хай у нас із вами буде гарний тиждень 🤍
Маю велику радість вести цей канал для вас. Сподіваюся, буде корисно.
Колись у часи навчання в інституті я влаштовувала вечірки. Збирала людей, домовлялася про локацію, навіть грала як діджейка)
Так і почуваю себе зараз: ніби на великій сцені. Хвилююче, але дуже цікаво.
Почну з музики.
⛰️ Це ісландський гурт Sigur Rós, або «Троянда Перемоги». Цей трек моментально додає настрою – https://youtu.be/WgaQC7B3GIE?si=tNjaUd3TlcNBD89t
Запрошую послухати)
І хай у нас із вами буде гарний тиждень 🤍
❤27