Веня Векк записал видео о методе прогрессивного джипега.

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

О методе в Ководстве. #process #wireframe

Таня Миронова написала, как встроить работу над доступностью в процессы компании.

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

#accessibility #process

Егор Грохотов написал о быстрой проверке гипотез.

— В Авито разработку и развитие продуктов делят на стадии. Каждая завершается гейтом — встречей, где команда презентует и защищает свой прогресс перед руководителями направлений;
— Проверяют гипотезы на стадиях New Opportunities Discovery (этап исследования) и Product Discovery (этапы проверки спроса и ручной проверки). Цель — попытаться убить продукт на самой ранней стадии;
— Быстрее и эффективнее всего проверять самые рискованные гипотезы;
— Изучайте рынок в том числе через экспертов. Пара интервью с экспертами поможет быстро разобраться, как устроена интересующая вас сфера;
— Если этап исследования подтверждает потенциал идеи, при проверке спроса можно оценить продукт по верхнеуровневой воронке и нащупать каналы продвижения. Например, можно посчитать конверсию лендинга;
— Ручная проверка — сопровождение нескольких клиентов по всем этапам взаимодействия от заявки до целевого действия, чтобы выявить проблемы. Продукт при этом может быть собран на коленке;
— Подключайте юристов и бухгалтеров пораньше, чтобы собрать соответствующие ограничения и не тратить время на правки продукта потом;
— Скорость сборки прототипов новых услуг увеличивает заранее подготовленная инфраструктура: CRM, телефония, чаты, отдельный счёт в банке.

#product #research #process

В 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