Автор: Ян Австрейх

Переводчик, копирайтер. Дизайн и психология.

Евгений Эшану рассказал про принципы, которые помогут создать хороший продукт. Это перевод его статьи, цитаты взяты из книги «It Doesn’t Have to Be Crazy at Work».

Дизайн-процесс: больше заморочек vs меньше заморочек

Если вы хотите создать что-то великое, нужно не тратить больше времени и ресурсов на решение проблемы, а меньше заниматься ерундой

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

Есть способ упростить процесс и сделать его более эффективным. Недавно я прочитал книгу ребят из Basecamp «It doesn’t Have to Be Crazy at Work», в которой они делятся практическими советами по управлению компанией, продуктом и командами. Я почерпнул из неё четыре принципа, которые помогут создать качественный продукт.

1. Найдите время спокойно обдумать идею

Реакция на чужую идею: «у нас нет ресурсов на это» vs «давай уделим время, чтобы всё обдумать»

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

Так бывает не всегда. Обычно кто-то быстро вскакивает с места и говорит, почему идея никогда не сработает. Это неправильно.

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

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

Почему не сэкономить время и не решить всё на месте?

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

Braintrust от Pixar

То, о чём я писал выше, очень похоже на метод Braintrust.

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

Braintrust — это совещание, на котором все делятся своими взглядами. Его цель в том, чтобы узнать разные точки зрения и обогатить вашу

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

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

2. Трёх человек достаточно, чтобы создать продукт

Меньше команда — лучше продукт

В Basecamp используют отличный подход — работают над продуктом командой из трёх человек.

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

Этот подход можно использовать в компании любого масштаба, от стартапов до многомиллиардных корпораций. Его применяют не только ребята из Basecamp, но и сотрудники Nike — один из лучших продуктов Nike был создан тремя людьми. Сейчас я расскажу о нём.

HTM

HTM — это название экспериментального дизайн-проекта Nike, запущенного в 2002 году. Название состоит из первых букв имён его авторов: Хироши Фудзивары, Тинкера Хэтфилда и Марка Паркера (генеральный директор и дизайнер Nike).

В чём изюминка HTM?

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

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

Что если набрать команду из четырёх-пяти человек?

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

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

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

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

Говорят, чтобы нарисовать хорошую картину, нужно взять холст побольше. Творческие люди знают, что это не так. Слишком большая свобода может привести к посредственности, ведь без границ нет стимула прорваться сквозь них. Если дать творческому человеку ограниченные ресурсы, он легко внедрит инновации и создаст нечто великое.

3. «Ничего не делать» может быть правильным решением

Не обязательно заставлять всех обновляться. Пусть люди используют версию продукта, которая им больше нравится

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

Допустим, вы работаете над V2 (новой версией) вашего продукта и собираетесь её выпустить. Что делать с теми, кому удобно пользоваться V1 и кто не хочет обновлений? Большинство компаний не принимают это во внимание, они думают: «V2 лучше, разве они могут не хотеть перейти на неё?»

Когда Basecamp работали над редизайном своего приложения, они остановились в середине процесса и спросили себя: «Что если люди привыкли к текущей версии и не хотят переходить на новую?». В их случае переход с V1 на V2 означал перенос данных, конвертирование форматов и работу с абсолютно новым интерфейсом.

Basecamp решили не менять версию насильно. Обновление было необязательным, пользователь мог остаться с V1, если она нравилась больше. Так компания сэкономила ресурсы и порадовала клиентов.

Иногда приходится бороться с очевидным. Приходится признать, что “улучшить” не всегда равно “принести пользу”. Решить ничего не делать очень трудно, но это может быть лучшим вариантом

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

Когда они выпустили новую версию продукта, переход на неё был необязательным — переключиться на V2 можно было в любой удобный момент. Более того, можно было повышать и понижать версию, чтобы посмотреть, какая из них больше подходит. Дав человеку поиграться с программой, Freshbooks избавили его от стресса и сэкономили его время, в результате пользователь остался доволен.

Через две недели я перешёл на новую версию приложения. Прелесть в том, что это было моё решение, а не компании — у меня было время поиграть с V2, привыкнуть и убедиться, что она мне подходит.

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

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

Если вы хотите узнать правду о том, хорош ли продукт, его нужно выпустить на рынок. Можно тестировать, проводить мозговые штурмы, спорить, опрашивать людей, но только выход на рынок покажет, утонете вы или поплывёте

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

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

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

Определитесь с идеей. Создайте продукт в небольшой команде в короткие сроки. Выпустите его рынок и смотрите, как его приняли

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

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

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

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

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

Выводы

Не сводите себя с ума, работая над продуктом или функцией. Процесс будет легче и эффективнее, если следовать этим принципам:

  1. Продумайте идею;
  2. Работайте в команде из трёх человек;
  3. Помните, что иногда «ничего не делать» — лучший вариант;
  4. Исследования не дадут точных ответов. Выпустите продукт на рынок, посмотрите, как его приняли, и делайте выводы.

Подписывайтесь на «Дизайнерский дайджест». Это еженедельная рассылка главного редактора с лучшими ссылками для графических дизайнеров.