Колонка
Як перебудувати дизайн-процеси в SaaS продукті з 30к користувачів
Кейс від дизайн-агенції Metacarbon
9 грудня, 2021
Макс Москаленко
Head of Design у агенції Metacarbon
Стати автором

Застрибнути на ходу в SaaS-проєкт та не зірватись: як застосувати свіже продуктове мислення, заохотити клієнта до діалогу та розробити новий глобальний функціонал? Макс Москаленко, Head of Design в агенції Metacarbon, розповів про деталі редизайну графічного онлайн-редактора, в якого сила-силенна конкурентів.

*Примітка: SaaS-продукт — це програмне забезпечення, яке надається клієнтові як ліцензійна послуга за підпискою.

На першому ознайомчому дзвінку з Glorify Омар, СЕО компанії, сказав: «На ринку дуже багато конкурентів і вони змінюються щодня, тому і нас чекатиме невизначеність у кожному спринті та багато змін на ходу». Glorify – графічний онлайн-редактор для маркетологів, соло-підприємців та власників e-commerce магазинів. Відкрита конкуренція зі схожими та масштабнішими продуктами означала, що ми потрапили в розпал продуктових перегонів і це надихнуло нас підійти до справи ще серйозніше, ніж зазвичай.

Додаткова цінність на етапі пропоузалу

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

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

З точки зору масштабування продукту, було б неправильно проєктувати нову функціональність у рамках системи, що не піддається розвитку. Тому перед стартом роботи над Mockups Designer, ми взялися працювати над новими навігаційними патернами та загальним концептом інструментів у редакторі. В таких випадках варіантів реакції клієнта рівно два – тотальне захоплення, або грізне не сприйняття через складність реалізації та геть інші очікування. На етапі пропозиції ми розуміли, що настільки глобальні зміни для Glorify можуть бути надто важкими в реалізації. Попри це вирішили спробувати.

Глобальна навігація

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

Створення нових файлів

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

Ключові дії та панель інструментів

Реорганізовуємо панель інструментів, панель з ресурсами й інспектор згідно з типовими патернами для таких інструментів.

Вже в контексті оновленого інтерфейсу пропрацювали функціонал Mockups Designer на двох прикладах: звичайні типові мокапи (різні девайси і т.д.) і мокап для пакування зі складнішим функціоналом – «Unwrap».

Під час презентації ми отримуємо дуже енергійну реакцію СЕО та купу питань. Врешті, клієнт у захваті, і ми отримуємо позитивну відповідь.

Як рухатися далі

Чесно кажучи, концепт, який ми готували на етапі пропозиції, мав на меті демонстрацію «програми максимум» та ідеального варіанту оновленого користувацького досвіду платформи.

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

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

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

«Якщо це можливо – спершу завжди будуємо дизайн-процес і лише потім – нові функціональності».

Що робити, якщо є потреба працювати над новими фічами вже одразу, роадмапа переповнена ідеями, дедлайнами та запитами користувачів, а нова дизайн-команда розповідає про потребу будувати новий дизайн підхід з нуля?

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

5 тижнів дизайн системи

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

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

Наша типова дизайн-система – це набір декількох взаємозалежних файлів. Пара Styleguide файлів для різних кольорових тем з усіма базовими стилями, описаними як дизайн токени, декілька UI-бібліотек для різних use cases (сам продукт та маркетингові вебсайти), файли з фловами, Change log зі змінами для розробників та JSON-файл, який наповнюється згідно зі Styleguide файлами.

Slider image
Slider image

Ітерації та щоденне прототипування

На відміну від, наприклад, CRM чи ERP-платформ, де більшість користувацьких фловів лінійні, відносно розділені та послідовні, продукти на зразок Glorify – це часто набір динамічних модулів, їхніх властивостей та взаємодій між ними.

Однією з таких функціональностей був Video Editing. Фактично, завданням було спроєктувати відеоредактор інтегрований у редактор статичних картинок.

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

Slider image
Slider image
Slider image

Проте задача виявилась легшою, ніж здавалось. Більшість нових взаємодій, сам редактор з усіма таймкодами та звичне поняття «layering» добре лягли у хронологічний вигляд відеоредактора, дозволивши залишити основні функціональні сайдбари Glorify без змін.

Масштабування та наступні кроки Glorify

Наразі Glorify залучив наступний раунд інвестицій, більше 30 тисяч користувачів сервісу створили близько 1,7 млн дизайн-матеріалів за допомогою платформи, а продукт отримав Product of the Day на ProductHunt.

Щойно ми завершимо глбальні навігаійні зміни Mockups Designer та Video Editing, ми візьмемося за низку нових функціональностей з продуктової роадмапи. Про них ми розмовімо в наступних матеріалах, щойно станеться реліз цих частин продуктів.

 


Telegraf.Design живе за підтримки спільноти. Підтримуйте Telegraf.Design на Patreon.

avatar
Макс Москаленко
Head of Design у агенції Metacarbon
Колонка

У нас є ще дещо для вас