Проект для міністерства: як знайти ключик до успіху через комунікацію

Nadiia Bulatova
OffGrid Design Community
10 min readDec 6, 2022

🖥️ Intro

У цій статті ми б хотіли поділитись досвідом роботи над покращенням системи управління ефективністю, яку відносно нещодавно запровадили у Міністерстві економіки України та розповісти про шлях роботи над проектом зі сторони дизайн-команди.

Ви не зустрінете звичного Сase Study чи описів дизайн-процесів, адже ці речі ви можете із легкістю знайти у просторах інтернету. Ми хочемо розповісти про шлях до покращення системи, акцентуючи на проблемах, з якими ми зіткнулись, способах їх вирішення та, звичайно ж, факапами 🥴, куди ж без них.

🤝 Team

💪 Preparation

Все почалось із дизайн-курсів у OffGrid Design Community. Наша команда складалась із 6 людей (четверо студентів 👼 та два ментори 👩‍🏫), які були розкидані по різних містах. На той час ще усі жахались від COVID-19, тому навчання було віддаленим, а всі розмови, здебільшого, велись через інтернет. Кожен із нас мав основну роботу, тому часу на навчання та повноцінний проект було обмаль, окрім того, у кожного свій графік та стиль життя.

Це, власне, і стало першим челенджем з яким ми зіштовхнулись: налаштувати командну роботу таким чином, щоб все працювало злагоджено, як цілісний механізм ⚙️ та не давало збою. У цьому нам допомогли такі сервіси як:

  • Сoda (де ми зберігали та структурували усю інформацію по проекту).
  • Trello (де ми складали план дій, розбивали його на задачі та ставили естімейти).
  • Figma (де ми проводили воркшопи і розробляли, власне, сам дизайн) та інші корисні тули.

Для початку, нам потрібно було знайти реальний проект. Він мав бути соціальним та розв’язувати актуальні проблеми. Ми почали свій пошук із соціальних мереж, а також серед знайомих. Досить швидко назбирався список із цікавих проектів, серед яких ми обрали від Мінекономіки, адже саме цей варіант був складним та інтригуючим водночас. Зваживши всі “за і проти”, а також, оцінивши, чи подужаємо ми такий відповідальний проект — приступили до роботи.

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

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

Проте, наявний продукт для трекінгу задач ⏱️ виявився не дуже зручним для користувачів: вони губились в інтерфейсі, у них були труднощі із відстежуванням та розподілом задач для колег. Інтерфейс був доволі складним навіть для досвідченого користувача систем управління проектами, такими як: Jira, Trello чи Asana.

📝 Kick Off

Ми сконтактували із замовниками, для того аби чітко прояснити ціль нашої роботи та зрозуміти із чим будемо мати справу.

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

Переломним моментом стало те, що нам озвучили обовʼязкову умову — підписання NDA.

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

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

Ознайомившись з відеоінструкцією по використанню програми та побачивши основний шлях, який проходить користувач, ми змогли оцінити об’єм та структуру платформи. Маючи загальне уявлення про завдання, наша команда склала покроковий план підходу до розв’язання даної проблеми з розрахунком часу ⌛ (враховуючи обмеження курсу — 3 місяці) на його виконання. Також, ми визначили ролі та відповідальність кожного члена команди, що стало теж непростим викликом, оскільки було необхідно навчитись працювати як одне ціле і йти на компроміс.

Ще одна проблема у нас трапилась одразу на наступний день після підписання NDA — один із наших дизайнерів покинув команду. Тому, поки одна частина команди клопотала собі голову 🤯 як мʼяко про це розказати клієнтам, щоб вони в нас не розчарувались, інша частина розпочала активну підготовку до вивчення самого продукту та підготовки до інтерв’ю. Важливість цієї ситуації полягала у збереженні мотивації нашої команди, а також довіри наших клієнтів та запевненні їх, що це жодним чином не вплине на проект.

📊 User Interview & Survey

Незважаючи ні на що, ми з головою поринули у роботу та склали скрипт для інтервʼю із користувачами 📝, домовились, хто буде фасилітувати розмову, а хто робитиме нотатки.

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

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

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

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

Насправді виявилось усе навпаки — користувачі були дуже раді, що комусь цікава їхня думка, вони готові були розказувати про свій біль (про це взагалі окрема історія) та зустрічатись додатково для тестувань і уточнень в разі необхідності.

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

📈 Define

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

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

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

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

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

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

🧠 Ideate

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

Ми винесли усі “болі користувачів” на карточки 📃 та згрупували їх по категоріях. Після цього провели 2 сесії брейншторму із нашими стейкхолдерами, де ми генерували ідеї та пропонували рішення, які б могли розв’язати наші проблеми.

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

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

💻 Prototype & Design

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

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

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

🛠️ Problem Solving

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

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

Приклад каскадації

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

І врешті-решт, організувавши командну сесію брейншторму та розбираючи усі наші дослідження — рішення було знайдено 🏆!

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

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

Втомлені, але натхненні ми розуміли, що ціль вже дуже близько і це додало нам неабиякого ентузіазму 😎!

🤩 Feedback + Summary

Завершивши роботу над новим дизайном, ми підготували клікабельний прототип і призначили мітинг, щоб презентувати замовникам результати нашої роботи.

Ми підготували дві пропозиції проекту:

  1. Вдосконалення наявної системи за допомогою мінімальних змін.
  2. Кардинально нове рішення, яке зробить систему значно ефективнішою та зручнішою для користувачів.
Система до та після нашої роботи

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

Для нашої команди це є найбільшим досягненням, адже ми відчували, що наша робота має вплив на роботу самого Міністерства й, можливо, це маленький вплив на долю нашої держави 💙💛.

Після завершення проекту ми зібрались нашою командою, щоб провести підсумки і зрозуміти, що крутого в наше життя приніс цей проект. Так, ми опанували великий багаж досвіду пов’язаний з проведенням різних активностей, засвоєнням різних методів і практику над реалізацією проекту. Також ми зрозуміли, що робота над вже існуючим проектом насправді важча від стартапу. Але головне правило, яке ми засвоїли “Комунікація — наше все”!

Незабаром, в якості подяки, ми отримали мерч Ukraine WOW 🇺🇦, і тепер носимо його з гордістю, відчуваючи маленьку приналежність до позитивних змін в нашій державі!

🧐 What’s Next?

На жаль, війна в Україні принесла зміни в усі сфери життя, зокрема і на плани цього проекту. Ми поцікавились у наших стейкхолдерів як успіхи із проектом на даному етапі.

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

Бажаємо команді підтримки Мінекономіки успіхів 💫 у розвитку системи! Ми щиро вдячні за довіру і крутезну співпрацю!

--

--