В DesignHub написали, как давать обратную связь.

— Фидбек нужен всем. Даже опытному специалисту можно помочь свежим взглядом со стороны;
— Говорите не только, что не понравилось, но и как можно сделать лучше: предложите решения, приведите примеры, объясните, почему;
— Если не хватает экспертизы для конструктивного фидбэка, всё равно сообщайте, когда чувствуете, что что-то не так;
— Все люди разные, выбирайте форму обратной связи для конкретного человека: кого-то мотивируют позитивные комментарии, кому-то достаточно сухих фактов;
— Обсуждайте фидбэк лично: так комфортнее его получателю, и другие люди не скучают от специфической информации;
— Здорово, когда есть регулярные встречи между дизайнерами, на которых можно посмотреть и покритиковать работу друг друга;
— Не забывайте хвалить. Психологически тяжело, когда в ответ на хорошую работу поступает только список того, что нужно исправить;
— «Всё фигня, надо переделывать» — в целом хороший фидбэк. Можно сформулировать мягче, но главное не потерять смысл, чтобы специалист не услышал «Всё хорошо, но есть что улучшить»;
— Не надо выдавливать из себя комментарий, просто потому что подключили к задаче и спросили мнения. Если добавить нечего, так и говорите;
— Формулируйте комментарии как предложения для улучшения («Можно сделать это», «Тут хочется сделать так», «Думаю, будет лучше попробовать»). Вы можете оказаться неправым. Получатель фидбэка может не согласиться с комментариями;
— Фидбэк для кандидатов должен быть таким же, чтобы на ранних этапах взаимодействия заложить правильные принципы коммуникации.

#process

Илья Бирман написал о методе предложений.

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

#process

Илья Бирман написал о ещё одном методе проектирования интерфейса — потоке данных.

— Он помогает избавиться от лишних экранов и шагов;
— С точки зрения ТРИЗа, идеальный интерфейс — это интерфейс, которого нет, но его функция выполняется;
— Об интерфейсе можно думать как о посреднике в потоке данных, которые текут между людьми и машинами;
— Например, человек собирается в поездку и хочет узнать погоду в месте назначения. Интерфейс помогает запросу человека попасть в машину и отобразить нужную информацию. Отсюда получаем интерфейс: поле ввода города, и рядом — погода в нём;
— Интерфейс оператора пультовой охраны: оператор должен получить какие-то данные о сработавшей сигнализации, что-то сделать с ними, что машина сделать не может, принять решения, и отправить данные обратно в систему;
— Метод подойдёт, когда речь о конвейерном, транзакционном взаимодействии, когда процесс работы не слишком творческий;
— Но всё же всегда полезно думать не модулями и не «бизнес-сущностями», а сценарием и ролью интерфейса в нём.

#process

Слава Шестопалов написал об ограничениях дизайн-воркшопов.

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

In English. #process

Андрей Шапиро написал о test-driven design и полезных дополнениях: приём «Штука» и инвентаризация агрегатов.

— В проектировании надо шаг за шагом принимать решения и постоянно держать в фокусе конечную цель;
— Суть в том, что есть одно или несколько условий, которые должны быть удовлетворены, чтобы остановиться в поисках решения;
— «Штука» решает все проблемы и может принять любую форму, это абстрактная сущность, которую ещё предстоит создать;
— В общем случае любая «интерфейсная штука» показывает информацию и даёт манипулировать собой;
— Мы не знаем, как она будет выглядеть и из чего будет состоять, но можем сформулировать, зачем она нужна и что именно должна делать;
— Сформулировав требования, мы можем приняться за итеративное «выращивание» штуки;
— Test-driven development — сначала пишем приёмочный тест, например, что сложение 2 и 3 даёт на выходе 5, и только после этого — код, реализующий алгоритм;
— Подход прекрасно ложится в область дизайна: формулируем набор приёмочных критериев (вопросы, на которые можно ответить «да» или «нет») и затем конструируем решение, пока она не удовлетворит им всем;
— Инвентаризация агрегатов помогает заранее верхнеуровнево понять, из чего будет состоять конструкция. Просматриваем список критериев и выделяем агрегаты — крупные смысловые узлы конструкции интерфейса (например, мультизагрузчик файлов, насыщенная фильтрами таблица) и внутренней логики (обработчики очереди);
— Подход хорошо работает, когда на старте никто не знает, каким должен быть результат, когда нет известного паттерна;
— Позволяет легко сверять курс с другими людьми и валидировать генерируемые решения.

#process

Никита Черемисинов и Федор Раклов написали о методе генерации идей Playing the Future.

— Метод наиболее эффективен, если встроен в процесс дизайн-мышления и следует после эмпатии с фокусировкой, когда уже есть данные исследований;
— Команда должна быть кросс-функциональной, чтобы рассмотреть проблемы под разными углами. Например, разработчики помогут разобраться с техническими ограничениями;
— Перед генерацией идей надо изучить тренды (совсем далёкие вроде колонизации планет, наверное, стоит отбросить) и технологии в своей области. Например, пользовательские тренды: инклюзивность, управление жестами и голосом, персонализация, омниканальность;
— Важно раскрыть участникам всё, что известно о пользователях. Задача — не просто решить проблему (она может быть не озвучена прямым текстом), а сделать своего пользователя круче;
— Затем надо описать портреты пользователей и проблемы, с которыми они сталкиваются;
— Фреймворк How Might We: кто, проблема (безопасно передавать рабочие документы с телефона на ноутбук), чтобы что (не получить штраф за нарушение политики безопасности);
— Далее надо объединить проблему со случайно выбранным трендом и 5 минут побрейнштормить. Например, проблема — необходимость работать с телефоном в перчатках, тренд — управление жестами, идея — запускать функции движением телефона (потрясти, чтобы разблокировать или включить фонарик);
— Выбрать жизнеспособные идеи можно с помощью диаграммы Венна с 3 областями: ценность для пользователя, ценность для бизнеса, техническая реализуемость (по сути, табуретка Нормана).

Название статьи, конечно, претенциозное. #process

Павел Шерер написал 4-ю статью цикла о функциональной архитектуре.

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

#functional_architecture #process

Павел Шерер написал о страхе неопределённости в начале проекта.

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

#process

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

— Использование фреймворков и инструментов без понимания, зачем они нужны, — карго-культ (так можно легко опознать джуна);
— Вопросы, без ответов на которые задачу не решить: зачем, кто, что, как, когда;
— Отвечать на них можно в любом порядке. Лучше начинать с «Зачем», но Иван часто начинает с «Кто», чтобы понять, у кого спрашивать;
— Каждый фреймворк помогает частично или полностью ответить на один или несколько таких вопросов;
— Например, Mental models отвечает на «Кто наши пользователи?», а Stakeholder map — на «Кто наши стейкхолдеры и как с ними работать»;
— «Зачем» — фильтр для всего, что мы делаем. Аргументы на этом уровне хорошо понимает бизнес. User story map помогает увидеть, на каком этапе взаимодействия находится фича, и определить её приоритет;
— «Что» — что именно надо сделать и что получат пользователи: описания фичей, макеты, Userflows;
— «Кто» — важно не просто понимать, «Кто», но и «Какие они»;
— Карта стейкхолдеров показывает, на какие группы их разделить и как с ними работать: Inform, Show consideration, Keep satisfied, Work together;
— Возможно, артефакты JTBD потребуются только для того, чтобы конкретные участники увидели, что на этот раз всё по-науке, а не на коленке;
— «Как и когда» — в сложных задачах могут появиться вопросы вроде «Как собрать требования» и «Как вообще выстроить процесс». Здесь Scrum, Agile, Design Thinking и так далее;
— Полезные процессы стоит добавлять постепенно. К каким-то изменениям и практикам команда может быть ещё не готова;
— Внедрение идёт проще, если выделить проблему команды или бизнеса и принести одну из практик в качестве решения;
— Берите фреймворки как есть и пробуйте применять. Лучше в тепличных условиях, без дедлайнов и жёстких требований к результату — иначе трудно учиться, рефлексировать и делать выводы;
— Уже после максимального освоения и практического применения со стабильным результатом фреймворк можно переделывать под себя, скрещивать с другими подходами и так далее.

#process

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

— Креативные методологии (фреймворки для быстрого создания новых идей) — узкий инструмент с кучей ограничений, и подменять им творчество нельзя;
— Все они работают примерно так: некий объект раскладывается на составляющие → проводится работа с этими частями (что-то убрать, поменять, добавить, набор операций ограничен) → собирается новый объект;
— Их подают как последовательность действий, переключающих мозг на дивергентное мышление, что даже полезно;
— Постфактум можно увидеть, как эти действия привели к созданию каждой успешной идеи, но просто выполняя эти действия нельзя быть уверенным, что они приведут к успешной идее. Успех зависит от кучи других факторов;
— Творчество начинается с повторения, выработки навыков;
— Затем действия складываются в системы: технологии и методологии. Уже не нужна директивность, задачи объединены в последовательности, которыми человек и оперирует;
— Владея несколькими методологиями, можно выбирать более подходящие и комбинировать их. Это профессиональный кругозор;
— Затем становится доступна творческая деятельность: изобретение новых инструментов, подходов, идей. Это работа уровня RnD-отделов компаний;
— Креативные методологии позволяют получить много поверхностных идей, не сильно в них погружаясь. Годится для маркетинга, но в других сферах работает плохо;
— Создаётся иллюзия, что творчество — это легко и быстро. Но это одна из самых тяжёлых деятельностей: на час брейншторма можно потратить больше сил, чем на полный рабочий день;
— Если заниматься этим постоянно в рамках операционной деятельности, можно выгореть;
— Ломается нормальный процесс набора опыта. Люди занимаются чем-то другим вместо расширения профессионального кругозора, изучения предметной области и системных вещей;
— А ведь только это может привести к прорывным идеям, когда большая часть из них уже сгенерирована и реализована, и требования к продуктам уже не такие, как раньше.

#process

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

— С неполными вводными на старте минимально нужно 40 часов, чтобы заложить основу будущего проекта;
— Даже работая по схеме Time and materials клиент хочет знать примерный срок, бюджет и что он получит;
— Сначала надо собрать и систематизировать вводные (от 5 часов): презентации и текстовые описания, внутренние документы, скриншоты, фото с доски, наброски от руки и так далее;
— Иногда вводные приходят в созвонах, переписках и голосовых, что требует дополнительной обработки и структурирования;
— Может появиться список недостающей информации (метрики, списки конкурентов), а также нераскрытых или двусмысленных описаний, которые требуют конкретизации;
— В итоге получится структурированный список вводных, ссылок на документы, описание проекта (цель, задачи, целевая аудитория, контекст, заявленные проблемы), глоссарий;
— Удобно собрать всё в одном месте, например на FigJam-доске;
— Туда же можно добавить саммари по созвонам, кто за что отвечает в команде заказчика, план проекта, который потом дополнится ссылками на артефакты и их статусами, отчёт о потраченном на проект времени;
— Анализ занимает от 20 часов и зависит от количества и полноты вводных, числа ролей и ключевых сущностей, сложности бизнес-логики, а также желаемого набора артефактов (не все они нужны заказчикам);
— Сильно влияет степень вовлечённости заказчика — как быстро он отвечает на вопросы;
— Артефакты: описание функциональности (возможности и зависимости), схемы бизнес-процессов (последовательность операций, перемещение и обработка данных, граница между онлайном и офлайном), описание пользовательских ролей (чем занимаются, как принимают решения и взаимодействуют друг с другом), сущностей (ключевые объекты, их свойства, связи с другими объектами), сценарии (user stories), список внешних процессов, матрица «Роль × действие × сущность» и базовые правила доступа (CRUDL);
— В процессе анализа фиксируются ключевые требования к интерфейсу, предварительные предложения и решения по дизайну, появляются вопросы;
— Ответы на некоторые вопросы могут требовать времени. Чтобы не тормозить процесс, иногда можно договориться с командой о временных гипотетических ответах;
— Проектирование занимает от 15 часов (зависит от количества сценариев и ролей) и опционально. Артефакты: информационная архитектура (карта экранов), юзерфлоу, опционально мокапы и вайрфреймы.

#process #analysis

2/2

— Применение дизайн-мышления в продуктовом дизайне затруднено жёсткими рамками, в которых находится дизайнер: табуретка Нормана, специфика конкретного продукта, видение продакта;
— Самому фреймворку, который продают консалтинговые компании вроде IDEO, не хватает системного мышления;
— Хорошо, когда ограничения есть. Это стимулирует творчество, повышает сложность, что может превратить скучную задачу в нескучную и ввести в состояние потока. Но слишком жёсткие ограничения могут привести к пересыханию творческого ручья;
— Чтобы интерфейс оставался интуитивно понятным, следует придерживаться сложившихся паттернов, помнить о законе Якоба. Излишняя креативность может навредить;
— Но когда понимаешь, что делаешь, паттерны можно нарушить;
— При взаимодействии с произведением искусства возможен катарсис. Во время дизайна: эмоциональный провал из-за клиентского «это совершенно не то», приятное чувство, когда уже почти готово и полируете результат (это ловушка!), удовлетворение от завершения работы, чувство причастности, когда кто-то пользуется результатом вашего труда и хвалит его;
— AI повышает креативность, забирая простые задачи (или помогая их автоматизировать вайбкодингом) и высвобождая человеческие ресурсы для задач посложнее. Может взглянуть на проблему под совершенно другим углом (AI для игры в Го);
— Чтобы прокачать креативность: читайте хорошую художественную литературу, общайтесь с непохожими на вас людьми, «набивайте коробочку» в том числе и не связанными с дизайном знаниями, повышайте планку вкуса;
— Попробуйте увидеть скрытые паттерны, по которым вы выполняете свою работу — свой модус операнди. Определив их, попробуйте нарушить;
— Давайте мозгу время переварить информацию и синтезировать идеи. Утро вечера мудренее, особенно, если вы уже не эффективны и хотите доделать просто чтобы поставить точку;
— Да и вообще работать надо по расписанию, не рассчитывая на появление музы. Но если муза пришла вне расписания, не гоните её;
— Если пришла идея, постарайтесь зафиксировать её полностью. Лучше черновик всей песни, который можно потом довести до ума, чем идеальный отрывок, который может вообще ни к чему потом не подойти (Рик Рубин);
— Результат работы продуктового дизайнера не будет выглядеть таким же креативным, как работа моушен-дизайнера. Но и у него найдутся свои ценители.

Видео, копии в моём блоге и Медиуме. #process