Дизайн процессов что это
Как дизайн-процесс упрощает работу веб-дизайнеру
На связи главред Upward School. В этот раз я хочу рассказать про дизайн-процесс и его роль в работе веб-дизайнера.
Представим ситуацию: к вам пришел клиент и попросил сделать интернет-магазин одежды для поколения Z. Вы подобрали красивые референсы, добавили видео для просмотра деталей образа — все по законам поколения. И когда магазин запустили, выяснилось, что есть упущения: пользователь при нажатии на карточку товара в разделе спортивной одежды, видит ее, читает содержание, но не видит хлебные крошки и не может вернуться на шаг назад, чтобы посмотреть все варианты. Да еще и поп-ап вылетает на весь экран каждые 30 секунд. От назойливого и непродуманного дизайна бизнес теряет заказы.
Представим ситуацию: к вам пришел клиент и попросил сделать интернет-магазин одежды для поколения Z. Вы подобрали красивые референсы, добавили видео для просмотра деталей образа — все по законам поколения. И когда магазин запустили, выяснилось, что есть упущения: пользователь при нажатии на карточку товара в разделе спортивной одежды, видит ее, читает содержание, но не видит хлебные крошки и не может вернуться на шаг назад, чтобы посмотреть все варианты. Да еще и поп-ап вылетает на весь экран каждые 30 секунд. От назойливого и непродуманного дизайна бизнес теряет заказы.
Сколько дизайнеров, столько и мнений. Каждый выработал, на основе опыта, свою схему взаимодействия с клиентом. И каждая из них верна, если работает.Мы делимся своим опытом и взглядом на последовательность действий, которые доведут проект до логического завершения с минимальным количеством правок.
Так вот, этапы дизайн-процесса:
1 — Проводите исследование: собираете информацию о бизнесе и пользователях.
2 — Структурируете данные и формируете текстовый прототип.
3 — Составляете мудборд: подбираете цвета, шрифты, формы, изображения.
4 — Собираете прототип без цветов и изображений: расположение заголовков, подзаголовков, текста и блоков так, как будет в итоговой работе.
5 — Соединяете прототип и мудборд — получаете дизайн-макет.
6 — Адаптируете макет под мобильные устройства.
7 — Презентуете проект заказчику*
8 — Упаковываете работы в кейс для портфолио (если нет NDA — договора о неразглашении).
*С заказчиком согласовываете текстовый прототип, мудборд, прототип и в конце презентуете финальный проект.
И помните, что лучше задать глупый вопрос, чем домыслить самостоятельно или сделать из серии «а, и так сойдет, лишь бы к сроку успеть». Кто работает по дизайн-процессу, у того сроки не горят.
Дальше рассмотрим первый этап дизайн-процесса — исследование. По сути, это фундамент вашей работы над проектом. Если спустит колесо логики сейчас, это скажется на всех следующих этапах.
Первый этап дизайн-процесса — исследование, которое начнем с изучения деталей о бизнесе заказчика.
Чтобы создать сайт, нужно понять:
1. Кто/что? Что за проект/продукт/услуга, позиционирование компании/бренда на рынке.
2. Для кого? Кто ЦА? Что им нужно?
3. Зачем? Какие задачи будет решать сайт?
4. Где? Когда? Как? Сколько?
Вопросы на понимание бизнес-процессов.Чтобы получить ответы на список выше, вам нужен клиент и правильные вопросы. Как понять, что они правильные? Только через собственный опыт и выполненные заказы. Их можно задать при помощи брифа или интервью. Второй вариант «вытащит» из клиента больше информации о проекте, чем первый. Ниже расскажем почему.
Бриф — это документ, в котором вы собираете все ключевые вопросы о клиенте, бизнесе и бизнес-процессах, конкурентах, потребителях, о цифрах, фактах, планах/целях. Как работает схема дальше:
1 — вы договариваетесь, что отправите на электронную почту в течение дня бриф и согласовываете дедлайн для заполнения;
2 — ждете ответ;
3 — получаете ответ, но в нем короткие фразы и недостаточно информации;
4 — вы созваниваетесь и договариваетесь, что бриф пришлете повторно для уточнения деталей;
5 — ждете, снов…;
6 — получаете заполненный бриф и понимаете, что клиент не понял половину вопросов;
7 — снова звоните.
Лучше сразу отбросить этот вариант или совместить с интервью, но так вы ставите между собой и клиентом электронную почту, которая затягивает процесс работы над сайтом.
Еще один существенный недостаток брифа — дает вам недостоверную информацию. Клиент может заполнять его в спешке, не быть осведомлен обо всех процессах и просто пропустить ответы на некоторые вопросы. Такого не случится на интервью, потому что вы будете задавать вопросы и контролировать ситуацию.
Интервью дает больше информации о бизнесе, помогает сориентироваться дизайнеру. Но есть нюансы, которые следует учесть. Поэтому составьте план проведения интервью по следующим шагам:
Шаг 1 — вы договариваетесь с клиентом, что берете время на сбор информации о нем: проводите исследование проекта/продукта/услуги и конкурентов, составляете для себя шпаргалку с вопросами.
Шаг 2 — назначаете дату и время встречи, которая удобна обеим сторонам. Это может быть личная встреча или звонок по Skype.
Шаг 3 — готовитесь к интервью: составляете список вопросов (метод 6 вопросов).
Шаг 4 — спрашиваете разрешение о записи разговора для возможности последующей транскрибации, чтобы вся важная информация сохранилась. Вы можете получить отказ, тогда делайте пометки по ходу разговора у себя в ежедневнике или на компьютере. На интервью удобнее ходить с напарником, который будет фиксировать информацию.
Зачем это нужно? Пока вы будете задавать вопросы, вам нужно следить за тем, как проходит интервью: все внимание сосредотачивается на сути и смысле ответов. Сложно одновременно осознанно слушать и фиксировать ответы. Если вы поняли, что памятки с вопросами не хватает для раскрытия вопроса, не бойтесь задать дополнительные. И не забывайте объяснять клиенту, зачем вы задаете тот или иной вопрос.
Шаг 5 — после встречи вы предупреждаете, что по итогам интервью соберете всю информацию и договоренности в документ, который пришлете на согласование в течение 1-2 дней.
Помните, что вы не только помогаете клиенту создать сайт с нуля, но и ведете его по всему процессу от начала и до конца. Поэтому спокойно объясняете какие действия будете совершать дальше и зачем — ориентируете на следующий шаг.
На этом этапе вы собрали вопросы у клиента. А теперь вам нужно собрать информацию у пользователей. Сильно углубляться не стоит, если это новый или небольшой проект.Подробнее про интервью с клиентом и пользователями мы расскажем в следующих постах и статьях.
Клиент обратился к вам за решением конкретной задачи. Но на рынке есть конкуренты, которые подобную задачу решали. Посмотрите, как они это сделали у себя.
Изучите их сайт и выделите плюсы/минусы решения задачи:
— удобно ли пользоваться сайтом: навигация, нет ли раздражающей рекламы; — структура, верстка и композиция: хорошо ли структурирована информация, выделено главное, создана визуальная иерархия;
— визуальная составляющая: наличие единого стиля, передает ли эмоции, какие ассоциации вызывает.
Собрать информацию о бизнесе клиента и конкурентах, это как получить только инь. Время собрать полную картину о проекте, провести исследования о пользователе продукта/услуги — ян.
Ниже мы привели некоторые из методов, которые помогут понять, кто пользователь конкретного бизнеса и как он думает, чтобы воспользоваться продуктом/услугой.
Метод исследования, который больше расскажет про пользователей проекта и сделает действия дизайнера точечными. Целевая аудитория проекта онлайн-магазина одежды может быть неоднородной, поэтому у вас должен быть портрет каждой из них.
Составляем образ группы. Например, аватар одной из групп — студент на последнем курсе университета. Что нужно о нем рассказать:
— имя, возраст потенциального студент,
— фотография, которая проиллюстрирует аватар группы. Можно взять с просторов интернет,
Дизайн-процесс: 7 шагов к идеальному проекту
Я, как и многие, на старте карьеры столкнулся с этой проблемой. Периодические заказы могли создать иллюзию того, что я все делаю правильно, но со временем я начал понимать, что в моей работе что-то не так.
Перед началом проекта у меня было воодушевление, а в ходе работы я непременно терял мотивацию. В итоге, мне хотелось как можно скорее закрыть проект, уже не думая о качестве работы.
Сила процесса
Это очень похоже на написание статей. Представьте, что вас попросили подготовить материал о таянии ледников. Конечно, вы что-то об этом слышали, но чтобы сделать качественный материал вам потребуется время на изучение темы и только набравшись знаний, вы сможете выполнить поставленную задачу. Так почему же дизайнеры думают, что могут сразу приступать к рисованию, минуя другие этапы?
Начинающие дизайнеры пропускают обязательные этапы по двум причинам. Во-первых, они не знают, что такие этапы есть. Им ведь никто об этом не говорил. Во-вторых, все начинающие дизайнеры придают слишком большое значение визуальной составляющей. В итоге, рисуется картинка, оторванная от реальных задач бизнеса.
Конечно, чем вы опытнее, тем проще сделать свою работу хорошо, но выстроенный дизайн-процесс помогает добиться лучшего результата специалисту любого уровня.
7 шагов к идеальному проекту
Давайте рассмотрим классический дизайн-процесс, который включает в себя 7 этапов:
1) Погружение в задачу
Понимание целей и задач бизнеса. Каким образом он зарабатывает? Какие цели и задачи стоят перед пользователями?
2) Исследование
Анализ полученной от заказчика информации. Самостоятельное исследование в открытых источниках: изучение конкурентов, схожих по механике сервисов и аналитических отчетов.
3) Генерация идей
Фиксирование полученных идей с прошлого этапа в текстовом виде или в форме зарисовок. Сравнение идей и выбор наиболее подходящих.
4) Продумывание сценариев
Определение ключевых и второстепенных сценариев. Поэтапная проработка основных сценариев.
5) Создание фреймворка
6) Поиск визуального стиля
Определение необходимого посыла бренда и выбор подходящих цветов, шрифтов и стилей элементов.
7) Дизайн макетов
Подготовка всех макетов и возможных состояний интерфейса для передачи их клиенту или разработчикам.
В любом процессе возможен возврат на несколько этапов, а возможно, и в самое начало. Это может произойти из-за того, что заказчику не понравилась ваша работа. Хотя правильная презентация способна минимизировать изменения. Или вы поняли, что совершили ошибку в проектировании. Например, выбрали не подходящую структуру или визуальный стиль не соответствует бренду. В этом случае нужно вернуться на несколько этапов назад и проделать часть работы снова.
Это всегда не просто, но лишь таким образом можно создать дизайн, который принесет вам удовлетворение и сделает вас более востребованным специалистом.
Суть процесса
Каждый этап дизайн-процесса приводит вас к решению. На старте карьеры мы все хотим поскорее приступить к рисованию, из-за чего наши работы получаются необдуманными и сложно применимыми к реальному миру. Помимо этого, такие работы сложнее презентовать и сейчас я покажу почему.
Представьте, что вы презентуете проект и заказчик спрашивает вас, почему такой-то элемент находится именно здесь. Или почему он именно такого цвета. Что вы ответите? Потому что это корпоративный цвет? Потому что это красиво? Или может потому что дизайнеру эта идея взбрела в голову? Как вы видите, ни один вариант не является убедительным. А когда вы прошли четкий процесс разработки идей и каждое ваше решение имеет смысл, его будет проще аргументировать.
Вместо того чтобы апеллировать к красоте, вы будете полагаться на конкретные факты. Они тоже могут относится к визуалу, но будут подкреплены логикой. Например, этот элемент располагается там потому, что он создает правильную композицию. Или находится в том месте, куда обычно смотрит пользователь. Или имеет такой цвет, чтобы привлечь внимание покупателя.
Хаос рождает жизнь: как мы построили эффективный дизайн-процесс
Работа над стартапом у нас может идти по нескольким сценариям, зависит от стартапера. Он может прийти с:
• идеей, от нас — дизайн и разработка
• идеей, от нас — только дизайн, если заказчик решает разработать проект со своей командой или другим агентством
• идеей и дизайном, от нас — разработка
Мы хотим поговорить о первых двух сценариях, о процессах в разработке поговорим как-нибудь в другой раз. Итак, приходит стартапер с идеей. Наша задача — подготовить концепт, а позже и весь дизайн.
Время чтения: 12 минут
Звучит легко. Если было бы так же на деле — этой статьи бы не было. Мы прошли долгий, тяжелый, местами невыносимый путь. Это даже хорошо, ведь без такого опыта организация дизайн-процесса не стала бы лучше. Меня зовут Юлия Вакуленко, я лид UI/UX дизайнер в Purrweb, хочу рассказать о нашем прошлом, настоящем и поделиться планами на будущее.
Глава 1. Старый дизайн-процесс
Раньше у нас не было ни портфолио на Dribbble, ни кейсов на Behance, поэтому каждому стартаперу мы предлагали за небольшие деньги посмотреть, на что мы способны.
Менеджер по продажам приходил к дизайнеру и говорил: «Есть проект, у тебя 2 дня». За эти 2 дня нужно было:
Нет, это не сюжет новой части фильма «Миссия невыполнима». У дизайнера было мало времени, чтобы все хорошо сделать. Мы укладывались в срок, но было сложно разобраться в деталях проекта. За 16 часов можно сделать крутой концепт, но проработать хотя бы на базовом уровне логику приложения не успеешь.
Дизайн-концепт задает общий стиль, логику и формат отображения контента. При этом концепт для интернет-магазина и мобильного приложения сильно отличаются между собой: первый обычно строится на главной странице, товарной позиции и выборке товаров, второй — на 2-3 ключевых экранах, демонстрирующих основную функцию.
Мы делали крутые, но не всегда реализуемые концепты — их можно сравнить с концепт-каром Lada XRAY. Представленный в 2012 году концепт приятно удивил — взгляните:
Оригинал концепта, опубликованный в 2012 году. Выглядит круто, не так ли?
Замысловатые формы, светодиодная техника, премиальные материалы отделки салона. Машина не затерялась бы среди лучших образцов мирового автопрома. Но с конвейера вышел совсем другой автомобиль.
Lada XRAY могла бы выйти такой, как в концепте, но ее цена выросла бы раз в 10. Так было и у нас. Мы не успевали проработать логику приложения, какая будет навигация, какие шаги будут делать пользователи. На выходе получался красивый концепт, но чтобы его реализовать, нужно было намного больше времени и бюджета.
С помощью концепта мы преследовали одну цель — впечатлить. В то время нам нужно было убедить заказчика, что мы не пальцем деланные. Концепты, которые мы тогда делали, можно сравнить с книжным магазином. Покупатель сразу видит красивые обложки, которые привлекают его внимание. Зачем? Чтобы он купил именно эту книгу, потому что покупатель не всегда знает, чего он хочет. Концепт готовился не столько для эффективности, сколько для эффектности.
Проблема в том, что заказчики забывают о своей целевой аудитории. Интерфейс Airbnb не работает в приложениях для здравоохранениям
Презентация концепта не дотягивала до желаемого уровня. Проджект-менеджер рассказывал стартаперу, какое решение предложил дизайнер, показывал макет и несколько экранов. Это были красивые 2-3 экрана в Figma, но это не дотягивало до уровня крутой презентации. Часто можно было услышать от заказчика: «Что это такое?», когда он смотрел на подготовленные экраны.
Два дня — слишком короткий срок, чтобы детально продумать концепт и еще подготовить презентацию. Если рождались новые идеи — не было времени над ними подумать, поэтому большая их часть уходила в стол и не возвращалась. Проджект-менеджеры старались донести задумку дизайнера до стартапера, но эти несколько экранов не создавали у заказчика впечатление завершенного концепта. Даже очень хороший концепт часто был недопонят.
Концепт, который мы готовили несколько лет назад
В лучшем случае стартапер приходил через неделю и говорил: «Все хорошо, но есть правки». Это в лучшем случае. Чаще всего время «на подумать» растягивалось — заказчик мог вернуться через месяц, полгода, год, либо вообще не вернуться. В итоге дизайнер не получал никакого фидбека, концепт уходил в стол, а если заказчик всё-таки возвращался — приходилось дизайнить приложение почти с нуля, потому что концепт часто терялся, если заказчик уходил подумать.
Если стартаперу понравился UI/UX дизайн, и он захотел остаться с нами, чтобы разработать и зарелизить проект — разработчики получали «что-то», что сделали дизайнеры. Каждый макет был уникальным, не похожим на предыдущий. В старом дизайн-процессе не было фреймворка, который помог бы и разработчикам, и дизайнерам.
Макеты мы раньше готовили на каком-то интуитивном уровне: дизайн-процесс был хаотичным. Часто на разработке всплывали интерфейсные проблемы из-за макета: то не хватало каких-то скринов, то некоторые флоу были не полностью проработаны, то еще что-то.
Бывало так, что заказчик, который ушел разрабатывать проект своей командой, возвращался с нашим макетом и спрашивал: «А как так вышло?». Говорили, что как-то так вышло и исправляли.
Жизнь разработчиков сильно усложнялась: им приходилось тратить кучу времени, чтобы разобраться в макете, самостоятельно вытаскивать элементы дизайна с каждого экрана. UI kit не был таким большим, как сейчас, и собирался так же, как и макет — какие-то элементы накидывались на отдельную страницу в Figma.
Разработчикам часто приходилось самим додумывать логику работы приложения, допиливать экран из готовых элементов, либо идти к дизайнеру и выдергивать его минут на 30, чтобы он что-то объяснил или доделал, например, дорисовал иконку, которой не хватает.
Команда есть, но ее нет
Два дизайнера никогда не работали одновременно над 1 проектом. Команда встречалась раз в неделю на планировании — это была вся командная работа. В остальное время дизайнеры работали отдельно друг от друга. Ситуация осложнялась неопределенным количеством часов на проект: один дизайнер мог за 5 часов закрыть ту задачу, на которую у другого уходило все 3 дня.
После концепта нужно было проработать всю функциональность приложения. Не всегда этим занимался тот дизайнер, который готовил концепт. Это была проблема, вытекающая из другой проблемы: неправильное планирование рабочих ресурсов. У дизайнера часто заканчивались задачи, он не знал, что делать, поэтому уходил помогать на других проектах. Получалось так, что дизайнер либо работал над одними концептами, либо доделывал проекты других людей.
Глава 2. Бриз перемен
За 3 месяца мы увеличились в несколько раз. Появилось 16 ребят с разным уровнем hard скиллов. Нужно было оценивать результаты работ дизайнеров, чтобы определять их сильные и слабые стороны.
С оценкой было далеко не все гладко — ей занялись проджект-менеджеры. Это как если бы картину художника оценивал строитель, который не разбирается в тонкостях работы маэстро и может сказать только: «Давай лучше работай».
Не все проджекты такие суровые, как может показаться, — некоторые из них делали скидку дизайнерам-новичкам: они же только начинают работать в компании, поэтому будут медленнее закрывать задачи. Нужен был системный и более объективный подход к оценке, чтобы грамотно распределять ответственность между дизайнерами.
Начали проводить ретроспективы проектов. Каждое ретро отнимало неописуемую кучу времени — остро встал вопрос с ресурсами. Одни недорабатывали, другие перерабатывали. Многие тогда сильно беспокоились за свои нервы.
То, что раньше не было проблемой, быстро в нее превратилось. Мы провалились под лед и начали паниковать. Было тяжело, но мы смогли собраться с духом и выкарабкаться из ледяной воды. В нашем дизайн-процессе появилось важное звено — старший дизайнер, который:
В конце 2020 года наш арт-директор Вадим ушел из компании. Это стало большой неожиданностью, потому что нас никто не предупреждал. Всегда можно было обратиться к дизайнерам поопытнее, а когда Вадим ушел — самыми опытными стали мы с Юлей. Поначалу мы были в шоке, но быстро адаптировались. Нужно отдать должное Вадиму — перед тем, как уйти, он начал меня и Юлю отправлять самостоятельно оценивать задачи перед тем, как стартовать проект.
Глава 3. Новый дизайн-процесс
Старший дизайнер — первый большой шаг на пути к переменам. Мы создали определенный уровень доверия и авторитета к себе, поэтому отказались от эффектных концептов за 2 дня.
Дизайн-процесс теперь начинается с кик-офф колла: сейлз-менеджер знакомит заказчика с проджект-менеджером. ПМ собирает кик-офф митинг, рассказывает команде об идее, задачах и деталях проекта. Проджект передает команде user stories, которые составил бизнес-аналитик, и старший дизайнер берет проект в работу. Процесс пресейла у нас тоже претерпел серьезные изменения, об этом вы можете почитать в статье ниже.
Мы начали собирать негативные референсы. Проджект-менеджер спрашивает у заказчика, что ему не нравится и что ему не нужно. Это не те узкие рамки, в которые мы загоняли себя и заказчика в старом дизайн-процессе : мы смотрели только на 2 кусочка большого пирога, а сейчас — на все, кроме этих двух кусочков. Мы не собираем положительные рефы, но если у заказчика они есть, то можем взять такие же цвета, шрифты, что-то такое, но не структуру.
Теперь подготовительный этап в дизайн-процессе длится не 2 дня, а 2 недели. На первом спринте готовим майндмэпу: дизайнеры погружаются в проект, разбираются в задачах, ищут подводные камни — получится ли реализовать предложения заказчика.
На одном проекте стартапер хотел анимированный космический корабль в приложении. Мы закинули эту задачу в бэклог, но на этапе составления майндмэпы поняли, что это растянет срок и бюджет проекта. Объяснили все заказчику — он решил отказаться от этой идеи.
Команда дизайнеров, когда готовит майндмэпу, прорабатывает всю логику приложения: разбирается, какие у проекта фичи, какие шаги будут совершать пользователи в приложении и какую заложить навигацию. Майндмэпа помогает избежать ситуации, когда заказчик говорит: «Это не то, что мне нужно». А занимает всего 8-10 часов.
Менеджер созванивается с заказчиком показывает готовую майндмэпу. Детали проекта обсуждаются на берегу, в моменте можно внести корректировки в работу, если:
Майндмэп — это 2 в 1: 1) дешевый способ подготовить почву для полноценного UI/UX дизайна, чтобы избежать многих интерфейсных проблем на разработке, 2) простой путь быстро притереться старшему дизайнеру к проекту, а заказчику к нам как к команде.
На втором спринте мы готовим концепт. Теперь это не 2-3 экранчика в Figma, а детальная презентация на Readymag. На странице дизайнеры рассказывают, что сделали, показывают все экраны, которые приготовили, и объясняют, как будет работать приложение. Еще мы готовим анимации и иногда видеоролик.
Презентация сервиса, который позволяет ресторанам размещать заказы онлайн — сделали с помощью ReadyMag, добавили анимацию и видео
Анимацией мы показываем сложные технические моменты, которые трудно, либо долго объяснять на словах. Если мы подготовили концепт быстрее, чем планировались, то можем еще упаковать видео в презентацию. В этом нет необходимости, но если у команды есть идеи, уходящие дальше концепта, то делаем. Так, на одном проекте команда придумала логотип приложения — запилили видео в конце презентации. Получился небольшой брендинг.
Заказчик теперь получает ссылку на страницу, в которую завернут концепт. Это приятно показывать, потому что проделана большая работа. Презентация проектов стала намного круче, качественнее и понятнее для нас и заказчиков. Нам намного проще показать, объяснить и донести до стартапера наш замысел.
Презентация на лендинге еще не проработанный продукт, но и не проект на стадии идеи, поэтому концепт не стыдно показать даже инвесторам. Если заказчику нравится концепт — подключаем второго дизайнера и работаем над визуалом всех фич приложения.
Концепт, который мы готовим сейчас, — уже не книжный магазин, а библиотека. К нам приходят не покупатели, а читатели, которые видят перед собой стеллажи с книгами, отсортированными по алфавиту. Читатель четко понимает, какую книгу он хочет взять, а библиотекарь максимально быстро ее находит. Концепт ради эффективности, а не эффектности.
Как только дизайнеры проработали все экраны, и заказчик готов перейти к разработке — неважно, с нами продолжает он работу над проектом или со своей командой, — мы начинаем готовить макет для разработки. Наша задача — правильно донести логику приложения до разработчиков.
В Purrweb мы выделяем определенное количество времени на разработку UI китов. Смотрите, как мы сделали UI kit для электронного кошелька с криптовалютой
Еще одно нововведение — старшие дизайнеры начали сопровождать разработку. Мы договорились с разработчиками, что будем писать отчеты — у кого какие недочеты были, которые всплыли на разработке. Это помогает дизайнеру лучше понимать процесс разработки и потом учитывать слабые моменты в интерфейсе.
Мы стараемся как можно чаще делать кликабельные прототипы. Это больше для заказчиков, чтобы они могли потыкать и посмотреть, какой у них замечательный сервис. Но прототипы полезны еще дизайнерам — можно найти какие-то дыры в дизайне и на берегу их закрыть. Кликабельные прототипы не настолько нужны программистам, как макет для разработки или UI kit, но к ним можно обращаться, если в навигации приложения что-то непонятно.
Настоящая дизайн-команда
Теперь на проекте обычно работают 2 дизайнера одновременно, иногда 3, и даже 4. Не всегда резонно подключать больше 2 — старшему дизайнеру будет сложнее ревьюить работы. Но если нужно больше — подключим еще людей к проекту.
Мы начали перемешивать команды между собой, чтобы дизайнеры могли еще больше обмениваться экспертизой и опытом. Запустили бета-версию карты компетенций, которая помогла каждому дизайнеру понять:
Карта подготовила почву для разговора на тему личностного роста дизайнеров и выявила узкие места во взгляде на сокомандников — непонятные ситуации и субъективные оценки, которые в моменте обсуждались на перфоманс-ревью. Например, старший дизайнер мог ошибочно оценить человека.
Увеличилась скорость работы на проектах. Если раньше она ограничивалась рабочей неделей одного человека, то теперь задачи на 80 часов мы можем закрыть за 40 или еще быстрее, потому что на проекте одновременно работают больше 1 дизайнера.
Проблемы с планированием рабочих ресурсов больше нет. Мы начали планировать задачи на каждый день — теперь понимаем, в какие дни, какие дизайнеры на каких проектах будут работать. Количество часов на проект оценивается старшим дизайнером вместе с бизнес-аналитиком на стадии пресейла. Стало намного проще формировать ожидания заказчикам и соответствовать им. Теперь дизайнеры не попадают в ситуации, когда у них нет задач, и они не знают, что делать.
Глава 4. Еще не конец
Мы практически с нуля построили рабочие процессы и сделали их прозрачными. Создали исправно работающую систему управления проектами, обмена опытом внутри команды и коммуникации с заказчиком. Старт проекта отлажен, предсказуем и всем известен. Дизайн-процесс идет по выработанному фреймворку.
Однажды я ушла в отпуск, и проект передали другому дизайнеру, который не был в контексте задач. В итоге что-то сделали не так, как хотел заказчик, вроде как цвет кнопки, к которому дизайнер добавил градиент с другим цветом. Некоторые предложения заказчика вообще были утеряны.
Теперь если лид дизайнер планирует уйти в отпуск, то ему нужно ввести другого дизайнера в контекст и объяснить задачи, чтобы дизайн получился таким, каким задумывался, и чтобы все предложения стартапера не потерялись.
До недавнего времени мы пользовались Trello — у каждого дизайнера была своя доска в таск менеджере, где отслеживались задачи по проекту. Мы давно планировали отказаться от Trello, а когда на одном проекте начали работать минимум 2 дизайнера — то старый таск менеджер окончательно перестал нас устраивать. Стало трудно отслеживать задачи по проектам и без проблем передавать их другим проджект-менеджерам.
Самая крутая фича в ClickUp, от которой мы больше всего кайфуем — возможность вести вики проекта. Теперь когда нужно будет передать работу другому проджекту — можно не бояться, что какие-либо материалы или информация потеряется. Новый таск менеджер на ближайшие год-два будет полностью нас устраивать.
Trello — хороший инструмент, он отлично справляется с базовыми потребностями небольших проектов. Но когда проект выходит за рамки 200 часов и на нем работает больше одного дизайнера — нужен функциональный и кастомизируемый таск менеджер. Мы только-только мигрировали с Trello на ClickUp, и даже его бесплатная функциональность существенно повысила уровень комфорта в нашей работе.
Глава 5. Планы на будущее
Мы набили много шишек и продолжаем их набивать. Какие планы на будущее?
— Вырастить новых старших дизайнеров, чтобы масштабировать дизайн-процесс и быстрее интегрировать в работу новичков.
— Повысить детализацию майндмэпы: хотим добавить в нее информационную архитектуру.
— Начать объединять дизайнеров в команды побольше, чтобы обмен опытом шел еще активнее.
— Вести документацию по проекту: как только все привыкнут к ClickUp — начнем хранить в нем всю необходимую документацию прямо внутри проекта.
Изменились не только мы — изменились и заказчики. Стартаперы стали как-будто лучше разбираться в UI/UX дизайне и стали больше прислушиваться к предложениям дизайнера. Хочется верить, что наш блог способствует этой крутой тенденции.
Всю эту долгую дорогу мы прошли с замечательными людьми, кто ушел, кто остался с нами. У нас появилось богатое портфолио на Dribbble и великолепные кейсы на Behance, где наши дизайнеры показывают свои скиллы. Мы проделали большой путь и ненадолго остановились в придорожном баре, чтобы рассказать эту историю. Теперь пора снова в дорогу — еще увидимся!