Модель двойного алмаза

Если дивергентное мышление — это поиск множества решений одной проблемы, то противоположным ему будет конвергентное мышление — отсекание всего лишнего, анализ вглубь.

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

Если рассматривать этот процесс в рамках разработки продукта, то получится примерно такая история:

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

Экскурсия в офис авито

На прошлой неделе ходили в гости к авито, в отдел исследования. Экскурсию проводил Миша Правдин.
Наиболее интересные моменты:

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

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

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

____________

Сейчас авито на взлёте, но взлет этот такой же, как и у нокиа в своё время, и их персональный «айфон» уже на подходе — в виде sharing economy. То есть модели, построенной не на владении, чем либо, а на временном пользовании. Уже сейчас модель совместного потребления можно увидеть на примере Airbnb, городского каршеринга и велопроката. И когда подобные сервисы закроют большинство потребностей — авито станет не нужен.

Советы по общению, речи и зачем быть похожим на крокодила, о которых вы не просили.

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

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

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

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

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

Продолжение позже…

Боязнь простых решений

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

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

"Мы предусмотрели в проекте 500 экранов! Если так, то такой экран и логика.
Если этак — такой экран и логика. Всё очень индивидуально."

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

Если вместо 500 экранов можно сделать 100 — надо делать 100. Пусть потеряется где-то индивидуальность, но решение не будет протухать.
У нас в Велвике такой принцип — если решение кажется сложным, то мы останавливаемся, отматываем назад и смотрим, где можно упростить.
Простое работающее решение придумать сложнее, чем нагородить кучу "если".

В общем, надо стремиться к упрощению.

Анна Данилова написала о тире. То, что мы обычно называем просто «тире», — это длинное тире.

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

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

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

Исторически длинное тире делалось размером с прописную М (поэтому оно называется Em dash). Некоторые иностранные типографы считают его слишком длинным и не используют в тексте. В современных шрифтах у тире бывают разные пропорции, а некоторые шрифтовики делают несколько типов длинного тире — «устаревшее» длинное, более современное покороче и т. д.

Короткое тире (En dash) в современном русскоязычном наборе чаще всего используется для обозначения числовых диапазонов, например 1990–1998. В текстах на английском короткое тире используется в любом диапазоне, даже если он набирается словами: October–November. Короткое тире в таких ситуациях не отбивается пробелами.

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

https://type.today/ru/journal/dash

Юрий Ветров #1 - об аутсорсе и развитии дизайн-системы.

Директор по дизайну в Mail.Ru Group (продукты под брендом “Mail.Ru”).
jvetrau.com

— Привет, Юр. Давай для начала поймем, за что отвечает дизайн-директор по продуктам в Mail.Ru?

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

У меня такие группы задач:
- Координация работы дизайнеров, помощь менеджерам в работе с ними.
- Найм и развитие команды.
- Задание направления для дизайна продуктов и его координация.
- Маркетинг нашей экспертизы для усиления бренда (публикации, конференции и т.п.).
- Работа руками, там где хватает времени.

В разных продуктах разная ситуация, поэтому эти обязанности комбинируются по-своему — где-то это всё и сразу, где-то, например, только помощь дизайнеру в развитии. В других подразделениях компании всё устроено по-своему; общий глава дизайна вряд ли возможен, учитывая разнообразие направлений и подходов (игры, социальные сети, e-commerce).

— В прошлом году вы искали аутсорс-дизайнера на продуктовые лендинги. В каком случае вы привлекаете внешних специалистов?

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

Но для части маркетинговых задач (промо-сайты, иллюстрации, баннеры и т.п.), либо там где у нас нет сильной экспертизы и мало практических задач для её развития (например, шрифтовой дизайн, видео-продакшен, брендинг) — иногда обращаемся к внешним студиям. Ещё один повод — если нужно сделать прорыв в продукте и важно посмотреть на проблему со стороны (бывает, что ограничения слишком давят на дизайнеров внутри), здесь иногда заказываем концепты сторонним дизайнерам или студиям (и сами думаем параллельно). Вот неплохо описан процесс работы над брендом My.com, который шёл по такой схеме — be.net/gallery/10980469/Mycom-Identity.

— Вы уже давно занимаетесь развитием своей дизайн-системы Paradigm. Что бы ты сделал по-другому, начиная работать над ней сейчас?

Да, мы начали работу над технологическим фреймворком для дизайн-системы ещё в 2012 году, а первые продукты на ней запустились в 2013. Тогда тема была сырой как идеологически, так и технологически, так что путь приходилось прокладывать по ходу и я уверен, что можно было бы сделать всё гораздо быстрее, имея огромное количество публикаций и примеров, которые есть сейчас.

Я бы начал с идеи токенов (файлов с переменными, которые легко описать и раздавать в любые технологические фреймворки — medium.com/eightshapes-llc/tokens-in-design-systems-25dd82d58421). Мы переводим Paradigm на эту архитектуру с прошлого года и это оказалось настоящей серебряной пулей — здорово сокращает расхождения, очень легко найти общий язык с фронтендом, для многих продуктов это очень дешёвый первый шаг перехода на Paradigm. Весной мы про это подробно расскажем.

— Как ты видишь её дальнейшее развитие?

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

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