Щоб ефективно будувати продукт, треба мати фреймворк керування командами дизайнерів і розробників. В іншому випадку відсутність структури призведе до небажаних простоїв.

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

Коли постала потреба відповідати за команду дизайнерів, я не знайшов належну інструкцію в мережі, тому почав створювати свою. Тепер хочу поділитися власним досвідом комбінування ролі розробника і дизайн-менеджера.

Teamwork framework

Пропоную побудувати фреймворк з нуля. Спочатку нам потрібно визначити дві речі:

• у чому полягає результат роботи дизайнерів?
• що дизайнерам необхідно для коректного розуміння завдання?

Інакше кажучи, це Output (результат) дизайн-завдань і Input (вхідні дані) дизайн-завдань.

Вхідні дані → дизайн-завдання → результат

Що дизайнери дають «на вихід»

Мета дизайну — допомогти розробникам будувати кращий продукт. Дизайн сам по собі не має сенсу для користувача, натомість готовий продукт має. Результатом роботи дизайнера має бути визначений таск для розробників, а точніше, візуальна частина таску.

Один зі способів описати завдання — це розробити прототип Figma і додати його в тікет на борді розробників. Давайте проговоримо, що потрібно дизайнерам для створення цього прототипу.

Вхідні дані → дизайн-завдання → результат

Що потрібно дизайнерам «на вхід»

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

Спрощений приклад User Flow

Потім я проводжу дзвінок з дизайнерами, щоб переконатися, що вони зрозуміли всю картину (під час розмови можуть виникнути правки User Flow від дизайнерів). Інша мета зустрічі – розділити User Flow на тікети. Щойно ми опишемо окремі завдання, ми «пройдемося» ними і вирішимо, хто буде відповідати за кожне з них.

Переконайтеся, що всі тікети містять чекліст «підфіч» для кожної фічі. (Фіча “А” готова, якщо користувач може зробити X, Y, Z). Це допоможе і розробникам, і дизайнерам з подальшим рев’ю.

Підсумовуючи, вхідними даними дизайн-завдань є User FLow.

Дизайн-спринт

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

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

Ітерації дизайну від ескізу до фінального результату

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

Проте і розробникам не варто «забивати» на ідею дизайнера. Якщо її відклали на потім, слід повернутися до концепту в слушний момент. Інакше мотивація дизайнерів щось пропонувати зникне.

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

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

Мені здається, розробники частіше цінують закономірності, а дизайнери – унікальність. Скажімо, вебпродукт вже має 3 компоненти кнопки. І дизайнер вирішує в новій фічі зробити нову кнопку.

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

Щоб робота розробників ішла плавно, дизайн-менеджер має перевірити, чи дизайн відповідає таким вимогам:

• всі лейаути зрозумілі, їхня логіка і закономірність очевидні;
• немає рандомних кольорів, шрифтів, розмірів (наприклад, ваш основний розмір шрифту 16px, але чомусь прототип містить шрифти на 15px та 17px);
• всі нові елементи додані до списку figma-компонентів;
• кожен тікет/фіча має окремий Figma Flow.

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

Agile в дизайні

Оскільки розробники приступають до імплементації, дизайнери можуть працювати над наступним спринтом.
Рекомендую розділити робочий простір Figma на дві частини:

• Draft
• Stage

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

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

І цикл повторюється:

Беклог → User Flow → Дизайн-завдання → Завдання розробки

Підсумки

Життєвий цикл фічі

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

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

Кожен менеджер має розробити фреймворк для своєї унікальної команди. Я сподіваюся, що мої міркування допоможуть вам сформувати власні ідеї.