Як ми проектуємо і прототипуємо додатки і системи

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

Нижче — два короткі відео з реального процесу. Вони добре показують одну просту, але дуже важливу думку: прототип — це не прикраса і не красива картинка для інвестора. Це робочий макет системи, який допомагає приймати рішення до того, як ви витратите основний бюджет на production-розробку.

Відео №1. Огляд першого етапу: прототип, документація, адміністративний контур і системна логіка

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

Відео №2. Клієнтська частина, Figma як референс і логіка MVP

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

Що ми пропонуємо на етапі проектування-прототипування

Ми пропонуємо два формати входу в роботу. Це важливо, бо не кожному проєкту одразу потрібен код. Іноді потрібен спочатку здоровий технічний мозок, а вже потім руки.

Варіант 1. Тільки проектування

Це формат для тих, кому потрібно створити ТЗ, зібрати логіку системи, описати модулі, межі MVP і архітектурні рішення, але без написання навіть сирого демо-коду. Такий формат ідеально підходить, коли потрібно:

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

По суті, у цьому варіанті ми створюємо інженерний креслярський комплект для майбутньої системи: не фасад, а конструкцію.

Варіант 2. Проектування + прототипування

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

У цьому варіанті до проектування додається:

• ранній прототип бази даних;
• CRUD-адмінка для керування бізнес-об’єктами CRUD — створення, читання, редагування, видалення;
• ранній прототип адміністративної зони;
• частково реалізований користувацький застосунок у браузері;
• спрощена дизайн-система для узгодження візуальної логіки;
• тестове середовище, де рішення можна побачити не в абстракції, а в дії.

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

Що саме ми створюємо: структура результату

Нижче — не абстрактна обіцянка на кшталт усе продумаємо, а нормальна структура того, що реально формується на цьому етапі.

1. Бізнес-вимоги і рамки проекту

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

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

2. ТЗ на дані, архітектуру, інфраструктуру, адміністрування

Ми формуємо технічне завдання у форматі, близькому до логіки SRS / ISO/IEC/IEEE 29148. Не для галочки, а щоб документ був корисним для постановки задач на розробку.

• вступ і загальний опис системи;
• функціональні вимоги;
• нефункціональні вимоги;
• дані та обмеження;
• критерії приймання;
• опис предметної області;
• загальні системні вимоги;
• бізнес-об’єкти системи і зміст кожного бізнес-об’єкта;
• архітектурні рішення;
• опис інфраструктури;
• адміністративний контур;
• оціночний юніт і базова оцінка компонентів.

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

3. ERD / модель даних

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

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

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

4. ТЗ на інтерфейс користувача

Окремо формується модель інтерфейсів:

• декларація візуальних екранів;
• декларація блоків і компонентів;
• опис типів компонентів;
• зв’язки екранів із моделлю даних;
• зв’язки елементів інтерфейсу з бізнес-об’єктами;
• опис полів, форм, переходів, вкладеностей і сценаріїв;
• додаткові неформальні коментарі до функціональності;
• декларація дизайн-системи у вигляді змінних до CSS.

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

5. Прототип бази даних

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

• спрощене збереження бізнес-об’єктів;
• первинні зв’язки між сутностями;
• тестові дані для демонстрації флоу;
• основа під ролі, користувачів, профілі, довідники, системні записи;
• можливість перевірити, чи взагалі модель поводиться адекватно під реальні сценарії.

6. CRUD-адмінка і адміністративний контур

Саме адміністративна частина вбиває романтику у хорошому сенсі =). Бо коли ми проектуємо реальний продукт, доводиться думати не лише про те, що бачить пацієнт, а й про те, хто наповнює довідники, редагує лікарів, керує ролями, мовами, категоріями, документами, подіями, статусами і системними даними.

• керування користувачами;
• керування ролями та доступами RBAC;
• керування мовами і перекладами;
• керування довідниками;
• системні таблиці, фільтри, сортування, пошук;
• редагування записів без участі програміста;
• підготовка бази під системну аналітику, логи, таймлайни, статуси.

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

7. Частковий прототип користувацького застосунку

У ранній версії ми частково збираємо користувацькі екрани, щоб можна було побачити флоу очима реального користувача. Не в презентації, а в браузері.

• авторизація і реєстрація у спрощеному вигляді;
• списки і картки сутностей;
• форми створення і редагування;
• кнопки переходів і базова навігація;
• мобільна адаптація на рівні прототипу;
• візуалізація пріоритетних екранів MVP.

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

8. Прототипна дизайн-система

Ми не видаємо сирий прототип за фінальний преміальний дизайн, але і не зводимо все до сірого тексту на білому фоні. Для прототипу використовується базова дизайн-система, достатня для візуального узгодження:

• кольори;
• шрифти;
• відступи;
• кнопки;
• картки;
• меню;
• типові елементи форм.

На технічному рівні як основа можуть використовуватись Bootstrap і Font Awesome, щоб не винаходити колесо там, де потрібна швидка та зрозуміла візуалізація.

Які контури ми проектуємо в подібних системах

По відео добре видно, що мова йде не про один екран, а щонайменше про три великі шари системи.

Клієнтський контур

• реєстрація та авторизація;
• профіль;
• список спеціалістів;
• картка лікаря;
• створення консультації;
• перегляд консультацій;
• медична карта та частина персональних даних;
• в майбутньому — білінг, розсилки, інтеграції, AI-модулі, календарі.

Робочий контур лікаря або спеціаліста

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

Адміністративний і системний контур

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

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

Що входить у першу фазу, а що проектується наперед

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

Наприклад, у подібних медичних продуктах у прототип часто входять:

• спрощена реєстрація;
• список лікарів;
• створення консультації;
• профіль користувача у спрощеному вигляді;
• медична карта з базовими параметрами;
• адміністративна система під паролем;
• керування користувачами, ролями, статтями, категоріями, бізнес-об’єктами;
• таблиці, пошук, сортування, фільтри, редагування, видалення, додавання.

А от більш складні речі можуть бути спроектовані на перед, але не входити в першу сиру реалізацію:

• просунута реєстрація з перевірками;
• модулі штучного інтелекту;
• деталізовані рейтинги і відгуки;
• повноцінний календар бронювань;
• білінг на основі платіжного шлюзу;
• онлайн-чат;
• push-сповіщення;
• поштова автоматизація;
• інтеграції з зовнішніми медичними системами.

Це дуже здорова логіка. Бо хороше проектування не намагається одразу зварити космічний корабель із чайника. Воно будує дорогу розвитку.

На якому стеку може створюватися такий прототип

Для швидкого, контрольованого і технічно прагматичного прототипування може використовуватись стек PHP, MySQL, Docker і Linux. Це дозволяє зібрати робочий демонстраційний контур без зайвої театральщини, але з достатньою технічною серйозністю.

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

Що важливо розуміти чесно: прототип — це не production

І це нормально. Більше того — це правильно.

• Прототип не призначений для публічного запуску.
• Прототип не є фінальним продуктом для реальних користувачів.
• Прототип не включає повну унікальну бізнес-логіку production-рівня.
• Прототип не включає повну індексацію, оптимізацію, складні об’єднання вибірок і тонке навантажувальне налаштування.
• Прототип не гарантує production-рівень безпеки, прав доступу і тонкого UX-полірування.

Прототип — це технічний чернетковий макет з мозком. Він потрібен, щоб зменшити ризик, а не щоб удавати, ніби ризику вже не існує.

Як організований сам процес

У нормальній моделі ця послуга ділиться на два етапи:

• перший етап — збір та уточнення вимог, побудова моделі даних, моделі інтерфейсів, чернеткового ТЗ і створення раннього прототипу;
• другий етап — уточнення інтеграцій, системних подій, особливих алгоритмів, нефункціональних вимог і фіналізація ТЗ.

Зазвичай у таку послугу органічно входять:

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

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

Для кого цей формат особливо корисний

Для стартапів

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

Для системних компаній

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

Суміжні кейси, які варто подивитися

Якщо вам близька тема медичних та системних продуктів, ось кілька релевантних матеріалів:

• Проектування МІС по eHealth — хороший приклад, коли потрібні нормативка, моделі, логіка інтеграцій і системне мислення.
• Lita — медичний продукт із конструктором тестів та складною логікою даних.
• L-Doc — онлайн-кабінети для лікарів, де добре видно професійний робочий контур.
• Rapport — продукт для психологів і пацієнтів, де теж важливий баланс між UX, даними і процесами.
• Dent Ingello — медичний сервіс для стоматологій з власною операційною логікою.
• FORMA BPM — якщо вам ближча не медицина, а побудова системної корпоративної платформи.

Що отримує замовник на виході

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

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

І ось це, власне, і є головна цінність такого етапу: він перетворює хаотичну ідею на керований інженерний об’єкт.

Коли варто починати саме з цього етапу

Починати з проектування і прототипування варто тоді, коли:

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

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