Scalr: дизайн система, продуктові задачі 

Переробив верх дашборда так, щоб показати весь пайплайн візуально: Init, Plan, Apply і State Storage, з кожним хуком на своєму етапі.

Перша ітерація закрила питання «який стан», але пайплайн лишався чорною скринькою: не було видно, які хуки спрацьовують на якому етапі й де це кастомізувати. Діаграму зробив інтерактивною: хуки на pre-init, pre-plan, post-plan, pre-apply і post-apply, апрували, OPA-політики, Infracost-оцінка вартості й нотифікації додаються прямо з неї, а не крізь налаштування. Робочі частини v1, тобто Latest run, Outputs, Runs activity і Resources, лишились унизу і працюють як раніше.

Зв'язав три виміри в одному bubble chart: кількість запусків, RUM (resources under management, скільки ресурсів реально веде workspace) і швидкість виконання, яку кодує колір бульбашки.

Перші метрики показували тренди і найповільніші простори, але не відповідали, які простори потребують уваги і чому: 500 запусків по 2 хвилини це норма, 500 по 10 хвилин це діра в бюджеті. Розклав чарт на семантичні зони: Busy Bees, Critical Monoliths, Frozen Giants і Ghost Sandboxes, зі Sweet Spot по центру. Кожна бульбашка пронумерована й клікабельна, тому платформний лід показує на зону і одразу називає три проблемні простори.

Опитав досвідчених користувачів, які дані важливі й коли, і зібрав екран у контекстні блоки, де кожен відповідає на одне питання.

Старий дашборд був плоским списком даних без контексту, тож щоб зрозуміти стан простору, доводилось стрибати між кількома вкладками. Блоки це Summary, Latest run, Outputs, Runs activity і Resources. Додав дії прямо з дашборда, тобто Queue new run і Show all, графік активності запусків, і виніс наперед результати policy-перевірок та оцінку вартості, які раніше ховались на два-три кліки вглиб.

Розклав IAM на вкладки і додав колонку Last activity з кольоровими прапорцями для акаунтів, неактивних 5+ місяців.

Стара сторінка була простим списком імен і пошти, тож адмін не міг оцінити структуру команди чи знайти неактивні акаунти, не клікаючи в кожного окремо. Вкладки це Users, Service accounts, Workload identity providers, Teams, Roles і Access policies: від живих людей до CI/CD-акаунтів і безключової автентифікації. Додав колонку Teams прямо в списку, дію Login as для дебагу прав і пошук, що поєднує пошту, ім'я і статус в одному полі.

Спроєктував сторінку метрик з нуля навколо двох питань: «що відбувається зараз» і «який тренд».

Централізованого моніторингу продуктивності в Scalr не було: команди не бачили ні черг, ні тривалості запусків, ні деградації просторів, і знаходили проблеми вже після поломки. «Зараз» це статус і латентність черги, «тренд» це Daily runs, Plans і Applies. У кожен графік вбудував порівняння з попереднім періодом і дельту у відсотках, а вью Slowest workspaces ранжує простори за P95, тому розмите «щось гальмує» стає конкретним списком, що лагодити першим.

Замінив модалки на двопанельний picker: середовища без доступу ліворуч, з доступом праворуч, стрілки між ними.

VCS-з'єднання (GitHub, GitLab) це канал, через який Scalr тягне Terraform-код і вебхуки, і адмін вирішує, які середовища можуть ним користуватись. Раніше видача йшла через попапи і багатокрокові дії, а масове призначення було майже неможливим без клікання по кожному середовищу. Патерн знайомий із файлових менеджерів. Додав пошук і пагінацію для масштабу і перемикач Allow all current and future environments, тобто один клік замість ста шістдесяти.

Згорнув пайплайн у компактний вертикальний таймлайн ліворуч, а праворуч віддав головне: diff коду і зміни ресурсів.

Стара сторінка деталей була роздутою: етапи пайплайна, ресурси і зміни коду лежали без ієрархії, тож щоб зрозуміти, що змінилось, доводилось скролити й клікати. Таймлайн це Source, Plan, Cost estimate, Policy check, Apply approval і Apply. Зробив GitHub-подібний diff-в'ювер із червоно-зеленим підсвічуванням, акордеон по кожному ресурсу і пошук за адресою ресурсу.

Зробив split-panel: список ліворуч, повна розкладка доступу праворуч, з ієрархією Account, Environment і Workspace.

Система політик складна за природою: користувачі й команди мають кілька скоупів, кожен зі своїми ролями, тож питання «що саме цей користувач може і де» вимагало клікати крізь кілька екранів і складати картину в голові. Ієрархічний вигляд показує рівень доступу (Full access, Read-only, Limited) і кількість прав, дозволи розкриваються, фільтр за роллю в пошуку відповідає на зворотне питання «хто має цю роль», а користувачі й команди лежать в одному списку з різними іконками.

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

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