Лого vc.ru

Как устроены дизайн-процессы в Facebook: понимание, моделирование, построение и запуск

Как устроены дизайн-процессы в Facebook: понимание, моделирование, построение и запуск

Продуктовый дизайнер Facebook Том Брокстон в своём блоге на Medium привёл четырехэтапную модель, которая помогает команде оценить срок разработки проекта и избежать лишних разногласий.

Редакция рубрики «Интерфейсы» публикует перевод материала.

Поделиться

Писать статьи о процессе разработки — неблагодарное дело. Автор невольно кажется этаким ханжой, который развлекает читателей байками о чьей-то успешной жизни. Я понимаю, что вы не хотите читать очередной текст о пользе GTD. Всё довольно очевидно, но трудно заставить себя день за днем исследовать процесс проектирования, когда нужно срочно изучать Framer и писать прототип. Поэтому просто расскажу о своём опыте.

Незнание порождает проблемы

Я привык думать, что разработка продукта происходит примерно так: кто-то что-то придумывает и просит меня подготовить несколько мок-объектов, я их делаю, потом мы пишем код, проводим пользовательское тестирование и настраиваем, а в финале запускаем продукт.

Моё изначальное видение типичного процесса разработки

На самом деле, когда приходит запрос, я обычно слишком занят другим проектом. Спустя какое-то время я могу приступить к новому делу, но теперь нужно торопиться. Я показываю моки моим коллегам, и мы обсуждаем все детали визуального дизайна. Коллеги тоже очень заняты и торопятся, но мы продолжаем спорить. Разработчикам это надоедает, и они начинают делать тот вариант, который кажется им наилучшим. Но мы по-прежнему продолжаем дебаты.

Типичный процесс разработки в моём случае

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

В конце концов у всех появляется ощущение, что мы сделали что-то не то. Когда страсти немного утихнут, я произнесу нечто вроде: «Что происходит? Я думал, у вас есть какой-то план». И ребята ответят мне: «Да ты что, мы думали, это у тебя есть план!».

Когда члены команды отстают от графика или не знают, куда двигаться дальше, разница во мнениях кажется непреодолимой

Следом тут же начинаются недоразумения, неопределённость со сроками и поиски виноватых. Всего этого можно было бы избежать, будь у нас более реалистичный план.

Сколько времени потребует проект

Постепенно я научился более или менее точно предсказывать, сколько времени может потребовать большой проект. Правда, осталась одна проблема: мне никто не верит, как будто я Кассандра, а не менеджер проекта. Я могу предсказать, когда начнутся бесконечные споры, но не могу убедить людей предпринять меры, чтобы их избежать.

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

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

Организация процессов в Facebook

Я пришёл работать дизайнером в Facebook как раз тогда, когда в компании начался период особенно быстрых изменений. Продукты, которыми раньше занимался один-единственный дизайнер, вдруг обросли огромной инфраструктурой. Они стали приносить миллионы долларов и требовать поддержки сотен разработчиков.

Сейчас каждый дизайнер отвечает лишь за небольшой паззл целого продукта

Мне очень нравилось искать способы эффективного ведения проектов. Мы с партнёром и небольшой группой дизайнеров изучали, как разные команды и отдельные разработчики организуют рабочие процессы.

В итоге мы выработали практику, непохожую на те, что рекомендуют в большинстве книг или статей по управлению процессами. Наша модель подразумевает больше времени на исследования и обработку запросов, мозговые штурмы, тестирование и отсеивание идей — на то, что обычно делается на ранних стадиях разработки. Именно это позволяло нам превращать грубый набросок в подробный, хорошо продуманный план с кроссфункциональной поддержкой.

Четыре этапа процесса разработки:

  1. Понимание — определение проблемы, которую предстоит решить.
  2. Моделирование — фокусировка видения и визуальное описание концепта.
  3. Построение — проектирование и разработка продукта.
  4. Запуск — тестирование и координация с маркетингом.

Я заметил, что многим продуктовым менеджерам и проектировщикам трудно принять этот подход. Они считают, что тратить столько времени на этап понимания слишком расточительно. Они думают, что уже знают все ответы и что хороший разработчик выдаст им отличный дизайн, который они «узнают сразу же, как только увидят».

Я решил убедить их, что менее оптимистичный прогноз даст лучшие результаты.

Как я искал доказательства

Я заметил, что люди больше склонны доверять моим словам, когда я подкрепляю их цифрами. К счастью, у меня уже была кое-какая информация. С тех пор как я стал менеджером проектов, я всё время наблюдал за тем, как работают разные команды, и тщательно документировал всё, что они делали.

Эти команды, в свою очередь, обновляли статус проекта и добавляли короткие заметки о ключевых событиях за прошедшую неделю (я просил их записывать только важные события, а не перечислять всё, что было сделано).

Проанализировав эти записи, я воссоздал всё, что происходило в предыдущие шесть месяцев. Затем я отслеживал все наши проекты ещё три месяца — получилась картина прогресса за девятимесячный период. Я свёл все данные в таблицу, представив каждый проект в виде строки. Главные события в жизни каждого проекта включали в себя следующие моменты:

  • Когда мы впервые привлекли к проекту разработчика или контент-стратега.
  • Когда мы чётко договорились о том, что именно хотим создать.
  • Когда мы все согласились с конкретным набором мок-объектов.
  • Когда наши исследования принесли наибольшую пользу.
  • Когда мы признали, что продукт готов (обычно это отмечается каким-то событием вроде Bug Bash, теста или альфа-запуска).
  • Когда мы официально запустили продукт.

С таблицей можно было сравнивать разные проекты (большие и маленькие) и сопоставлять их временные графики. Хотя проекты были не похожи один на другой, на макроуровне каждый из них сводился к четырёхэтапному процессу:

Реальные сроки отличались от запланированных, особенно для первых этапов проекта.

Поскольку обычно продуктовые менеджеры не делали различий между этапами понимания и моделирования, начальные планы по поводу разработки были очень неясными и часто формулировались просто как «сделать мок-объекты».

На мой вопрос, сколько времени на это потребуется, менеджеры отвечали, что одна-две недели. На первый взгляд, это вполне обоснованный прогноз, разработчики довольно быстро создают мок-объекты даже для сложных продуктов. Но реальные данные показывают, что обычно от момента, когда мы привлекаем к проекту разработчика, и до согласования мок-объектов проходит около шести-восьми недель.

Чтобы выяснить, где кроется ошибка и почему так происходит, потребовалось почти детективное расследование.

Это проклятое «почти готово»

Я стал детальнее наблюдать за командами на ранних этапах разработки. Посещал их еженедельные кроссфункциональные митинги и следил за тем, как именно они пытаются прийти к соглашению. Начиналось всё прекрасно: люди определяли, чего они хотят и что именно собираются разрабатывать.

Но когда команды перешли к обсуждению дизайна, появились неожиданные проблемы. Несогласие по небольшим вопросам приводило к ожесточённым спорам. Члены команды долго ходили по кругу, пока кто-нибудь не находил более или менее подходящее решение. Тогда команды принимали этот вариант.

Подобные разногласия возникали снова и снова, ведь команды верили, что мок-объекты «почти готовы» и можно спокойно обсуждать детали. Они не замечали, что на самом деле не могли договориться по принципиальным вопросам, связанным с разработкой. Я видел команды, которые настолько зацикливались на этом этапе, что вынуждены были прерывать проект.

Креативный цикл против «спирали смерти»

Довольно долгая фаза понимания нужна не для того, чтобы удовлетворить творческие потребности разработчиков. В это время вы можете попросить команду выразить все их идеи должным образом и придать им форму, которая позволит реалистично их оценить. Обычно в том, что проект затягивается, виноват не дизайнер, а те, кто выражает свои мнения и зацикливается на многочисленных мок-наборах, чтобы эти мнения оценить.

Одна из самых полезных для разработки вещей, которую вы можете сделать, — не дать команде раньше времени оценивать, насколько реализован проект

Если я собираюсь заново пройти цикл разработки, чтобы отработать новую идею, — это нормально, это не напрасно потраченное время. Но если я зацикливаюсь на том, чтобы «посмотреть, как бы это выглядело, если бы вместо выпадающей была флажковая кнопка», я закопаюсь в бесполезных данных и упущу реальные проблемы, не говоря уже о том, что мы так и не договоримся, что же нам нужно на выходе. Это и есть «спираль смерти».

Как выйти из цикла

Я нашёл два основных способа избежать подобных циклов на мелких итерациях. Один из них — как можно тщательнее выяснить, что нужно разработчику, чтобы создать полезные мок-объекты. Обычно это достигается за счёт чёткого выделения этапа понимания: в это время вы должны выяснить, что именно хотите получить, создавая мок-объекты (на этапе моделирования).

Другой путь — создать карту (диаграмму Ганта или какую-нибудь другую), чтобы определить, на каком этапе процесса разработки вы находитесь. Покажите эту карту другим членам команды и спросите, соответствует ли это положение их видению ситуации.

Как бы это ни пугало, лучше сразу принять разницу в ожиданиях, чем обнаружить её позже

Когда кто-то знает, что он уже около финишной черты, он не очень-то рвётся её преодолеть.

Возможно, это звучит слишком просто, но есть большая разница между тем, чтобы знать и предполагать. Тот этап, где вы сейчас находитесь, и тот, где вы хотели бы быть, — не одно и то же. Осознав это, вы избежите многих потерь и разочарований, а также сможете значительно улучшить качество своих продуктов.

Вот почему исследование и обсуждение процесса разработки стоит ваших усилий.

Присылайте свои колонки и интерфейсные кейсы на interface@vc.ru

Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

Ненавижу пейсбук за их UI/IX, за их поддержку и не понимаю, почему в 2016г люди продолжают пользоваться этим г..ном. Пытаюсь сейчас продвигать через пейсбук олин небольшой продукт для узкой целевой аудитории: все взаимодействие с системой и с пользователями через нее - это примерно как на том скетче с карлючками. Собственно, из статьи я понял, откуда это у них берётся - это все изначально так разрабатывается, хренпоймикак.

Вот вот. Сверх популярная сеть. А юзабилити - дебилити. Почему, как так?

0

Честно говоря нифига не понял. Одну мысль близкую мне уловил - зацикливание на мелочах - это дикая проблема бесконечные правки сайта до идеала.

Это кстати довольно распространенная проблема - вместо того чтобы проверять концепцию и заниматься развитием, перекрашивать кнопки в другой цвет.

0

да, пытаешься своим вкусом что то решить, где только a/b тесты помогут и кажется что из за этого конверсия рухнет если не проведешь день над условной "кнопкой"

краткое содержание:
"у нас до сих пор нет ясной идеи..."
но нам платят, и много...
сделаю вид, что занят разработкой...
нарисовал красные каракули....
голова слегка кружится...
статью не писал,
просто стошнило на бумагу...
!!! опубликовали???
...

Вот почитал и думаю:
То ли совсем идиот и они на 10 лет ушли вперед от нас по развитию.
То ли какие-то сказки для взрослых, чтобы обосновать свои ЗП и бонусы дизайнеров в ФБ.

Но по факту то, ни разу не видел что б ФБ приводили в пример как образец UX/Ui.
Или всеж просто не понимаю...

Короч запутали меня совсем).

из-за этих кретинов я немогу найти коллег и добавить их, хотя знаю их фио и т. д. это просто невозможно(

Номер телефона не проще чем ФИО?

0

Но мы-то знаем как там дела на самом деле=)

0

Отличный текст. Работаем дальше.

ФБ - конечно уникальное в своем роде явление. Интересно, что должно произойти, чтобы эта непотопляемая говняшка наконец затонула и освободила место под солнцем?

0

Я понял наконец-то! Успешный дизайнер - в душе копирайтер. Когда нарисовал херню и никто не в восторге, всегда можно запилить статью или написать книгу, где все типа обосновывается, а кто не понял тот тупой и вообще не в тренде.

0

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
Salawat Waliullin

(экологии)

«Добро пожаловать в 2030 год»: член датского парламента о счастливой жизни без приватности и личных вещей
0
Salawat Waliullin

Насчет эконологии в Дании не уверен.
Насчет технологии тоже.
Скорее всего в каждом большом здании будет 3д-принтер, и в каждой комнате.
При необходимости он будет печатать все, от еды и коммуникаторов, до машин и нано-машин.
Города будут завалены мусором, но его будут постоянно убирать роботы.

Социальные пузыри, о которых она сейчас говорит, уже стали новым бичом цивилизации - их будут использовать в переворотах, как на Украине против Януковича, для победы на выборах, как в США 2016.
Люди будут заново учиться создавать и поддерживать сильные социальные связи.
Слабые социальные связи перестанут цениться вообще - все будут знакомыми со всеми.

«Добро пожаловать в 2030 год»: член датского парламента о счастливой жизни без приватности и личных вещей
0
Игорь Арнаков

Хорошая статья(нет).В том смысле хорошая, что хорошо демонстрирует логику стандартного работодателя.Суть тонны текста в ней легко свести к одной фразе:сложно найти нормального спеца на нашу смешную зарплату-мир несправедливо устроен,хнык-хнык. Причем отсутствует понимание элементарной вещи (которую даже школьник в состоянии понять)-хороший специалист и низкая зарплата-понятия в принципе несовместимые.

Почему в Санкт-Петербурге сложно найти дизайнера интерфейсов
2
Ефим Дутый

Скорее нет, чем да.
Правильно вокруг пишут, на нынешнем рынке труда быть "просто дезигнером" - дыра. Либо вы "круты", что в области дизайна означает в первую очередь громкие имена студий/заказчиков (потому что оценить сам дизайн в портфолио не может чуть менее чем никто, а тут - верификейшен). И стучите всем этим "аж кушать не можем как хотим гениального дизайнера на 700 баксов в месяц" по губам. Либо вы не круты, и идете по десять штук рубль, шо те старушки.

Почему в Санкт-Петербурге сложно найти дизайнера интерфейсов
0
Ефим Дутый

Ааааабажаю такие "статьи".

1. Мы предлагаем уг "вычесть из опыта" проекты и смешные зарплаты. Так что все приличные дизайнеры уехали от нас в Москву или за границу. Бида бида!
2. Здорово бы найти гения из оставшихся. Чтоб чудо-работал и чудо-терпел. По слухам, они есть в фейсбуке.
3. Такие ребята нарасхват, но все равно хорошо было бы, чтоб они написали нам МОТИВАЦИОННОЕ ПИСЬМО! (Всегда лучший ПОВОРОТ подобных кулстори)
4. Десять пунктов мало описать, какие придурки и неумехи шлют нам мотивационные письма.

Число пи, простите, здец.

Почему в Санкт-Петербурге сложно найти дизайнера интерфейсов
1
Показать еще