В bang bang education вышел мой микро-курс про то, как руководить дизайнерами. Вот тут за минуту рассказываю о курсе: https://youtu.be/X_daDUPY67c

А сам курс здесь: https://bangbangeducation.ru/course/how-to-manage-designers

Вот и пост сегодня на похожую тему будет.

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

* * *

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

Вот какие у меня мысли возникают:

0. Самое главное — проговорить ожидания со своим будущим руководством. Чего от вас ждут в ближайший год? Какие перед вами задачи стоят и какие у вас есть ресурсы и полномочия для их выполнения? Зачем бизнесу вообще понадобилось выстраивать отдел дизайна? Надо убедиться, что вы с вашим начальством понимаете это всё абсолютно одинаково. И зафиксировать договорённости в виде целей на ближайший год и квартал.
1. Работу в новой должности я бы начинал с того, что постарался изучить, как устроены процессы в компании сейчас. Первый месяц, а то и пару месяцев, не бросался бы ничего менять, а скорее наблюдал.
2. Ещё одна важная задача на первое время — выстроить отношения с разработчиками и завоевать у них уважение и доверие. По-хорошему надо стать участником их команды — ходить на ключевые встречи, знать, о чём они сейчас беспокоятся и какие нерешенные проблемы стоят, помогать в меру возможностей.
3. Насчёт того, что почитать. Вот лучшие известные мне книжки про руководство людьми:
- "Managing Humans" by Michael Lopp — https://www.amazon.com/Managing-Humans-Humorous-Software-Engineering/dp/1484221575/
- "Radical Candor" by Kim Scott — https://www.amazon.com/Radical-Candor-Kick-Ass-Without-Humanity/dp/1250103509
- «Оргуправленческое мышление» Щедровицого — https://store.artlebedev.ru/books/orgupravlencheskoe-myshlenie-2014/
- А вот ещё восхитительная заметка Саши Ложечкина про ошибки начинающих руководителей — горячо рекомендую: https://clck.ru/EHhtN
4. В долгосрочной перспективе самое главное — собрать сильную команду. Можно ошибаться и наломать дров в чём угодно, но не в найме людей — ошибки найма исправлять тяжелее всего. А со слабой командой далеко не уедешь. Поэтому с этим я бы точно не спешил, поставил высокую планку и искал самых сильных и классных людей, до которых только получается дотянуться. Гораздо лучше нанять одного сильного дизайнера через 3 месяца, например, чем за месяц набрать 5 посредственных.
5. Вопросов у вас будет возникать ещё много. Хорошо бы найти ментора (может быть из вашей компании, а может даже и внешнего) — опытного руководителя, не обязательно понимающего в дизайне, который регулярно мог бы помогать советом.

Удачи! Всё получится.

Пишет читатель Алекс: «Сейчас мы делаем сложную админку более чем из 400 разных экранов, всплывающих окон и т. д. Invision уже не справляется и очень сильно глючит, и долго грузится. Там прототипы не получается делать. Есть ли более подходящий сервис для прототипирования?»

Честно говоря, когда прочитал вопрос, у меня в голове была только одна мысль: зачем кому-то может быть нужно 400 экранов в прототипе? Это же овердофига. Тут если среда прототипирования не начнёт глючить, то дизайнер начнёт непременно.

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

Сложная работающая система создаётся только путём эволюции из простой работающей системы. Сложная система, разработанная с нуля, никогда не работает, и её даже невозможно довести до работающего состояния. Это не я придумал, это закон Галла (https://en.wikipedia.org/wiki/John_Gall_(author))

Любой разработчик вам подтвердит, что если написать сразу 400 строк кода, то не получится потом это дело отладить и добиться работоспособности. С разработкой дизайна сложной админки на 400 экранов — то же самое.

Единственный совет, который могу дать, — радикально уменьшить задачу, сделать что-то очень маленькое и простое. Несколько экранов буквально. В любой привычной среде прототипирования. Протестировать, переделать, добиться того, чтобы у людей получалось с помощью интерфейса решать задачи. Передать разработчиками, показать, объяснить. Вместе с ними довести до работающего по-настоящему состояния. Запустить, отпраздновать. Увидеть, как это живёт в реальности и снова всё переделать.

А потом по чуть-чуть добавлять сложности.

Пока кто-то из нас вчера следил за презентацией Эппла, на которой, по-моему, не было ничего особенно интересного (ну разве что часы научились снимать ЭКГ), Убер показал свой новый брендинг. Вот где красота.

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

Не все знают, что Убер — компания не про заказ машины. Их амбиции всегда были намного бóльшими. Убер хочет переизобрести перевозку всего и всех. Людей в городе и между городами, еды, товаров, грузов. Убер — это логистическая компания в самом широком смысле, и именно поэтому она стоит баснословные 72 миллиарда (семь Яндексов!).

Новый бренд сделан внутренней бренд-студией вместе с Wolff Olins. Своя бренд-струдия — это тренд. Так же как дизайн продуктов в продуктовых компаниях сейчас всегда делается внутри. Такие вещи просто невозможно делать силами подрядчиков. Это неотъемлемая часть бизнеса, которая живёт и развивается вместе с ним.

Внешне новый Убер сделали очень трендовым. Белый фон, крупный круглый кастомный чёрный шрифт, синие акценты, простые иллюстрации и фотки. Где-то мы всё это уже видели. Примерно у всех стартапов, которые хотят своим внешним видом сказать, что они модные и технологичные. Писал про это заметку год назад: t.me/desprod/82. Любопытно, что за год изменилось не так уж и много. Стало меньше иллюстраций и больше фотографий, да ярко-тёмно-синий окончательно всех победил в качестве Главного Цвета.

Много классных находок в графике. Широкие белые поля у билбордов и плакатов как будто образуют букву U. Знака нет вообще — вместо него текстовый логотип. Главное применение знаков у технологических компаний сейчас — иконка приложения. Убер предлагает чёрную иконку с белым текстом. А ещё мне очень нравится как в рекламной коммуникации используют простую стрелочку вправо. Привет гениальному бренду FedEx.

Классно видеть контент-дизайн — tone of voice — неотъемлемой частью бренда. То, какими именно словами и с какой интонацией компания общается с нами, определяет ощущения в неменьшей степени, чем графика. Но как часто при этом в портфолио дизайн-студий в рассказах про брендинг мы видим гайдлайны по стилю письма? Не могу тут не сказать, что мне очень нравится язык Яндекс.Драйва, один из самых ярких примеров сильной работы с текстом на русском языке.

Новый бренд сам по себе, конечно, не спасёт Убер. Но приятно видеть, что у компании ещё есть порох. Все подробности про новый бренд Убера тут: https://www.uber.design/case-studies/rebrand-2018

P. S. Кстати, у Яндекс.Такси бренд ничуть не слабее, а то и посильнее будет. Им даже слова не нужно писать, чтобы обозначить себя, — достаточно покрасить машину, билборд или любой другой объект. Простой язык с бесконечными возможностями использования.

На прошлой неделе Гугл объявил о том, что через полгода прекратит поддержку Inbox, своего инновационного почтового клиента, запущенного в октябре 2014 года. Останется только Gmail. Немало моих знакомых, которые пользовались Инбоксом как основным интерфейсом почты, огорчились. А мне это всё напомнило, что не рассказывал вам ещё про концепт-кары. Конечно, Инбокс был больше, чем просто концептом, но сработал в итоге похожим образом.

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

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

Google Inbox был ровно таким примером. Многие идеи, которые в нём впервые появились, сейчас уже перенесли в Gmail — основной серийный продукт. Например, вложения, которые видны сразу в списке писем. Или кнопки с быстрыми ответами, как в мессенджерах. Или «отмена» отправки письма, когда отправку задерживают на 10 секунд, чтобы можно было отменить, если отправил случайно по ошибке.

В 2014-м мы делали Альфа-версию Яндекс.Браузера (https://www.youtube.com/watch?v=gon9AfLqa78) как концепт-кар, который никогда не собирался становиться по-настоящему массовым браузером, но позволил обкатать идеи, часть из которых со временем перенесли в основной продукт.

Ещё один мой любимый пример — Facebook Paper (https://www.youtube.com/watch?v=Ne2uHFi_e_M). Помните такой? Запущен всё в том же 2014 году (богатый год на концепты выдался), прекращён в 2016. Сейчас в дизайне основного продукта Фейсбука можно увидеть следы Paper, например карточки-посты. А новое видео-стриминговое приложение IGTV так вообще очень похоже.

Конечно, решаясь сделать концепт-кар, компания должна быть согласна потратить немало времени дизайнеров и разработчиков на нечто, что никогда не будет по-настоящему запущено. Зато если решиться, можно, во-первых, придумать и проверить много идей, которые никогда не найдут себе места в основном роудмапе. А во-вторых, здорово оживить и мотивировать команду. Концепты делать страшно интересно. А ещё классный концепт всегда украшает портфолио продуктового дизайнера (хорошо бы только, чтобы оно не состояло из одних лишь концептов). Процесс создания концепта при этом не радикально отличается от обычной продуктовой работы. Писал про это: t.me/desprod/28

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

В воскресенье впервые в жизни пробежал марафон (42 км 195 м).

Впечатлений много, поэтому вот отдельный подробный пост про то, как на это решился, как готовился и как всё прошло: https://medium.com/design-productivity/впервые-пробежал-марафон-как-это-было-f233e0791c7e

И ещё новость. Вчера стартовал открытый конкурс Chatfuel для продакт-менеджеров и дизайнеров, в котором мне повезло быть в числе экспертов вместе с Дмитрием Думиком, Андреем Дороничевым, Ильёй Красинским и Анной Булдаковой.

- Участвовать могут команды в 1-3 человека;
- Надо придумать концепт онбординга для Chatfuel — конструктора ботов для Facebook Messenger;
- Призовой фонд — 1 000 000 рублей, будет поделен между тремя командами-победителями;
- Полная прозрачность — Chatfuel поделится цифрами конверсий продукта, наработками и контекстом;
- Заявки принимаются до 14 октября.

Подробности тут: t.me/dumik/8

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

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

— А если дизайнер не прислал спецификации для какого-то состояния или ситуации?
Это нормально. Интерактивные продукты — сложная штука, дизайнер почти наверняка забудет описать какую-то ситуацию. Разработчик может предложить решение сам, но ему стоит поставить дизайнера в известность. Написать дизайнеру, например: «Для такой-то кнопки не было описано, каким должно быть состояние при наведённом курсоре. Сделал по аналогии с другими кнопками в продукте. Посмотри — нормально?»

— А если решение, которое предлагает дизайнер, слишком сложное в разработке?
Тогда надо дизайнеру об этом сказать и вместе придумать, как добиться нужного эффекта более простыми средствами. Может быть, дизайнер согласится на что-то попроще. А может объяснит, почему всё-таки должно быть именно так.

— А если разработчик знает, как сделать продукт лучше?
Прекрасно! Тем более стоит обсудить это с дизайнером. У нас у всех одна цель — сделать классный продукт. Часто самые лучшие решения приходят от разработчиков. Давайте их обсуждать, давайте вместе решим, что будем делать.

— А если дизайнер один, а вопросов сотни?
Возможно, у вас в компании не хватает дизайнеров. Нормальным соотношением в современных продуктовых компаниях считается 1 дизайнер на 4-5 разработчиков. При таком соотношении дизайнер обычно успевает отвечать на все вопросы.

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

— А если дизайнер не отвечает, ну не останавливать же из-за этого производство?
Дизайнер не обязан отвечать мгновенно, ему нужно иметь возможность работать без отвлечений. Если скорость ответа дизайнера ставит под угрозу производство, значит у нас глобально что-то идёт не так. Всегда можно договориться о каком-то способе общения, который всем подойдёт. Дизайнер может выделить время, когда он гарантированно будет доступен и будет быстро отвечать. Или, если сейчас такой этап проекта, когда внимание дизайнера нужно постоянно, — пусть поставит все остальные дела на паузу и сядет вместе с разработчиком за один компьютер на целый день.

— А если в компании вообще нет дизайнеров?
ААААААА!!!

Сегодня вместо обычного поста вопрос и пара вещей вокруг, которые меня сейчас интересуют.