В Альфа-Лаборатории мы строили процессы продуктовой разработки как раз по скраму, где каждая команда является самостоятельной единицей, способной делать поставки так быстро, как смогут (в идеале — недельными или двухнедельными спринтами).
Важная оговорка: весь текст рассказывает о работе дизайнера в скрам-команде. Это очень важная оговорка, которую надо держать в голове. На лекциях я это упоминал мимоходом, как само собой разумеющееся, поэтому кто-то мог потерять смысл рассказа. Для канбана и традиционных подходов (договор-дизайн-верстка-сборка-акт) такой метод скорее всего может даже навредить. Поэтому, если вам понятие «скрам» ново, изучите подход — может быть кому-то это поможет лучше организовать работу у себя. По ходу текста я насыпал ссылок на статьи и книги.
В конце 2017 года в Лаборатории было около 30 команд (может больше), и почти для каждой нужен был свой дизайнер. Даже на таком относительно большом масштабе важнее работать на уровне стратегии, верхнеуровневых понятий и подходов, потому то «контролировать» работу 30 дизайнеров, которые работают над разными продуктами и в разных командах и с разной скоростью технически качественно не получится. Тактику определяет каждая команда самостоятельно, в этом вся прелесть.
Такая простая цель. Разберем каждое слово, ведь она не просто так сформулирована именно этими словами.
Обратите внимание на отсутствие слов-процессов, таких как «создание», «проектирование» и прочее. Процессы — это вовсе не цель. Целью может быть только результат, а не процесс. Но дизайнеры всего мира попадают в ментальную ловушку процессов, поэтому результатами их работы становятся артефакты процессов, а не работающие продукты.
У меня есть грустная статистика. Из десяти дизайнеров, приходящих «делать продукт и влиять на него» на результате фокусируется один, остальные — на процессах. Доходит долго, и хорошо, если доходит вообще.
Прежде чем польётся негодование, уточню: важности процессов я не умаляю и понимаю их. Фреймворки, исследования, проектирование, методологии, спецификации, гайдлайны, дизайн-системы, профессиональное ПО и так далее. Как только продукт попадает в руки пользователя, всё это теряет смысл: продукт либо работает, либо нет.
Если пользователь скачивает приложение, а оно не работает или не решает его задачу, становится неважным абсолютно всё: как собирались данные и проводились исследования, какими были макеты, в каком ПО они выполнялись, какие были блок-схемы и серые квадратики, как отчаянно работали программисты перед запуском и какое классное видео получилось с вечеринки в честь запуска продукта.
Любая профессиональная надстройка для «ускорения» или «совершенствования» процессов часто просто (уже будучи надстройкой, то есть фактически избыточным явлением) добавляет процессов и бюрократии, не решая задачи и не двигая команду к цели, а отдаляя от неё. Взять то же прототипирование1: вместо разработки, мы создаем эмуляторы, которые дают от силы 10-30% опыта, который будет в продукте. И проектирование. И исследования. И макеты. И вайрфреймы ДО макетов (некоторые отличают эту стадию от проектирования и вкладывают в одни и те же термины разные смыслы). Потом описание гайдов. И ещё «авторский надзор» (очень пошлое название подглядывания за работой разработчиков и ворчание — тут-то вскрывается миллиард неучтенных во всех этих «исследованиях» и «прототипах» нюансов). Так, вместо того чтобы стремиться к результату в виде продукта, дизайнеры или менеджеры создают массу высокозатратной возни. Вырастают отдельные профессии типа «проектировщик», «дизайнер интерфейсов», «UX/UI-дизайнер», «исследователь» и так далее. На конференциях вполне всерьёз начинают обсуждать легитимность склеивания UX и UI, мол этим должны разные люди заниматься, разные инструменты и задачи. Вместо фокуса на работающем продукте получается фокус на процессах, и каждая надстройка только отдаляет от реальной цели.
Надо понимать, что здесь речь идёт только о процессах, наиболее тесно связанных с работой людей, которых мы называем дизайнерами (что бы кто в это собирательное понятие ни вкладывал). Об устоявшихся процессах внутри давно существующей компании, которые называются «бизнес-процессами», и которые часто наиболее сильно влияют на продукт и опыт пользователя, здесь речи не идёт.
Anyway, вернемся к формулировке.
- Работающий продукт — тот, которым можно пользоваться, решать задачи. Речь о технической возможности решить задачу используя продукт.
- Продукт — некая законченная сущность, цельная, в сумме ингредиентов обладающая бОльшей ценностью, чем все они взятые по отдельности.
- Пользуются — говорит о востребованности и удобстве.
- Люди — более широкое понятие, чем «клиенты», «пользователи», «сотрудники» и т.д. Работая для людей, мы учитываем эргономику и какие-никакие но стандарты.
Допустим, продукт не работает. Тут всё понятно: пользоваться им (как минимум по назначению) не будут.
Или это не продукт: набор разрозненных компонент, не связанных между собой ни по какому признаку (такое тоже бывает).
Или продукт есть, но им не пользуются (совсем). Тоже провал, может быть чей угодно: отсутствие маркетинга, неудобный, тормозит.
Если пользуются не люди… тогда, допускаю, будут совсем иные принципы дизайна.
Эту мысль с разных сторон обсуждают и когда говорят про Agile, и про частые поставки, и про Скрам и про работу в командах, но даже при таких практиках дизайнеры почему-то порой скатываются в уютную колею «процессов». Допускаю такие причины:
- не понимают технологий и своего влияния на них,
- не могут повлиять на результат (страх «не послушают», отсутствие мотивации, выдуманная субординация «мне так не говорили делать»)
- не понимают своей роли
- скрам эксплуатируется без понимания цели, как фреймворк (см. также «Культ Карго») — тогда он точно не лучше ватерфолла (а то и хуже)
- устраивают небольшие ватерфоллы внутри скрама :-) — «Сначала дизайн, потом фронт-энд», вместо того чтобы работать как минимум вдвоём/парой. Это, почему-то, особенно трудно заходит как дизайнерам, так и разработчикам (но когда и если доходит, то к мини-ватерфольной модели они уже больше не хотят возвращаться, потому что она во всех смыслах ущербна).
P.S. Ссылки на описания перечисленных методологий, Википедия:
Часто роль дизайнера в продуктовой команде преувеличивают, потому что мыслят категориями процессов и последовательности действий (ватерфолл) вместо результата.
(Правильно мыслить от результата, категориями цели.)
Разработчик, просто сделав всё согласно стандартам и спецификациям скорее всего решит задачу лучше, чем если пройдётся по макетам дизайнера. Вероятно, даже продуктовые метрики будут лучше. При полном отсутствии дизайнера.
«Мы ждём макеты» — если такое звучит, значит процессы в команде организованы неправильно.
(Увы, многие разработчики и дизайнеры не знают о стандартах — хотя бы W3C для веба, а там заложено очень много фундаментальных принципов, которые помогают строить лучший опыт. По аналогии существуют описания/стандарты для ведущих мобильных и настольных платформ; iOS, Material.)
Обратите внимание на стартапы — Facebook, Вконтакте, Одноклассники и те же Apple с Microsoft: в их основе лежат инженерные решения (Возняк, Гейтс), к которым впоследствии присоединились дизайнеры. Они создавали продукты в соотвествии с Целью.
Сначала — работающий продукт.
(Красивый, справледивости ради, сделали идейные ребята в лаборатории Xerox, но масштаб последствий совсем иной.)
•••
В чем же тогда роль дизайнера?
В том, чтобы добавить ценность.
Добавить можно к чему-то существующему, обратите внимание.
Ценность в глазах клиентов, пользователей.
•••
Зачастую последовательность переворачивают с ног на голову и «ждут дизайн». Это, конечно, говорит о незрелости команды и неадекватном менеджменте этой самой команды.
•••
«Макеты» — анахронизм, наследние статичного веба, который раньше следовал эстетике и процессам подготовки журнальной и газетной графики. В продуктовом дизайне это перестало быть актуальным, но подход — за неимением другого — остался, как в процессах так и в сознании.
Начинайте с кода вместо макетов.
Приложение — динамика, движение, взаимодействие. Поэтому макеты в работе продуктового дизайнера чаще неуместны и противоречат цели.
Именно поэтому продвинутые дизайнеры мигрируют в прототипы с реальными данными. Хорошо ли это? Считаю, это избыточно — зачем программировать прототип, когда можно (и логично) сразу программировать продукт?
Лучше сразу двигаться от разработки к дизайну. Начинать именно с кода — прототипа, выполняющего задачу клиента в минимальном виде. Прототипа, который может пойти в рабочую поставку (вспомним позже про Customer Development).
(Здесь важна открытость и зрелость разработчиков — их готовность экспериментировать и совершенствовать программу, возможно даже переписывая код заново по несколько раз. Уверен, для этого уже давно существует много готовых решений.)
Сравнение с бумажной, физической вещью очень привлекательно, потому что пока что понятно больше других. Поэтому поддамся соблазну и приведу аналогию из жизни графического дизайнера.
Представьте себе что работающий продукт это контент издания (книги, журнала, газеты). Важно его правильно «упаковать» и представить читателю. Без контента смысл в оформлении отсутствует. Пустая книга не удовлетворяет читателя. Роль разработчика сравни роли автора. А без хорошего оформления содержание книги всё равно имеет ценность.
А контент дальше можно распределить как угодно. Кстати, сейчас контент распределяется между массой носителей — от бумажных до электронных. Те же книги в электронном виде живут в разных форматах и читалках, подтверждая приоритет контента над оформлением.
(К слову о дизайн-системах: это стилевые решения для быстрого оформления контента. Инструмент разработки, а не оформления.)
Takeaway
Осознайте задачу пользователя.
Начните с разработки. Трудитесь в паре с разработчиком (как арт-директор и копирайтер).
Совершенствуйте работающий продукт вместо макетов.
Мыслите категориями цели, результата вместо процессов.
Дизайнер продукта создаёт продукт, а не макеты.
Этот метод вместе с библиотекой компонентов стал базой банковской дизайн-системы.
Предлагаю работать в такой последовательности:
- Осознать задачу клиента (пользователя) и зафиксировать в виде User Story.
- Определить метрики. Как мы понимаем, что задача пользователя решена? Зафиксировать.
- Сформулировать гипотезы. Зафиксировать.
- Customer Journey Map.
- Работающий прототип. MVP. Customer Development.
Макеты.(При слаженной работе команды и существующей дизайн-системе можно обойтись без макетов).
Задача клиента
Кажется, будто здесь всё понятно, но зачастую это не так. С задачами клиента путают интерфейсные гипотезы, за них выдают хотелки менеджеров и вообще используют для не самых красивых манипуляций над командой.
Задачу клиента выявляют либо на основании жалоб («боль клиента»), либо исследований потребностей.
(Вскользь отметим, что жалоба и задача это разные вещи, и важно сохранять холодную голову и не бросаться «решать проблему» на основании жалобы — задача может быть другой, а жалоба вызвана несвязанными обстоятельствами. Приходит с опытом. Применяйте способ «пять почему» — иногда он помогает докопаться до причины, на основании которой можно сформулировать объективную задачу.)
Когда задача осознана, она записывается в виде User Story. Об этом написано много статей и книг, поэтому я здесь повторяться не буду — изучите самостоятельно.
Для погружения в вопрос настоятельно рекомендую книгу User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton and Peter Economy).
Два типа метрик (важно фиксировать оба!)
- Сформулированный ответ на вопрос «Как мы понимаем, что задача пользователя решена». Что мы хотим получить в виде решения.
- Цифровые: относительные и абсолютные величины. Чаще про количественные показатели (финансовые, скорость, клиенты, время). Как мы поймем что решение удачное. Тут есть уловка: часто в презентациях за относительными величинами скрывают, преувеличивают или теряют объективный масштаб решения. Например, «прирост аудитории составил 3%» — это много или мало? Если это 150 000 человек (поселок городского типа, со школами и садиками, магазинами и своей администрацией) — то уже внушительное число, хотя кажется что мелочи. С другой стороны, «рост прибыли 300%», если это 300 рублей за месяц — уже сомнительный показатель. И снова, если 150 000 человек — статистическая погрешность в размерах аудитории всего продукта (допустим, посещения главной страницы поисковика в год), то этими размерами скорее всего можно пренебречь, хотя речь про население того самого поселка городского типа.
Часто оказывается, что метрики придумывают после того, как продукт или фичу уже сделали. Для отчетности и красивой презентации. Это печально и мастерства не показывает, а напротив, портит картину и создает ложное ощущение спокойствия (расплата наступает всегда). Очень хорошо ситуацию иллюстрирует анекдот про лучшего в мире лучника.
Лучший в мире лучник
Жил-был лучший в мире лучник. Допустим, дело было в Японии — для остроты сюжета. Он мог поразить цель лучше всех с самой большой дистанции, и даже как Робин Гуд попасть в собственную стрелу. Лучник путешествовал по стране и удивлял своим мастерством окружающих, делился опытом.
В одной деревне он обнаружил множество пораженных целей, и были они в самых неожиданных и труднодоступных местах. Лучник понял, что здесь живет Мастер, уровня искусности которого ему никогда не достичь.
Лучник понял, что миссия его выполнена и дальше жить смысла нет. Он готовился сделать ритуальное самоубийство — сепукку — когда мимо него проходил крестьянин.
— Что случилось, Лучник? — удивился крестьянин.
— Я обнаружил, что в вашем поселении обитает Великий Мастер, который значительно превосходит меня в умении, посему миссия моя выполнена и я могу оставить этот мир.
— Ты наверное говоришь про пораженные цели в самых причудливых местах? — внезапно догадался крестьянин.
— О да, ты прав — с сожалением молвил Лучник.
— О Лучник! Знай: это — проделки местного дурачка. Он выпускает стрелы наугад, а мишени обводит позже. Мы все жалеем его. Ты ошибаешься.
Гипотеза — ответ на вопрос о самом быстром способе решить задачу пользователя
Всегда существует несколько решений задачи. В разработке (дизайне) нельзя ограничиваться одним! Никто не знает наперед, какое сработает лучше всего.
Проведите ментальную работу и придумайте, как минимум, три разных решения.
Имейте в виду, что «развитие» одной идеи в виде прогрессивно меняющегося макета это одно решение, а не три (или сколько у вас получилось сделать разных макетов).
Для простоты попробуйте три подхода:
- Интерфейсное решение. Их тоже может быть несколько.
- Автоматическое (например, на сервере выполняется задача по наступлению какого-то события) — без участия пользователя.
- Процессы — что можно изменить в процессах так, чтобы пользователь с задачей не сталкивался совсем, но получал решение в нужный момент.
Лучшее решение находится исключительно эмпирическим путём (см. «Научный метод»). Любое даже самое дикое на первый взгляд решение/идею необходимо проверять. Гипотезы надо проверять. Идеальный случай — проверка всех трёх гипотез, выполненных в виде 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 минут вместо часа? Вообще отменить её?
Убрать графику? Не делать её вообще, изначально?
Нужны ли иконки?
Что будет, если убрать половину пунктов в навигации?
Приём — фиксировать цель и отрезать всё лишнее, что не подходит к решаемой задаче. В единицу времени может быть только одна цель.
Если появляются дополнительные идеи, можно заносить их в бэклог. Бэклог не может быть обязательным набором — жизнь богаче планов, нужно гибко реагировать на реальность: принимать и анализировать обратную связь, отслеживать продуктовые метрики. Многое из надуманного окажется бесполезным уже на этапе тестирования.
Дели на два.
В более широком смысле рекомендую ознакомиться с принципом «Бритва Оккама», если еще не знаете что это такое.
Научный метод
Мне нравятся простые понятные подходы, принятые в научном мире. Например, доказательная медицина. И научный метод в более широком смысле. Разумеется, такие удобные штуки как-то переосмысливаются и адаптируются для своей работы. Так получился один из моих принципов продуктового дизайна.
«Нау́чный ме́тод — система категорий, ценностей, регулятивных принципов, методов обоснования, образцов и т.д., которыми руководствуется в своей деятельности научное сообщество.
Метод включает в себя способы исследования феноменов, систематизацию, корректировку новых и полученных ранее знаний. Умозаключения и выводы делаются с помощью правил и принципов рассуждения на основе эмпирических (наблюдаемых и измеряемых) данных об объекте. Базой получения данных являются наблюдения и эксперименты. Для объяснения наблюдаемых фактов выдвигаются гипотезы и строятся теории, на основании которых в свою очередь строится модель изучаемого объекта.
Важной стороной научного метода, его неотъемлемой частью для любой науки, является требование объективности, исключающее субъективное толкование результатов. Не должны приниматься на веру какие-либо утверждения, даже если они исходят от авторитетных учёных. Для обеспечения независимой проверки проводится документирование наблюдений, обеспечивается доступность для других учёных всех исходных данных, методик и результатов исследований. Это позволяет не только получить дополнительное подтверждение путём воспроизведения экспериментов, но и критически оценить степень адекватности (валидности) экспериментов и результатов по отношению к проверяемой теории.»
В моей трактовке идея принципа простая: справедлива только разведка боем.
Придумали решение? Выкатывайте на клиентов. Настаиваете на другом фоне? В бой.
Все заявления должны проверяться и подтверждаться экспериментальным путём. В цивилизованной среде они называются гипотезами, в любительских группах — «мнением» :-)
Условия эксперимента должны быть прозрачными и при необходимости воспроизводиться другими людьми.
Для проверки есть куча инструментов и методов. Все результаты можно оцифровать: воронки, скорость, суммы субъективных оценок и так далее.
В то же время все рассуждения, виденья и так далее это просто сотрясание воздуха, не более. Только наблюдение за поведением пользователей в реальных условиях даст ответы на вопросы (а не их мнения и рассказы).
Более того: только на бою вскрываются все реальные плюсы и минусы решений, обнаруживаются неучтенные ситуации и собирается реальная обратная связь от клиентов. При этом на разных стадиях развития продукта эта обратная связь повлечет разные последствия: от изменения критичных показателей на зрелом продукте до полного разворота/изменения концепции на молодом продукте.
Исходя из этого принципа я прихожу к таким соображениям:
- Любой участник команды может выдвигать гипотезу и тестировать её, безотносительно формальной роли: дизайнер, продакт-оунер, разработчик чего угодно (фронта/бэка/мидла и чего еще бывает). Все могут делать свой вклад в достижение результата. Командам следует продумать прозрачный и простой механизм учета и порядка запуска таких идей (если их много).
- У дизайнера нет индульгенции, права быть правым просто потому, что он — дизайнер. В некоторых командах я наблюдаю этот перекос, причем в обе стороны: разработчики и продакты манипулируют тем, что «ждут, пока дизайнер сделает дизайн» (отказываются думать самостоятельно), в то же время дизайнеры часто пользуются тем, что у них в должности прописано «дизайнер», и для некоторых название должности является аргументом в спорах. Продукт — совокупность усилий всех специалистов.
- Бывает такое, что самые дикие и нелогичные на первый взгляд решения работают лучше всего. Мы окружаем себя предубеждениями и не можем выбраться из них, посмотреть с другой стороны — это и правда очень сложно. Всегда будет включаться сопротивление изменениям — как внутри команды/организации, так и клиентами. Единственный честный выход — решительно действовать, уметь рисковать, тестировать боем, собирать обратную связь, наблюдать результаты и реагировать на них. По-другому ничего интересного не появляется. Замечено и доказано, что всё необычное позавчера становится нормой сегодня и обыденностью завтра — см. «Окно Эвертона».
Итого
- Тестировать боем — выходить хотя бы на часть аудитории и проверять все гипотезы.
- Всё оцифровывать — результаты должны быть прозрачными.
- «Дичайшие» гипотезы тоже надо уметь проверять.
- Всё, что подкрепляется только «экспертным мнением» и «опытом» (в конкретных интерфейсных/продуктовых решениях) смело отправляется на помойку — ориентироваться надо только на наблюдения за поведением реальных пользователей.
И еще бонус
Я сделал тематический сборник — по большей части про дизайн, а так как я покинул банк, то ещё и неизбежная рефлексия на тему дизайна в корпорации. Взгляд на работу без розовых очков
Дизайнер 2022, по мотивам лекции в Сочи.
Мысли на тему развития профессии дизайнера в ближайшие пять лет. Лекцию готовил для студентов и школьников, и для России, поэтому она затрагивает вопросы демографии, ретроспективу (как было 20 и 10 лет назад) и фантазии на тему среднесрочной перспективы.
***
Дизайн цифровых продуктов — обещанный текст лекции из трёх частей:
- Цель дизайнера цифровых продуктов
- Роль дизайнера в продуктовой команде
- Метод — как работать над продуктом. Этот метод был описан для дизайнеров в Альфе, чтобы донести до новобранцев суть работы и ожидания.
Надо понимать что речь там идёт по большей части о работе в скрам-командах, а это исторически мой любимый формат сотрудничества.
***
Тройка принципов: чем я часто руководствуюсь в работе над продуктом:
• Научный метод
• Пополам
• Самое большое, на что вы способны
***
Инструкции или «Секретный секрет успешного успеха в успехе» — почему у вас не работает то, что работает у других и как мы себя научились обманывать.
***
Ловушка корпорации
На удивление для меня, резонирующий пост; даже незнакомые мне люди писали и обсуждали, даже просили перевести на английский чтобы дать почитать коллегам в других странах.
***
Рекрутмент как продукт или «Ваня, найди нам дизайнеров!» —
подробное описание кейса разработки продукта с нуля, внутри корпорации. Я люблю эту историю, она вдохновила многих знакомых и бывших коллег, а ещё её рассказывали (уже без меня) эйчары Альфы на паре митапов и конференций.
Пост я приправил ссылками на все артефакты процесса — наши посты, публикацию Молиноса, статью в Коммерсанте и так далее. Мне самому было интересно сравнить то, как я думал год назад с тем, что я написал спустя год после запуска проекта. Этот феномен описан в одной из научных публикаций Умберто Эко, а здесь я посмотрел как это работает на своем примере. Занимательно.
***
Мой первый продукт —
история про то, как мы с одноклассником сделали настоящий продукт, из которого получилась компания. История аж из 1998 года, но очень показательная, рассказывает о том, как сложились мои принципы и подходы, которые я применяю в работе и о которых я здесь иногда пишу.
***
И о спорте
Считаю, что за пределами профессиональных тем забыты и напрасно оставлены темы физической культуры. Кто меня помнит хотя бы даже трехлетней давности — поймёт, о чем я: суета и работа довели меня до истощения и выглядело это ужасно. Надеюсь, этот текст поможет ещё кому-то крепко задуматься о своём здоровье заблаговременно, не дожидаясь печальных результатов какие были у меня.
Комментариев нет:
Отправить комментарий