Главная » Хабрахабр » Дизайн цифровых продуктов. Цель, роль, метод

Дизайн цифровых продуктов. Цель, роль, метод

Мне довелось создать с нуля подразделение дизайна в Альфа-Банке и поработать дизайн-директором. На это ушло пять лет. В результате у нас получилась дизайн-система (в коде) и подход к диайну цифровых продуктов. Собственно, про этот подход я и расскажу здесь. Точнее, это — текст лекции, которую я читал в начале 2018 года в Москве, Перми, Новосибирске и Петербурге. В мае я принял решение покинуть банк, теперь дошли руки опубликовать текст лекции.

В Альфа-Лаборатории мы строили процессы продуктовой разработки как раз по скраму, где каждая команда является самостоятельной единицей, способной делать поставки так быстро, как смогут (в идеале — недельными или двухнедельными спринтами).

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

Даже на таком относительно большом масштабе важнее работать на уровне стратегии, верхнеуровневых понятий и подходов, потому то «контролировать» работу 30 дизайнеров, которые работают над разными продуктами и в разных командах и с разной скоростью технически качественно не получится. В конце 2017 года в Лаборатории было около 30 команд (может больше), и почти для каждой нужен был свой дизайнер. Тактику определяет каждая команда самостоятельно, в этом вся прелесть.

Разберем каждое слово, ведь она не просто так сформулирована именно этими словами. Такая простая цель.

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

Из десяти дизайнеров, приходящих «делать продукт и влиять на него» на результате фокусируется один, остальные — на процессах. У меня есть грустная статистика. Доходит долго, и хорошо, если доходит вообще.

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

Занудное пояснение на тему процессов и негодования

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

Взять то же прототипирование1: вместо разработки, мы создаем эмуляторы, которые дают от силы 10-30% опыта, который будет в продукте. Любая профессиональная надстройка для «ускорения» или «совершенствования» процессов часто просто (уже будучи надстройкой, то есть фактически избыточным явлением) добавляет процессов и бюрократии, не решая задачи и не двигая команду к цели, а отдаляя от неё. И исследования. И проектирование. И вайрфреймы ДО макетов (некоторые отличают эту стадию от проектирования и вкладывают в одни и те же термины разные смыслы). И макеты. И ещё «авторский надзор» (очень пошлое название подглядывания за работой разработчиков и ворчание — тут-то вскрывается миллиард неучтенных во всех этих «исследованиях» и «прототипах» нюансов). Потом описание гайдов. Вырастают отдельные профессии типа «проектировщик», «дизайнер интерфейсов», «UX/UI-дизайнер», «исследователь» и так далее. Так, вместо того чтобы стремиться к результату в виде продукта, дизайнеры или менеджеры создают массу высокозатратной возни. Вместо фокуса на работающем продукте получается фокус на процессах, и каждая надстройка только отдаляет от реальной цели. На конференциях вполне всерьёз начинают обсуждать легитимность склеивания UX и UI, мол этим должны разные люди заниматься, разные инструменты и задачи.

Об устоявшихся процессах внутри давно существующей компании, которые называются «бизнес-процессами», и которые часто наиболее сильно влияют на продукт и опыт пользователя, здесь речи не идёт. Надо понимать, что здесь речь идёт только о процессах, наиболее тесно связанных с работой людей, которых мы называем дизайнерами (что бы кто в это собирательное понятие ни вкладывал).

Anyway, вернемся к формулировке.

  1. Работающий продукт — тот, которым можно пользоваться, решать задачи. Речь о технической возможности решить задачу используя продукт.
  2. Продукт — некая законченная сущность, цельная, в сумме ингредиентов обладающая бОльшей ценностью, чем все они взятые по отдельности.
  3. Пользуются — говорит о востребованности и удобстве.
  4. Люди — более широкое понятие, чем «клиенты», «пользователи», «сотрудники» и т.д. Работая для людей, мы учитываем эргономику и какие-никакие но стандарты.

Тут всё понятно: пользоваться им (как минимум по назначению) не будут. Допустим, продукт не работает.

Или это не продукт: набор разрозненных компонент, не связанных между собой ни по какому признаку (такое тоже бывает).

Тоже провал, может быть чей угодно: отсутствие маркетинга, неудобный, тормозит. Или продукт есть, но им не пользуются (совсем).

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

Допускаю такие причины: Эту мысль с разных сторон обсуждают и когда говорят про Agile, и про частые поставки, и про Скрам и про работу в командах, но даже при таких практиках дизайнеры почему-то порой скатываются в уютную колею «процессов».

  • не понимают технологий и своего влияния на них,
  • не могут повлиять на результат (страх «не послушают», отсутствие мотивации, выдуманная субординация «мне так не говорили делать»)
  • не понимают своей роли
  • скрам эксплуатируется без понимания цели, как фреймворк (см. также «Культ Карго») — тогда он точно не лучше ватерфолла (а то и хуже)
  • устраивают небольшие ватерфоллы внутри скрама 🙂 — «Сначала дизайн, потом фронт-энд», вместо того чтобы работать как минимум вдвоём/парой. Это, почему-то, особенно трудно заходит как дизайнерам, так и разработчикам (но когда и если доходит, то к мини-ватерфольной модели они уже больше не хотят возвращаться, потому что она во всех смыслах ущербна).

S. P. Ссылки на описания перечисленных методологий, Википедия:

Часто роль дизайнера в продуктовой команде преувеличивают, потому что мыслят категориями процессов и последовательности действий (ватерфолл) вместо результата.

(Правильно мыслить от результата, категориями цели.)

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

«Мы ждём макеты» — если такое звучит, значит процессы в команде организованы неправильно.

По аналогии существуют описания/стандарты для ведущих мобильных и настольных платформ; iOS, Material.) (Увы, многие разработчики и дизайнеры не знают о стандартах — хотя бы W3C для веба, а там заложено очень много фундаментальных принципов, которые помогают строить лучший опыт.

Они создавали продукты в соотвествии с Целью. Обратите внимание на стартапы — Facebook, Вконтакте, Одноклассники и те же Apple с Microsoft: в их основе лежат инженерные решения (Возняк, Гейтс), к которым впоследствии присоединились дизайнеры.

Сначала — работающий продукт.

(Красивый, справледивости ради, сделали идейные ребята в лаборатории Xerox, но масштаб последствий совсем иной.)

•••

В чем же тогда роль дизайнера?

В том, чтобы добавить ценность.

Добавить можно к чему-то существующему, обратите внимание.

Ценность в глазах клиентов, пользователей.

•••

Это, конечно, говорит о незрелости команды и неадекватном менеджменте этой самой команды. Зачастую последовательность переворачивают с ног на голову и «ждут дизайн».

•••

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

Начинайте с кода вместо макетов.

Поэтому макеты в работе продуктового дизайнера чаще неуместны и противоречат цели. Приложение — динамика, движение, взаимодействие.

Хорошо ли это? Именно поэтому продвинутые дизайнеры мигрируют в прототипы с реальными данными. Считаю, это избыточно — зачем программировать прототип, когда можно (и логично) сразу программировать продукт?

Начинать именно с кода — прототипа, выполняющего задачу клиента в минимальном виде. Лучше сразу двигаться от разработки к дизайну. Прототипа, который может пойти в рабочую поставку (вспомним позже про Customer Development).

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

Лирическое отступление: пример из физического мира

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

Важно его правильно «упаковать» и представить читателю. Представьте себе что работающий продукт это контент издания (книги, журнала, газеты). Пустая книга не удовлетворяет читателя. Без контента смысл в оформлении отсутствует. А без хорошего оформления содержание книги всё равно имеет ценность. Роль разработчика сравни роли автора.

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

Инструмент разработки, а не оформления.) (К слову о дизайн-системах: это стилевые решения для быстрого оформления контента.

Takeaway

Осознайте задачу пользователя.

Трудитесь в паре с разработчиком (как арт-директор и копирайтер). Начните с разработки.

Совершенствуйте работающий продукт вместо макетов.

Мыслите категориями цели, результата вместо процессов.

Дизайнер продукта создаёт продукт, а не макеты.

Этот метод вместе с библиотекой компонентов стал базой банковской дизайн-системы.

Предлагаю работать в такой последовательности:

  1. Осознать задачу клиента (пользователя) и зафиксировать в виде User Story.
  2. Определить метрики. Как мы понимаем, что задача пользователя решена? Зафиксировать.
  3. Сформулировать гипотезы. Зафиксировать.
  4. Customer Journey Map.
  5. Работающий прототип. MVP. Customer Development.
  6. Макеты. (При слаженной работе команды и существующей дизайн-системе можно обойтись без макетов).

Задача клиента

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

Задачу клиента выявляют либо на основании жалоб («боль клиента»), либо исследований потребностей.

Приходит с опытом. (Вскользь отметим, что жалоба и задача это разные вещи, и важно сохранять холодную голову и не бросаться «решать проблему» на основании жалобы — задача может быть другой, а жалоба вызвана несвязанными обстоятельствами. Применяйте способ «пять почему» — иногда он помогает докопаться до причины, на основании которой можно сформулировать объективную задачу.)

Об этом написано много статей и книг, поэтому я здесь повторяться не буду — изучите самостоятельно. Когда задача осознана, она записывается в виде User Story.

Для погружения в вопрос настоятельно рекомендую книгу User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton and Peter Economy).

Два типа метрик (важно фиксировать оба!)

  1. Сформулированный ответ на вопрос «Как мы понимаем, что задача пользователя решена». Что мы хотим получить в виде решения.
  2. Цифровые: относительные и абсолютные величины. Чаще про количественные показатели (финансовые, скорость, клиенты, время). Как мы поймем что решение удачное. Тут есть уловка: часто в презентациях за относительными величинами скрывают, преувеличивают или теряют объективный масштаб решения. Например, «прирост аудитории составил 3%» — это много или мало? Если это 150 000 человек (поселок городского типа, со школами и садиками, магазинами и своей администрацией) — то уже внушительное число, хотя кажется что мелочи. С другой стороны, «рост прибыли 300%», если это 300 рублей за месяц — уже сомнительный показатель. И снова, если 150 000 человек — статистическая погрешность в размерах аудитории всего продукта (допустим, посещения главной страницы поисковика в год), то этими размерами скорее всего можно пренебречь, хотя речь про население того самого поселка городского типа.

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

Анекдот про лучника

Лучший в мире лучник

Допустим, дело было в Японии — для остроты сюжета. Жил-был лучший в мире лучник. Лучник путешествовал по стране и удивлял своим мастерством окружающих, делился опытом. Он мог поразить цель лучше всех с самой большой дистанции, и даже как Робин Гуд попасть в собственную стрелу.

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

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

— удивился крестьянин. — Что случилось, Лучник?

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

— внезапно догадался крестьянин. — Ты наверное говоришь про пораженные цели в самых причудливых местах?

— О да, ты прав — с сожалением молвил Лучник.

Знай: это — проделки местного дурачка. — О Лучник! Мы все жалеем его. Он выпускает стрелы наугад, а мишени обводит позже. Ты ошибаешься.

Гипотеза — ответ на вопрос о самом быстром способе решить задачу пользователя

В разработке (дизайне) нельзя ограничиваться одним! Всегда существует несколько решений задачи. Никто не знает наперед, какое сработает лучше всего.

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

Имейте в виду, что «развитие» одной идеи в виде прогрессивно меняющегося макета это одно решение, а не три (или сколько у вас получилось сделать разных макетов).

Для простоты попробуйте три подхода:

  1. Интерфейсное решение. Их тоже может быть несколько.
  2. Автоматическое (например, на сервере выполняется задача по наступлению какого-то события) — без участия пользователя.
  3. Процессы — что можно изменить в процессах так, чтобы пользователь с задачей не сталкивался совсем, но получал решение в нужный момент.

«Научный метод»). Лучшее решение находится исключительно эмпирическим путём (см. Гипотезы надо проверять. Любое даже самое дикое на первый взгляд решение/идею необходимо проверять. Для этого вы сделаете прототип. Идеальный случай — проверка всех трёх гипотез, выполненных в виде MVP.

Customer Journey Map погружает в контекст

Если у вас небольшой продукт с единственной функцией, то CJM позволяет увидеть весь процесс решения пользователем задачи и выявить болевые точки, осознать реальное завершение задачи.

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

Про CJM написано довольно много, вам необходимо это изучить самостоятельно и применить в работе.

Начать можно с книги «Пользовательские истории» Джеффа Паттона.

Работающий прототип. MVP. Customer Development.

Это не обязательно будет идеальное в техническом и эстетическом плане решение — важно сделать минимально жизнеспособный продукт (MVP), в тестирование которого можно вовлечь новых и существующих клиентов (Customer Development). Договоритесь с разработчиком и сделайте работающий прототип для проверки каждой гипотезы.

Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели». Подробнее обо всём этом читайте в книге Эрика Риса «Бизнес с нуля. Пересказывать книгу нет смысла.

Однако книга намного полезнее. Если вы не знакомы с термином MVP, начните со статьи на Википедии.

Обойдемся без макетов, потому что есть готовый продукт

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

Takeaway

User Story
Как определяем успех
Гипотезы (способы решений)
CJM
Прототип, MVP, Customer Development
Макеты (если потребуются)

Самое большое, на что вы способны

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

Придется пояснить.

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

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

Они тратят время на придумывание буквально плохих интерфейсов (за зарплату), потому что обдумывают не то, как улучшить пользовательский опыт, а то, как его подстроить к процессам. Или когда бэк так откровенно плохо сделан, что дизайнеры занимаются исключительно созданием костылей. Это не фантастика, это реальность (когда вам говорят про ограничения в возможностях системы  получается та самая ерунда, а не «ограничения»; предложите таким ограничителям объяснить эту нелепицу клиентам с улицы  —  то еще развлечение получите).

Поедет ровно настолько, насколько смогут вытянуть те самые колёса. Аналогия из физического мира: если на гоночном болиде установлены плохие колёса, то круто он не поедет. Хотя инженер скорее всего был супер-крутой, раз болид создал. Даже если всё остальное  —  супер-крутое: мощный двигатель, сплошной карбон везде и всё такое  — на ободах быстро не поедешь. Чем больше терпимость к посредственности и ошибкам (это называется «компромисс»), тем хуже будет продукт/компания. То же самое с банками, приложениями, студиями, издательствами, агентствами и так далее. Продукт/компания настолько хорош, насколько плох самый плохой сотрудник или процесс: в магазине могут быть феноменально крутые/редкие товары, но если продавец хамит, то продажи будут хромать.

Думаю, мысль уже давно понятна.

Оказывается, многим это не понятно.

Зачем писать об этом?

Важно в работе только что и как в результате получают клиенты. Затем, чтобы у начинающих/продолжающих специалистов не было чувства собственной индивидуальной крутости (ложной), и чтобы ориентировались не на то, как и какие крутые макеты они могут отгружать, а на том, какой результат они могут отдать пользователю. Конечно, если важно сделать продукт, а не картинки отгрузить.

Принцип применяется везде, не только к продуктам.

Пополам

Глядя на макет: Как решить задачу половиной элементов интерфейса?

Сформулировать в два раза короче? Убрать половину текста?

Как решить задачу за половину отведенного времени?

Вообще отменить её? Провести встречу за 30 минут вместо часа?

Не делать её вообще, изначально? Убрать графику?

Нужны ли иконки?

Что будет, если убрать половину пунктов в навигации?

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

Бэклог не может быть обязательным набором — жизнь богаче планов, нужно гибко реагировать на реальность: принимать и анализировать обратную связь, отслеживать продуктовые метрики. Если появляются дополнительные идеи, можно заносить их в бэклог. Многое из надуманного окажется бесполезным уже на этапе тестирования.

Дели на два.

В более широком смысле рекомендую ознакомиться с принципом «Бритва Оккама», если еще не знаете что это такое.

Научный метод

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

Цитата из Википедии, чтоб два раза не вставать

«Нау́чный ме́тод — система категорий, ценностей, регулятивных принципов, методов обоснования, образцов и т.д., которыми руководствуется в своей деятельности научное сообщество.

Умозаключения и выводы делаются с помощью правил и принципов рассуждения на основе эмпирических (наблюдаемых и измеряемых) данных об объекте. Метод включает в себя способы исследования феноменов, систематизацию, корректировку новых и полученных ранее знаний. Для объяснения наблюдаемых фактов выдвигаются гипотезы и строятся теории, на основании которых в свою очередь строится модель изучаемого объекта. Базой получения данных являются наблюдения и эксперименты.

Не должны приниматься на веру какие-либо утверждения, даже если они исходят от авторитетных учёных. Важной стороной научного метода, его неотъемлемой частью для любой науки, является требование объективности, исключающее субъективное толкование результатов. Это позволяет не только получить дополнительное подтверждение путём воспроизведения экспериментов, но и критически оценить степень адекватности (валидности) экспериментов и результатов по отношению к проверяемой теории.» Для обеспечения независимой проверки проводится документирование наблюдений, обеспечивается доступность для других учёных всех исходных данных, методик и результатов исследований.

В моей трактовке идея принципа простая: справедлива только разведка боем.

Выкатывайте на клиентов. Придумали решение? В бой. Настаиваете на другом фоне?

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

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

Все результаты можно оцифровать: воронки, скорость, суммы субъективных оценок и так далее. Для проверки есть куча инструментов и методов.

Только наблюдение за поведением пользователей в реальных условиях даст ответы на вопросы (а не их мнения и рассказы). В то же время все рассуждения, виденья и так далее это просто сотрясание воздуха, не более.

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

Исходя из этого принципа я прихожу к таким соображениям:

  1. Любой участник команды может выдвигать гипотезу и тестировать её, безотносительно формальной роли: дизайнер, продакт-оунер, разработчик чего угодно (фронта/бэка/мидла и чего еще бывает). Все могут делать свой вклад в достижение результата. Командам следует продумать прозрачный и простой механизм учета и порядка запуска таких идей (если их много).
  2. У дизайнера нет индульгенции, права быть правым просто потому, что он — дизайнер. В некоторых командах я наблюдаю этот перекос, причем в обе стороны: разработчики и продакты манипулируют тем, что «ждут, пока дизайнер сделает дизайн» (отказываются думать самостоятельно), в то же время дизайнеры часто пользуются тем, что у них в должности прописано «дизайнер», и для некоторых название должности является аргументом в спорах. Продукт — совокупность усилий всех специалистов.
  3. Бывает такое, что самые дикие и нелогичные на первый взгляд решения работают лучше всего. Мы окружаем себя предубеждениями и не можем выбраться из них, посмотреть с другой стороны — это и правда очень сложно. Всегда будет включаться сопротивление изменениям — как внутри команды/организации, так и клиентами. Единственный честный выход — решительно действовать, уметь рисковать, тестировать боем, собирать обратную связь, наблюдать результаты и реагировать на них. По-другому ничего интересного не появляется. Замечено и доказано, что всё необычное позавчера становится нормой сегодня и обыденностью завтра — см. «Окно Эвертона».

Итого

  1. Тестировать боем  —  выходить хотя бы на часть аудитории и проверять все гипотезы.
  2. Всё оцифровывать — результаты должны быть прозрачными.
  3. «Дичайшие» гипотезы тоже надо уметь проверять.
  4. Всё, что подкрепляется только «экспертным мнением» и «опытом» (в конкретных интерфейсных/продуктовых решениях) смело отправляется на помойку — ориентироваться надо только на наблюдения за поведением реальных пользователей.

И еще бонус

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

Скачать ePub

Посмотреть на содержание сборника

Дизайнер 2022, по мотивам лекции в Сочи.

Лекцию готовил для студентов и школьников, и для России, поэтому она затрагивает вопросы демографии, ретроспективу (как было 20 и 10 лет назад) и фантазии на тему среднесрочной перспективы. Мысли на тему развития профессии дизайнера в ближайшие пять лет.

***

Дизайн цифровых продуктов — обещанный текст лекции из трёх частей:

  1. Цель дизайнера цифровых продуктов
  2. Роль дизайнера в продуктовой команде
  3. Метод — как работать над продуктом. Этот метод был описан для дизайнеров в Альфе, чтобы донести до новобранцев суть работы и ожидания.

Надо понимать что речь там идёт по большей части о работе в скрам-командах, а это исторически мой любимый формат сотрудничества.

***

Тройка принципов: чем я часто руководствуюсь в работе над продуктом:
• Научный метод
• Пополам
• Самое большое, на что вы способны

***

Инструкции или «Секретный секрет успешного успеха в успехе» — почему у вас не работает то, что работает у других и как мы себя научились обманывать.

***

Ловушка корпорации

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

***

Рекрутмент как продукт или «Ваня, найди нам дизайнеров!» —

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

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

***

Мой первый продукт —

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

***

И о спорте

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] UDB. Что же это такое?

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

Беспроводные технологии передачи звука на базе Bluetooth: что же лучше?

С развитием технологий так привычные всем «ламповые» аналоговые наушники уходят в историю – их всё больше вытесняют беспроводные собратья на базе Bluetooth. Современные смартфоны лишаются привычного разъёма в угоду влаго- и пылезащищённости. Разработчики выпускают всё новые версии протокола Bluetooth и ...