Проблема всех эссе о процессе проектирования — это то, что они читаются, как ханжеские упреки. Я понимаю, что вам не хочется слушать о том, что для выполнения работы, нужна организованность. Все это совершенно очевидно, но удивительно трудно делать изо дня в день, когда вы хотели бы изучать Framer и кодировать прототип. Так что я постараюсь это учесть.
Проблема с простотой
Раньше я считал, что процесс проектирования происходит следующим образом: Кто-то о чем-то думает; потом они просят меня нарисовать эскизы; я рисую эскизы; мы их кодируем, проводим пользовательское тестирование, и настраиваем; затем запускаем продукт.
На самом деле, когда приходит запрос, я обычно занят другим проектом. К тому времени, как я приступаю к работе, приходится спешить. Потом я показываю свои эскизы людям, и мы все спорим о мелочах визуального дизайна. Все заняты, все торопятся, и мы еще немного спорим. Потом, дизайнерам надоедает спорить, и они начинают разрабатывать то, что считают лучшим.
Мы пытаемся урегулировать наш спор пользовательским тестированием. Но мы не имеем четкого представления о том, что тестировать, исследователи заняты, и мы торопим испытания. В итоге мы понимаем, что спроектировали неправильный продукт. Когда пыль укладывается, я говорю что-то вроде: «Что случилось — я думал у вас есть план.»» А они говорят: «О, а мы думали, что у тебя был план!»
Когда члены команды чувствуют, что они отстали, или не имеют понятия что будет дальше, проблемы и разногласия кажутся непреодолимыми.
За этим следуют недоразумения и обвинения. В большинстве случаев, более реалистичный план помог бы нам всего этого избежать.
Как много времени это займет?
В конце концов, я стал лучше разбираться в том, на сколько затянется большой проект. Но всё еще оставалась одна проблема: никто мне не верил. Я мог предсказать, где возникнут трудности, но я не мог убедить людей принять меры, чтобы избежать их.
Мало кто хочет смотреть на процесс проектирования в реальном свете, чтобы признать, что он беспорядочен, требует сотрудничества и компромиссов. Проще опустить голову, сосредоточиться на своей работе, и надеяться, что у кого-то другого есть план.
В попытке заставить людей вкладываться в более реалистичные сроки, я начал аналитически относиться к проектам, над которыми работал, и стал прозрачным по поводу того, сколько проект займет времени. Я не хочу отбирать у вас удовольствие обнаружения собственных сроков, но надеюсь дать некоторое представление о том, куда действительно уходит время, и почему стоит ожидать некоторого беспорядка.
Оттачивание процесса в Facebook
Я присоединился к Facebook в качестве дизайнера во время особенно быстрых перемен. Продукты, которыми занимался один дизайнер, внезапно разбились на огромные куски инфраструктуры, поддерживаемые сотнями инженеров и приносящие миллионы долларов дохода.
Теперь отдельные дизайнеры несут ответственность за дублирование частей головоломки, которые вместе должны представлять целостный продукт.
Было очень интересно находить лучшие практики, которые бы позволили проектам эффективно развиваться. Я работал с партнером, который занимался исследованиями и небольшой группой дизайнеров. Нашей задачей было понять, как разные группы и отдельные люди себя организуют.
Мы придумали способ, который не особо отличался от того, что вы читали в большинстве книг или статей о процессе проектирования. Но наша модель приносила больше времени в начале процесса, которое можно было потратить на сопоставление исследований и требований, продумывание, тестирование и отбрасывание идей — по сути, все, что требуется, для перехода от грубого плана, к хорошему с наименьшими затратами.
- Понимание — Согласиться с проблемой, которую надо решить.
- Моделирование — Сузить мышление и описать концепцию визуально.
- Проектирование — создание продукта
- Запуск — Тестирование и координирование с рынком.
Утверждение модели
Я считаю, что люди больше склонны мне верить, если я прихожу к ним с данными. К счастью, у меня уже есть большая часть нужной мне информации. С тех пор, как я стал менеджером по дизайну, я смотрел, как работают разные команды, и тщательно документировал всё, что они делают.
Команды постоянно предоставляют отчеты о состоянии работы, с краткими заметками о ключевых событиях своих проектов в течение предыдущей недели. Я призываю их записывать только важные события, а не перечислять всё, что было проделано.
Анализируя эти записи, мне удалось собрать картину проделанной работы за предыдущие 6 месяцев. После еще 3-х месячного отслеживания наших проектов, у меня была картинка прогресса, достигнутого за 9-месячный период. Я сделал таблицу, в которой каждому проекту выделялась одна линия, и отметил основные события в жизни каждого проекта, в том числе:
- Когда мы впервые назначили проекту дизайнера или контентного стратега.
- Когда мы наконец договорились о том, что мы будем создавать.
- Когда мы все договорились о конкретном одном наборе эскизов.
- Когда исследование было наиболее полезным.
- Когда мы посчитали проект законченным. (как правило, это отмечалось тестом или альфа запуском.)
- Когда мы запустили продукт.
После того как я отразил всё это в таблице, я мог сделать шаг назад и сравнить различные проекты, большие и маленькие, и их конкретные временные рамки. В деталях, каждый проект был хаотичным и разным. Но на макроуровне, они соответствовали нашему теоретическому четырехэтапному процессу:
Поскольку продуктовые менеджеры не видели различия между этапами Понимания и Моделирования, первоначальные планы команд относительно того, что будет включать в себя дизайн были очень схематичны. В итоге всё сводилось к «сделай набросок».
Когда я спросил продуктовых менеджеров, сколько времени обычно занимает «сделать набросок» они ответили неделю, или две. На первый взгляд, это не кажется глупым. Обычно, даже со сложными продуктами, дизайнеры укладывались в это время. Но данные показали, что наше обычное время от «Назначить дизайнера» до «Согласовать наброски» составляло около 6-8 недель.
Что бы выяснить почему так происходит, потребовалось еще немного детективной работы.
Проклятие выражения «почти готово»
Я стал внимательно наблюдать за командами, которые находились на ранних стадиях проектирования. Я присутствовал на их еженедельных собраниях, и наблюдал, как они пытаются прийти к согласию. Процесс начинался хорошо. Они определяли, к чему стремились, и что будут проектировать.
Но когда команда начинала говорить о дизайне, возникали неожиданные споры и проблемы. Разногласия вокруг мелких деталей оказались огромной проблемой. Члены команды ходили кругами, пока кто-нибудь не находил решение, которое было достаточно близко к тому, чего они хотели, и пытался закрыть дискуссию, чтобы начать проектирование.
Это снова и снова приводило к новым проблемам и спорам. Поскольку команда полагала, что наброски «почти готовы,» они продолжали копаться в деталях.
Они не замечали, что на самом деле, не соглашаются по основным целям проекта.
Я видел команды, которые настолько застревали в этом круговороте, что они не могли продвинуться дальше и бросали проект.
Творческий цикл и смертельная спираль
Фаза Понимания нужна не для того, чтобы удовлетворить креативность дизайнера. Это время, за которое команде, нужно должным образом выразить свои идеи, и привести их в форму, в которой они могут быть реально оценены. Этим, как правило, занимается не только дизайнер. Все должны выразить свои потребности и мнения, а затем просматривать наборы эскизов, что бы эти мнения оценить.
Если я снова и снова повторяю какой-либо дизайнерский процесс, который должен помочь выразить новую идею, то это не зря потраченное время. Но если я постоянно возвращаюсь назад, чтобы, например, «посмотреть, как это будет выглядеть с чекбоксом, вместо выпадающего списка» — это значит, что я вожусь, с не относящимися к делу вещами, избегая реальных проблем, а также тот факт, что мы так и не договорились о том, что собираемся делать.
Вне цикла
Я нашел два основных способа, которые должны помочь командам избежать этих маленьких спиралей смерти. Первый — больше заботиться о том, чтобы объяснить, что нужно дизайнеру для того, чтобы создать полезные наброски. Это обычно приравнивается, к четкому отделению процесса выяснения того, что вы пытаетесь достичь (шаг Понимания) от выполнения набросков (шаг Моделирования).
Другой способ — сделать карту, будь то диаграмма Ганта или другая визуализация. Используйте свои навыки дизайнера, чтобы показать, где в процессе вы находитесь. Покажите ее другим членам команды и убедитесь, что вы находитесь в одной с ними точке.
Как бы страшно это не казалось, лучше признать различия в ожиданиях раньше, чем обнаружить их позже.
Когда все знают, что они далеко от финишной прямой, они, как правило, перестают к ней рваться.
Это может показаться простым, но то, где вы находитесь на самом деле — в отличие от того, где бы вам хотелось быть — радикально отличаются. Это не только избавит вас от головной боли, но также поможет вам создавать продукты, которые лучше послужат людям, для которых вы их разрабатываете.
Перевод статьи Тома Брокстона
