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