FinTech
FP&A-платформа для фінансових команд
B2B-платформа для бюджетування, прогнозування та звітності. Я прийшла першою дизайнеркою, провела три етапи досліджень, щоб знайти, де фінансові команди втрачають час, і перетворила знахідки на дизайн-систему, нову навігацію та самостійний конструктор звітів.
- Країна клієнта
- Канада
- Платформа
- Веб · B2B
- Команда
- 33 людини · перша дизайнерка на продукті
- Тривалість
- 10 місяців · 2022–2023
Огляд
B2B-платформа фінансового управління: бюджетування, прогнозування, звітність і міжвідділова співпраця.
Вихідна точка
До мене дизайнера не було, і мене покликали знайти ключові проблеми й скласти структурований план їх виправлення.
Що я зробила
Три етапи досліджень задали порядок денний, а далі йшли дизайн-система, перебудована навігація та Excel-нативні таблиці.
Результат
Ad Hoc-звіти дали користувачам збирати власні шаблони звітів, скоротивши кастомну розробку.
Контекст
01
Продукт
Інструменти бюджетування, прогнозування та звітності з міжвідділовою співпрацею, рольовим доступом аж до окремих клітинок і налаштовуваною безпекою.
02
Користувачі
Фінансові команди, бухгалтери та керівники відділів. Відділи редагують лише свої клітинки; менеджери бачать усе. Для них Excel рідна мова.
Підхід
Проаналізувати
Аналіз продукту з матрицею зусилля-вплив для швидких перемог.
Зайти всередину
Інтерв'ю між відділами і спостереження за онбординг-дзвінками.
Перевірити
Опитування й модеровані тести: прототип проти поточної версії.
Три етапи досліджень перетворили стіну видимих проблем на пріоритезований і здійсненний план.
Процес
Ключова функціональність
01
Таблиці
Проблема
Фінансовий софт складний за своєю природою: дані, формули, права доступу. Інтерфейс мав не заважати, але й не спрощувати інструменти, на які фінансисти спираються щодня: тими самими таблицями користуються і профі, і людина, яка відкрила продукт уперше.
Гіпотеза
Якщо таблиці відкривають продукт і поводяться так, як звичний фінансистам інструмент, складність продукту перестає бути бар'єром.
Рішення
Продукт живе на даних: таблиці як початковий вигляд, із фільтрами й сортуванням під те, як фінансисти насправді сканують цифри.
Фінансисти починають із цифр, а не з графіків, тому продукт відкривається таблицями.
Результат
Робочі процеси звіряла з самими фінансовими командами, щоб обидві групи працювали без перекладача.
02
Аналітичні дашборди
Проблема
Дашбордами користувалися абсолютно по-різному: як стартовою сторінкою, для KPI, для презентацій, а чимала частина не користувалася зовсім, бо не було зрозуміло, з чого почати.
Гіпотеза
Якщо є модульна сітка й готові приклади, дашборд перестає починатися з порожнього аркуша, і його збирають усі три групи користувачів.
Рішення
Користувачі додають і налаштовують віджети: графіки з фільтрами й масштабуванням, таблиці, зображення, текст. Усе пов'язане з файлами-джерелами й оновлюється автоматично. Модульна сітка та приклади шаблонів дають кожній команді зрозумілий старт.
Віджети привʼязані до файлів-джерел, тож дашборди оновлюються самі.
Налаштування віджета
Результат
Дашборд більше не починається з порожнього аркуша.
03
Звіти та шаблони
Проблема
Відділи мали бачити різне всередині одного файлу: керівник відділу вносить свої цифри й не бачить чужих, повну картину бачить лише менеджмент. Гнучка й водночас безпечна модель прав вимагала кількох ітерацій із розробкою та перевірки на реальних даних.
Гіпотеза
Якщо права задаються на рівні файлу й комірки, відділи зможуть працювати в одному звіті, не бачачи чужих цифр.
Рішення
Просунуті таблиці зі складними розрахунками й рольовим доступом: керівники відділів вносять свої цифри, не бачачи чужих; повну картину бачить лише менеджмент.
Дії Excel там, де їх чекають бухгалтери, тож нічого не треба перевчати.
Тулбар: дії Excel там, де їх шукають фінансисти
Усі меню, що стоять за цим тулбаром
Рольовий доступ в одному файлі
04
Ad Hoc-звіти
Проблема
Кожен клієнт хотів свій шаблон звіту, і кожен новий шаблон був окремою задачею для розробки.
Гіпотеза
Якщо користувач збере шаблон сам, обравши змінні, звітність перестане залежати від черги розробки.
Рішення
Користувачі збирають власні шаблони звітів, обираючи змінні: індивідуальна звітність без очікування кастомної розробки.
Кожен кастомний шаблон був задачею для розробки. Тепер вистачає кількох кліків.
05
Сервери даних
Проблема
Бюджетування й прогнозування живуть на масивах, які неможливо читати «як є». Завдання було зробити тренди й аномалії видимими, не спрощуючи самих чисел.
Гіпотеза
Якщо дані структуровані за вимірами, зріз стає кількома кліками, а не запитом до розробки.
Рішення
Інфраструктурний вигляд: великі обсяги фінансових даних зі швидким доступом і безпечним зберіганням.
Джерела та підключення в одному вікні, для тих, хто ними керує.
06
Виміри
Проблема
Фінансові дані треба різати за часом, регіоном і продуктом, а в голих таблицях це перетворювалось на ручну роботу.
Гіпотеза
Якщо виміри задані явно, зріз стане вибором, а не перебудовою таблиці.
Рішення
Атрибути, якими ріжуться фінансові дані (час, регіон, тип продукту), змодельовані візуально для аналізу та звітності.
Час, регіон, продукт: осі, за якими ріжеться кожен звіт.
Редагування виміру
07
Менеджер завантажень
Проблема
Вихідні дані приходили файлами звідусіль (таблиці, документи, зображення) і жили поза системою.
Гіпотеза
Якщо все вантажиться й зберігається в одному місці, джерела цифр перестануть зникати.
Рішення
Excel-файли, документи й зображення: завантаження та організація в одному місці.
Excel-файли, документи й зображення в одному місці, готові до звітів.
08
Користувачі та групи
Проблема
Доступи налаштовували по людині й по файлу, і з кожним новим відділом це ставало некерованим.
Гіпотеза
Якщо права давати групам за ролями, доступ масштабуватиметься разом із компанією, а не проти неї.
Рішення
Права на перегляд і редагування по кожному файлу; користувач може бути в кількох групах, тож доступ налаштовується за ролями, а не по людині.
Доступи за групами, а не для кожного окремо: це масштабується разом із компанією.
09
Воркфлоу та задачі
Проблема
Бюджетний сезон тримався на листуванні: хто що здав і що блокує, знали лише в переписці.
Гіпотеза
Якщо процес описати задачами з порядком і власниками, стан сезону буде видно без жодного листа.
Рішення
Структуровані процеси з упорядкованими задачами, призначеними людям: бюджетний сезон як керований конвеєр, а не листування.
Бюджетний сезон як процес із задачами, а не ланцюжок листів.
10
Вхід
Проблема
Вхід не давав зворотного зв'язку: незрозуміло, чи дія зарахована і що саме не так.
Гіпотеза
Якщо стани й валідація явні, людина зрозуміє, що пішло не так, з першої спроби.
Рішення
Автентифікація, перероблена з чіткими станами та валідацією.
Кожен стан задизайнений, і помилка каже, що виправити.
Стани й валідація
11
Онбординг для нефінансових користувачів
Проблема
Люди, які не є фінансистами, усе одно вносять цифри й читають звіти, і приходять по результат, а не по курс із продукту.
Гіпотеза
Якщо продукт веде за сценарієм і пояснює в контексті, нефінансові ролі впораються без окремого тренінгу.
Рішення
Основними користувачами є фінансисти, але в системі працюють і керівники та директори. Онбординг перебудувала навколо ведених флоу, контекстних підказок і туторіалів за сценаріями.
Нотатка
Найбільше супроводу потребують ті, хто заходить найрідше.
Результат
Вони заходять у продукт без окремого тренінгу.
Ключові рішення
02
Зустріти користувачів в Excel, а не проти нього
Проблема
Бухгалтери й менеджери живуть в Excel, а наші інші табличні взаємодії створювали тертя замість переваги.
Гіпотеза
Якщо взаємодія з таблицями віддзеркалює звички Excel, прийняття приходить само, а унікальні переваги продукту стають видимими, а не схованими за перенавчанням.
Рішення
Перебудувала табличні взаємодії під Excel-звички й підняла нагору переваги продукту (пов'язані дані, ролі, автоматизацію) поверх знайомої механіки.
Підтвердження
Модеровані сесії проти поточної версії дали пріоритезований список фіч, що пішов прямо в розробку.
03
Ad Hoc-звіти замість кастомної розробки
Проблема
Кожному клієнту були потрібні індивідуальні шаблони звітів, і кожен будувала команда розробки, а це довго й дорого.
Гіпотеза
Якщо користувачі зможуть збирати шаблони самі зі змінних, більшість запитів на кастомні звіти зникне.
Рішення
Задизайнила конструктор Ad Hoc-звітів: обираєш змінні, отримуєш свій шаблон, перевикористовуєш.
Підтвердження
Індивідуальна звітність без розробки в циклі: фіча скоротила роботу над кастомними шаблонами.
Результат
- Дизайн-система з нуля: патерни, UX-тексти, іконки, лоадери, кольорова ієрархія
- Навігація перебудована у два сайдбари з поведінкової аналітики
- Excel-нативні таблиці й дашборди, які люди збирають самі
- Ad Hoc-звіти скоротили кастомну розробку
Продукт із фундаментом: консистентні патерни, зрозумілі ролі та звітність, що більше не чекає на розробників.
Наступний кейс
Система запасів для мережі міні-маркетів
Android-застосунок зі сканером у центрі для обліку, поставок і щоденних задач мережі продуктових мінімаркетів. Єдина дизайнерка: від бізнес-моделі до бети в усій мережі, з тестуванням на реальних працівниках на кожному кроці.
Переглянути кейс