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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. На прошлой неделе Mailchimp показал свой новый брендинг. Интересен он тем, что в отличие от Убера, который мы недавно обсуждали (t.iss.one/desprod/363), Mailchimp выглядит максимально далёким от трендов последних лет. Все делают белый фон, круглые гротески и простые чистые иллюстрации с плоскими цветами? Отлично, мы тогда сделаем жёлтый фон, возьмём антикву и нафигачим грязных безумных чёрно-белых иллюстраций, как бы говорит Mailchimp. Такой протест и вызов — это, безусловно, круто. Технологическим компаниям надоело быть одинаковыми, маятник качнулся в другую сторону?

2. Пока был в Москве не удержался и покатался на Яндекс.Драйве — там появились машины бизнес-класса и Порше. Даже если вы не водитель, очень рекомендую поставить Драйв, чтобы просто даже посмотреть приложение — есть чему поучиться.

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

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

3. И вопрос: как лидерам удаётся проводить большие изменения?

Есть много примеров того, как человеку удавалось изменить компанию или даже страну:
- Ли Куан Ю превратил Сингапур из никому не нужной бывшей колонии без территории, без ресурсов и с кучей противоречий в преуспевающую экономику и практически страну будущего;
- Сатья Наделла превратил Microsoft из приунывшей корпорации, которую, казалось, никто уже не воспринимал всерьёз, в живую преуспевающую компанию (и продолжает это делать);
- Герман Греф превратил Сбербанк из динозавра в бодрый банк, который вполне конкурирует со стартапами (и продолжает развивать компанию).

Даже маленькие изменения — это сложно. Как они это делают на таком масштабе? Страшно интересно. Кто знает, что на эту тему почитать или кого послушать?

Заметил, что есть одна книжка, которую в последний год рекомендовал чаще всех прочих — Sprint (https://www.amazon.com/Sprint-Solve-Problems-Test-Ideas/dp/1442397683). Это книжка дизайнеров из Google Ventures про то, как за 5 дней сделать квантовый скачок в понимании того, какой продукт делать.

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

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

Так вот. На днях вышла новая книжка авторов Спринта — Jake Knapp и John Zeratsky. Она называется Make time и полностью посвящена продуктивности (https://maketimebook.com).

Конечно, не смог удержаться, сразу купил её и залпом прочитал. Услышал о ней в нашем подкасте Inside Intercom — там Стюарт Скотт-Курран, руководитель нашей бренд-студии, беседует с Джейком: https://www.intercom.com/blog/podcasts/jake-knapp-on-making-time-for-your-most-important-work/.

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

На первом этапе предлагается выбрать Highlight — цель на день: что-то самое главное, что в течение дня хочется сделать. Потом максимально сфокусироваться, убрать все отвлечения, и, собственно, сделать. Попутно рассказывается о том, как поддерживать себя энергичным (сон-еда-кофе-физкультура). Наконец, в конце дня можно подвести итог и порадоваться тому, чего удалось достичь.

Точно так же как и в Sprint, в Make time нет ничего уж такого нового и удивительного. Нет какой-то особенной глубины, нет тонн ссылок на научные исследования. Но они написаны практиками, которые сами делают то, про что пишут. И написаны очень простым и ясным языком. Мне такое по душе.

* * *

P. S. Конкурс Chatfuel, в котором вхожу в состав жюри и про который писал раньше, в самом разгаре. Приём заявок заканчивается в следующее воскресенье — 14 октября. За эти или следующие выходные как раз можно набросать и предложить ваш вариант онбординга для конструктора ботов: t.iss.one/dumik/11

P. P. S. А ещё напоминаю, что полный архив этого канала с оглавлением по рубрикам есть на Медиуме: https://medium.com/design-productivity. Как раз добавил туда посты за последние несколько месяцев.

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

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

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

К дизайну продуктов это тоже относится.

Когда мы работали над Яндекс.Браузером, изучали историю веба и браузеров. Оказалось, что многие старые браузеры даже можно скачать и поставить себе на компьютер, и они будут работать! Мы внимательно разобрали тогда ключевые этапы и поворотные точки индустрии:
- Например, первый массовый браузер появился в 1993 году и назывался Mosaic. Удивительно, что общее устройство его интерфейса сразу попало в точку. Современные браузеры не то чтобы радикально отличаются.
- В 2000 в Opera впервые появляются вкладки! И поисковая строка Google, отдельно от адресной строки. Вкладки находятся внизу, но сразу делают браузер в 100 раз удобнее, и это изменение вскоре все подхватывают.
- В 2008 появляется Google Chrome, в котором адресная строка объединяется со строкой поиска — гениальное решение.
И так далее. Это было с одной стороны просто интересное исследование, а с другой, помогло понять, как всё пришло к тому, что мы имеем сегодня. И прикинуть, куда пойдёт дальше.

На этой неделе у нас в Интеркоме будет большой запуск — новая глава в истории компании: https://www.intercom.com/the-next-chapter. Этот лендинг — рассказ об истории того, как бизнес общался с людьми в разное время. Как новые технологии (телефон, е-мейл, сайты, мессенджеры) открывали новые возможности. Как компании во все эти технологические эпохи старались делать общение более личным и человечным и что из этого получалось.

Например, вот история самого эффективного е-мейла в истории маркетинга. В 1978 Гэри Туэрк из корпорации DEC отправил электронное письмо 400 потенциальным клиентам. Его письмо в итоге привело к заключению контрактов на 13 миллионов долларов и показало потенциал использования е-мейла в маркетинге. Компании тут же подхватили такой подход, а Гэри стал известен как «отец спама».

А вы насколько хорошо знаете историю того, над чем работаете?

Поговорили с Димой, CEO Chatfuel, о продуктовом дизайне, об отношениях между дизайнером и продакт-менеджером, о конфликтах, осознанности и о ведении телеграм-канала. И попробовали в прямом эфире придумать интерьер самоуправляемой машины 🙈

https://www.youtube.com/watch?v=kZz8dJwmH48

P.S. До дедлайна в конкурсе Chatfuel осталось 3 дня: t.iss.one/dumik/11 Ну то есть как раз ещё можно все успеть!

Этой осенью продуктовая команда Интеркома полностью перешла со Скетча на Фигму. Если кто-то пропустил, figma.com — это графический редактор, работающий в браузере, как Google Docs.

Кое-что про Фигму уже писал раньше. Например, почему верю, что в прекрасном светлом будущем скорее будет Фигма, чем Скетч: t.iss.one/desprod/296.

Что нам этот переход дал:
1. Самое главное — теперь у всех всегда есть доступ к последней версии дизайна. Продакт-менеджеры, разработчики, контент-стратеги, исследователи, маркетологи, другие дизайнеры — все просто открывают ссылку на макет, и видят там самую распоследнюю версию. И оставляют комментарии и вопросы. Или могут смотреть, как дизайнер работает и что-то ещё меняет. А дизайнеру теперь не надо после каждого микро-изменения заново выкладывать скриншоты, не надо нигде обновлять картинки. Это фантастически круто.
2. Стало легко найти исходники всего. Несмотря на то, что мы и раньше требовали от дизайнеров, чтобы все исходники были в корпоративном Google Drive — находить там зачастую ничего не получалось, приходилось писать дизайнеру и просить прислать макет или показать, где он лежит. Теперь в Фигме видны файлы всех, и я могу найти любой исходник любого дизайнера за секунды.
3. Дизайн-система обновляется у всех сразу. Дизайн-системой у нас фулл-тайм занимается выделенная команда. Как только ребята обновляют какой-нибудь системный компонент — всем автоматически приходит апдейт. Теперь можно в один клик обновить стиль кнопки во всех макетах всех дизайнеров компании. Ну ок, не совсем в один — им надо будет подтвердить обновление сначала.
4. Вместе со Скетчем нам почти что перестали быть нужны Zeplin и InVision. Разработчики сразу видят все спецификации в Фигме и забирают оттуда иконки. Прототипы тоже проще делать сразу в Фигме.
5. Фигма бесконечно хранит историю всех изменений. Не нужно иметь много копий одного и того же файла, всегда можно вернуться к любой старой версии.
6. Боялись, что работать без интернета станет невозможно. В самолёте, например. Отчасти это так, но с другой стороны, если скачать десктопное приложение и открыть в нём файл-исходник, то всё вполне работает и оффлайн. А когда интернет появляется, изменения просто синхронизируются. Главное не забыть подготовиться — собственно, открыть файл заранее.

Как переходили:
1. Начали с того, что пара дизайнеров-энтузиастов переключилась на Фигму на 2 недели. Переезд туда, кстати, занимает примерно минуту, потому что файлы Скетча можно просто импортировать и продолжать работать, как ни в чём не бывало. Заодно импортировали и дизайн-систему, там правда уже пришлось немного потрудиться.
2. Энтузиастам в итоге всё очень понравилось, и мы объявили пилотный проект на месяц, в течение которого Фигму предлагалось попробовать каждому дизайнеру. В конце месяца попросили всех заполнить небольшой опрос, общее впечатление оказалось очень положительным. Заодно собрали все сомнения, претензии и проблемы. Обсудили и договорились, что со всем этим делать.
3. Решили, что будем переходить. Команда дизайн-системы занялась полноценным портированием библиотеки компонентов. Собственно, «переход» означал ровно это — библиотеку в Скетче мы перестаём поддерживать.
4. Здорово, что в процессе мы были на связи с ребятами из самой Фигмы, они очень оперативно отвечали и помогали со всеми нашими вопросами. Однажды мы нашли неприятный баг с авторизацией, который мешал работать — нам в тот же день прислали способ проблему обойти, а через два дня в новой версии полностью исправили.

Вот так, теперь используем Фигму и нарадоваться не можем. А мне по этому всему поводу вот что интересно: всё уходит в браузер. Нативных приложений, которые мне были бы нужны на компьютере, уже почти что и не осталось. По инерции использую iA Writer только (божественно красивый, все тексты, заметки и размышления пишу только там), да Keynote. Ну и Слак, но он в браузере ничем не отличается.