Вчера мы начали обсуждать задачку — какую точку вы бы выбрали на шкале от «быстро и некачественно» до «долго и качественно». ☝️ Важный момент, который, похоже, я недостаточно явно сформулировал в постановке задачи и вариантах ответа — речь идёт именно про качество решения. Не про количество или полноту функционала, а про «степень прожарки».
Спасибо большое всем, кто проголосовал и прислал свои замечания и соображения.
Многие читатели отметили, что постановка задачи в таком виде слишком абстрактна, что не хватает контекста. Это правда. Для разных продуктов в разных ситуациях решения будут разными, одного правильного ответа тут не существует.
В Интеркоме мы в очередной раз столкнулись с такой развилкой совсем недавно. Пол Адамс рассказывал о ней в своём докладе на UX London (vimeo.com/275265188).
Меня удивило, что меньше всего голосов набрал вариант 3 — запуститься с максимальным качеством. Как дизайнер, в абстрактной усреднённой ситуации я бы топил именно за этот вариант. У остальных вариантов и так найдутся защитники в компании — продакт-менеджмент, руководство, продажи — всем, как правило, выгодно запуститься раньше. Done is better than perfect. Качество же кроме дизайнеров защищать-то некому. (Служба поддержки была бы рада, но у них обычно нет голоса при принятии продуктовых решений.)
С другой стороны, вот неочевидная штука. Мы, дизайнеры, конечно, можем выступать защитниками «счастья пользователей». Но если спросить самих пользователей, какой вариант они бы выбрали — часто они выберут вариант 1 — получить сырую фичу через месяц. Потому что любое существующее решение заведомо выигрывает у несуществующего. Если фича очень нужна, люди будут готовы потерпеть неудобства — лишь бы фича-таки появилась, и чем раньше, тем лучше.
Что же это получается, всем, кроме дизайнеров, выгоднее вариант 1? Ради чего тогда вообще весь этот перфекционизм? Дело в том, что у варианта 1 много рисков, которые не всегда и не все осознают. Кого-то из пользователей сырое решение оттолкнёт. Может быть, люди сначала обрадуются объявлению о том, что фича доступна, но потом попробуют и разочаруются. Мы можем их вообще потерять. Команде придётся доделывать решение, хотя у них будет большой соблазн начать заниматься следующими фичами. В общем, тут легко можно потерять больше, чем приобрести.
В реальной ситуации в Интеркоме мы в итоге пошли по варианту 2, который и в опросе набрал больше всего голосов. Среди предложенных крайностей он выглядит как разумный компромисс, учитывающий интересы разных сторон. Но возможен он только тогда, когда есть кому тянуть в сторону перфекционизма. От своих дизайнеров я ожидаю, что они будут заставлять всю команду совершенствовать и полировать продукт.
Спасибо большое всем, кто проголосовал и прислал свои замечания и соображения.
Многие читатели отметили, что постановка задачи в таком виде слишком абстрактна, что не хватает контекста. Это правда. Для разных продуктов в разных ситуациях решения будут разными, одного правильного ответа тут не существует.
В Интеркоме мы в очередной раз столкнулись с такой развилкой совсем недавно. Пол Адамс рассказывал о ней в своём докладе на UX London (vimeo.com/275265188).
Меня удивило, что меньше всего голосов набрал вариант 3 — запуститься с максимальным качеством. Как дизайнер, в абстрактной усреднённой ситуации я бы топил именно за этот вариант. У остальных вариантов и так найдутся защитники в компании — продакт-менеджмент, руководство, продажи — всем, как правило, выгодно запуститься раньше. Done is better than perfect. Качество же кроме дизайнеров защищать-то некому. (Служба поддержки была бы рада, но у них обычно нет голоса при принятии продуктовых решений.)
С другой стороны, вот неочевидная штука. Мы, дизайнеры, конечно, можем выступать защитниками «счастья пользователей». Но если спросить самих пользователей, какой вариант они бы выбрали — часто они выберут вариант 1 — получить сырую фичу через месяц. Потому что любое существующее решение заведомо выигрывает у несуществующего. Если фича очень нужна, люди будут готовы потерпеть неудобства — лишь бы фича-таки появилась, и чем раньше, тем лучше.
Что же это получается, всем, кроме дизайнеров, выгоднее вариант 1? Ради чего тогда вообще весь этот перфекционизм? Дело в том, что у варианта 1 много рисков, которые не всегда и не все осознают. Кого-то из пользователей сырое решение оттолкнёт. Может быть, люди сначала обрадуются объявлению о том, что фича доступна, но потом попробуют и разочаруются. Мы можем их вообще потерять. Команде придётся доделывать решение, хотя у них будет большой соблазн начать заниматься следующими фичами. В общем, тут легко можно потерять больше, чем приобрести.
В реальной ситуации в Интеркоме мы в итоге пошли по варианту 2, который и в опросе набрал больше всего голосов. Среди предложенных крайностей он выглядит как разумный компромисс, учитывающий интересы разных сторон. Но возможен он только тогда, когда есть кому тянуть в сторону перфекционизма. От своих дизайнеров я ожидаю, что они будут заставлять всю команду совершенствовать и полировать продукт.
Говорят, начался учебный год. Несколько лет назад в это самое время я оказался преподавателем курса по дизайну интерфейсов в МГУ. Тогда даже представить себе не мог, насколько полезным окажется этот опыт, хотя и непростым. Реально, если бы не преподавал, был бы сейчас совсем другим человеком.
Попал я туда почти случайно, меня позвал давний знакомый, который преподавал сам. И хотя времени и сил после фулл-тайм работы в Яндексе оставалось очень мало — не согласиться не мог.
Зачем мне это было надо? С одной стороны, чтобы поделиться тем немногим, чему успел сам научиться. Когда был студентом, меня очень вдохновляли молодые преподаватели-практики, которые рассказывали, как всё в жизни на самом деле происходит. Теперь хотелось отдать долг. С другой стороны, мне ужасно не нравилось примерно всё в устройстве традиционного высшего образования. Хотелось сделать курс здорового человека. Например, не понимаю как в XXI веке можно требовать от людей что-то запоминать и потом пересказывать на экзамене — у меня такого не было.
Чего не ожидал, так это того, что будучи преподавателем, сам научусь многому.
1. Если вам кажется, что вы понимаете какую-то тему, попробуйте о ней кому-то рассказать — вас могут ждать открытия. Мне пришлось разложить по полочкам всё, что знал про дизайн интерфейсов. Перечитать заново классические книжки (Норман, Купер, Раскин, вот это всё) и много нового там открыть. См. также пост про то, почему надо читать хорошие книги дважды: t.me/desprod/335. В общем, пока готовил материалы лекций, начал хоть понимать, чем занимаюсь на работе.
2. Преподавание — это лучшая практика публичных выступлений. Представьте, что вам надо раз в неделю, в любом настроении и самочувствии выйти и рассказать сотне человек интересную лекцию на часик-полтора. Окончательно перестал бояться выступать.
3. А ещё учишься быстро и убедительно отвечать на любые вопросы. Этот навык неплохо помогает на работе, особенно в общении с недизайнерами.
4. Заодно в моём случае курс оказался практикой быстрого удалённого арт-дирекшна. Студенты присылают работы в разной степени готовности, а вам надо после своего рабочего дня ещё вникнуть и дать полезную обратную связь по паре десятков проектов. Как это организовать, чтобы всё успеть и не стать бутылочным горлышком? Когда это встаёт на поток, быстро учишься.
5. А ещё общение со студентами помогает не терять связь с реальностью. Какие сейчас есть новые модные технологии или инструменты? Что интересно двадцатилетним, а что кажется странным? В каких вопросах моя позиция стала слишком консервативной? Студенты всё знают.
Преподавание подходит не всем. Но если вы чувствуете в себе силы и желание поделиться со студентами тем, что знаете и умеете, — обязательно попробуйте. Вам придётся отдать много сил и энергии, но взамен вы получите гораздо больше.
Попал я туда почти случайно, меня позвал давний знакомый, который преподавал сам. И хотя времени и сил после фулл-тайм работы в Яндексе оставалось очень мало — не согласиться не мог.
Зачем мне это было надо? С одной стороны, чтобы поделиться тем немногим, чему успел сам научиться. Когда был студентом, меня очень вдохновляли молодые преподаватели-практики, которые рассказывали, как всё в жизни на самом деле происходит. Теперь хотелось отдать долг. С другой стороны, мне ужасно не нравилось примерно всё в устройстве традиционного высшего образования. Хотелось сделать курс здорового человека. Например, не понимаю как в XXI веке можно требовать от людей что-то запоминать и потом пересказывать на экзамене — у меня такого не было.
Чего не ожидал, так это того, что будучи преподавателем, сам научусь многому.
1. Если вам кажется, что вы понимаете какую-то тему, попробуйте о ней кому-то рассказать — вас могут ждать открытия. Мне пришлось разложить по полочкам всё, что знал про дизайн интерфейсов. Перечитать заново классические книжки (Норман, Купер, Раскин, вот это всё) и много нового там открыть. См. также пост про то, почему надо читать хорошие книги дважды: t.me/desprod/335. В общем, пока готовил материалы лекций, начал хоть понимать, чем занимаюсь на работе.
2. Преподавание — это лучшая практика публичных выступлений. Представьте, что вам надо раз в неделю, в любом настроении и самочувствии выйти и рассказать сотне человек интересную лекцию на часик-полтора. Окончательно перестал бояться выступать.
3. А ещё учишься быстро и убедительно отвечать на любые вопросы. Этот навык неплохо помогает на работе, особенно в общении с недизайнерами.
4. Заодно в моём случае курс оказался практикой быстрого удалённого арт-дирекшна. Студенты присылают работы в разной степени готовности, а вам надо после своего рабочего дня ещё вникнуть и дать полезную обратную связь по паре десятков проектов. Как это организовать, чтобы всё успеть и не стать бутылочным горлышком? Когда это встаёт на поток, быстро учишься.
5. А ещё общение со студентами помогает не терять связь с реальностью. Какие сейчас есть новые модные технологии или инструменты? Что интересно двадцатилетним, а что кажется странным? В каких вопросах моя позиция стала слишком консервативной? Студенты всё знают.
Преподавание подходит не всем. Но если вы чувствуете в себе силы и желание поделиться со студентами тем, что знаете и умеете, — обязательно попробуйте. Вам придётся отдать много сил и энергии, но взамен вы получите гораздо больше.
В bang bang education вышел мой микро-курс про то, как руководить дизайнерами. Вот тут за минуту рассказываю о курсе: https://youtu.be/X_daDUPY67c
YouTube
Костя Горский о курсе «Как руководить дизайнерами»
Теоретический курс от Кости Горского, который пришел в Яндекс дизайнером, а ушел директором по дизайну. Сейчас преподаватель занимает должность Design Manager в компании Intercom (Дублин). Вы узнаете, что такое профессия руководителя и зачем люди берут на…
А сам курс здесь: 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. Вопросов у вас будет возникать ещё много. Хорошо бы найти ментора (может быть из вашей компании, а может даже и внешнего) — опытного руководителя, не обязательно понимающего в дизайне, который регулярно мог бы помогать советом.
Удачи! Всё получится.
* * *
Николай, поздравляю с новой позицией! В ближайшие месяцы будет интересно и нескучно.
Вот какие у меня мысли возникают:
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 экранов — то же самое.
Единственный совет, который могу дать, — радикально уменьшить задачу, сделать что-то очень маленькое и простое. Несколько экранов буквально. В любой привычной среде прототипирования. Протестировать, переделать, добиться того, чтобы у людей получалось с помощью интерфейса решать задачи. Передать разработчиками, показать, объяснить. Вместе с ними довести до работающего по-настоящему состояния. Запустить, отпраздновать. Увидеть, как это живёт в реальности и снова всё переделать.
А потом по чуть-чуть добавлять сложности.
Честно говоря, когда прочитал вопрос, у меня в голове была только одна мысль: зачем кому-то может быть нужно 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. Кстати, у Яндекс.Такси бренд ничуть не слабее, а то и посильнее будет. Им даже слова не нужно писать, чтобы обозначить себя, — достаточно покрасить машину, билборд или любой другой объект. Простой язык с бесконечными возможностями использования.
Настоящий ребрендинг — это не только внешние изменения. Не новые иконки и шрифты. Настоящий ребрендинг — это следствие изменений внутри, в ценностях и процессах компании. Убер сейчас переживает глубокий кризис. Компании пока так и не удалось оправиться от всех скандалов и отставки Трэвиса Каланика. Репутация Убера в Долине всё ещё ниже плинтуса. Так что им как никогда нужны изменения и свежая перспектива.
Не все знают, что Убер — компания не про заказ машины. Их амбиции всегда были намного бóльшими. Убер хочет переизобрести перевозку всего и всех. Людей в городе и между городами, еды, товаров, грузов. Убер — это логистическая компания в самом широком смысле, и именно поэтому она стоит баснословные 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 секунд, чтобы можно было отменить, если отправил случайно по ошибке.
В нашей индустрии концепты — тоже прекрасный способ продвинуть «основной» продукт вперёд, особенно если у продукта огромная аудитория и изменения ему даются с трудом.
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
Если вам кажется, что ваш продукт выглядит слишком консервативно, если изменения даются тяжело и хочется глотка свежего воздуха, значит, вам пора сделать концепт-кар.
Конечно, решаясь сделать концепт-кар, компания должна быть согласна потратить немало времени дизайнеров и разработчиков на нечто, что никогда не будет по-настоящему запущено. Зато если решиться, можно, во-первых, придумать и проверить много идей, которые никогда не найдут себе места в основном роудмапе. А во-вторых, здорово оживить и мотивировать команду. Концепты делать страшно интересно. А ещё классный концепт всегда украшает портфолио продуктового дизайнера (хорошо бы только, чтобы оно не состояло из одних лишь концептов). Процесс создания концепта при этом не радикально отличается от обычной продуктовой работы. Писал про это: t.me/desprod/28
Если вам кажется, что ваш продукт выглядит слишком консервативно, если изменения даются тяжело и хочется глотка свежего воздуха, значит, вам пора сделать концепт-кар.
В воскресенье впервые в жизни пробежал марафон (42 км 195 м).
Впечатлений много, поэтому вот отдельный подробный пост про то, как на это решился, как готовился и как всё прошло: https://medium.com/design-productivity/впервые-пробежал-марафон-как-это-было-f233e0791c7e
Впечатлений много, поэтому вот отдельный подробный пост про то, как на это решился, как готовился и как всё прошло: https://medium.com/design-productivity/впервые-пробежал-марафон-как-это-было-f233e0791c7e
Medium
Впервые пробежал марафон. Как это было
23 сентября 2018 впервые в жизни пробежал марафон (42 км 195 м).
И ещё новость. Вчера стартовал открытый конкурс Chatfuel для продакт-менеджеров и дизайнеров, в котором мне повезло быть в числе экспертов вместе с Дмитрием Думиком, Андреем Дороничевым, Ильёй Красинским и Анной Булдаковой.
- Участвовать могут команды в 1-3 человека;
- Надо придумать концепт онбординга для Chatfuel — конструктора ботов для Facebook Messenger;
- Призовой фонд — 1 000 000 рублей, будет поделен между тремя командами-победителями;
- Полная прозрачность — Chatfuel поделится цифрами конверсий продукта, наработками и контекстом;
- Заявки принимаются до 14 октября.
Подробности тут: t.me/dumik/8
- Участвовать могут команды в 1-3 человека;
- Надо придумать концепт онбординга для Chatfuel — конструктора ботов для Facebook Messenger;
- Призовой фонд — 1 000 000 рублей, будет поделен между тремя командами-победителями;
- Полная прозрачность — Chatfuel поделится цифрами конверсий продукта, наработками и контекстом;
- Заявки принимаются до 14 октября.
Подробности тут: t.me/dumik/8
Вопрос, который часто задают в той или иной форме: можно ли разработчикам принимать решения по дизайну без дизайнера?
Моё мнение тут однозначно — нет, нельзя. Всё, что увидят люди, должно проходить через дизайнера и должно быть дизайнером как минимум одобрено.
— А если дизайнер не прислал спецификации для какого-то состояния или ситуации?
Это нормально. Интерактивные продукты — сложная штука, дизайнер почти наверняка забудет описать какую-то ситуацию. Разработчик может предложить решение сам, но ему стоит поставить дизайнера в известность. Написать дизайнеру, например: «Для такой-то кнопки не было описано, каким должно быть состояние при наведённом курсоре. Сделал по аналогии с другими кнопками в продукте. Посмотри — нормально?»
— А если решение, которое предлагает дизайнер, слишком сложное в разработке?
Тогда надо дизайнеру об этом сказать и вместе придумать, как добиться нужного эффекта более простыми средствами. Может быть, дизайнер согласится на что-то попроще. А может объяснит, почему всё-таки должно быть именно так.
— А если разработчик знает, как сделать продукт лучше?
Прекрасно! Тем более стоит обсудить это с дизайнером. У нас у всех одна цель — сделать классный продукт. Часто самые лучшие решения приходят от разработчиков. Давайте их обсуждать, давайте вместе решим, что будем делать.
— А если дизайнер один, а вопросов сотни?
Возможно, у вас в компании не хватает дизайнеров. Нормальным соотношением в современных продуктовых компаниях считается 1 дизайнер на 4-5 разработчиков. При таком соотношении дизайнер обычно успевает отвечать на все вопросы.
— А если разработчик сам в прошлом был дизайнером?
Здорово, когда компетенции людей пересекаются — это позволяет говорить на одном языке. Но нужно уважать роли и зоны ответственности друг друга. За дизайн отвечает дизайнер, поэтому он должен быть в курсе всех изменений. Точно так же оценивать трудоёмкость какого бы то ни было решения имеет право только разработчик. Дизайнеру запрещено говорить, что «это можно сделать за день», даже если дизайнер был в прошлом разработчиком.
— А если дизайнер не отвечает, ну не останавливать же из-за этого производство?
Дизайнер не обязан отвечать мгновенно, ему нужно иметь возможность работать без отвлечений. Если скорость ответа дизайнера ставит под угрозу производство, значит у нас глобально что-то идёт не так. Всегда можно договориться о каком-то способе общения, который всем подойдёт. Дизайнер может выделить время, когда он гарантированно будет доступен и будет быстро отвечать. Или, если сейчас такой этап проекта, когда внимание дизайнера нужно постоянно, — пусть поставит все остальные дела на паузу и сядет вместе с разработчиком за один компьютер на целый день.
— А если в компании вообще нет дизайнеров?
ААААААА!!!
Моё мнение тут однозначно — нет, нельзя. Всё, что увидят люди, должно проходить через дизайнера и должно быть дизайнером как минимум одобрено.
— А если дизайнер не прислал спецификации для какого-то состояния или ситуации?
Это нормально. Интерактивные продукты — сложная штука, дизайнер почти наверняка забудет описать какую-то ситуацию. Разработчик может предложить решение сам, но ему стоит поставить дизайнера в известность. Написать дизайнеру, например: «Для такой-то кнопки не было описано, каким должно быть состояние при наведённом курсоре. Сделал по аналогии с другими кнопками в продукте. Посмотри — нормально?»
— А если решение, которое предлагает дизайнер, слишком сложное в разработке?
Тогда надо дизайнеру об этом сказать и вместе придумать, как добиться нужного эффекта более простыми средствами. Может быть, дизайнер согласится на что-то попроще. А может объяснит, почему всё-таки должно быть именно так.
— А если разработчик знает, как сделать продукт лучше?
Прекрасно! Тем более стоит обсудить это с дизайнером. У нас у всех одна цель — сделать классный продукт. Часто самые лучшие решения приходят от разработчиков. Давайте их обсуждать, давайте вместе решим, что будем делать.
— А если дизайнер один, а вопросов сотни?
Возможно, у вас в компании не хватает дизайнеров. Нормальным соотношением в современных продуктовых компаниях считается 1 дизайнер на 4-5 разработчиков. При таком соотношении дизайнер обычно успевает отвечать на все вопросы.
— А если разработчик сам в прошлом был дизайнером?
Здорово, когда компетенции людей пересекаются — это позволяет говорить на одном языке. Но нужно уважать роли и зоны ответственности друг друга. За дизайн отвечает дизайнер, поэтому он должен быть в курсе всех изменений. Точно так же оценивать трудоёмкость какого бы то ни было решения имеет право только разработчик. Дизайнеру запрещено говорить, что «это можно сделать за день», даже если дизайнер был в прошлом разработчиком.
— А если дизайнер не отвечает, ну не останавливать же из-за этого производство?
Дизайнер не обязан отвечать мгновенно, ему нужно иметь возможность работать без отвлечений. Если скорость ответа дизайнера ставит под угрозу производство, значит у нас глобально что-то идёт не так. Всегда можно договориться о каком-то способе общения, который всем подойдёт. Дизайнер может выделить время, когда он гарантированно будет доступен и будет быстро отвечать. Или, если сейчас такой этап проекта, когда внимание дизайнера нужно постоянно, — пусть поставит все остальные дела на паузу и сядет вместе с разработчиком за один компьютер на целый день.
— А если в компании вообще нет дизайнеров?
ААААААА!!!