Object-Oriented User Experience Одну з двох книг у замовленні ще навіть не відправили читачеві, а си

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 і тривогами.