Алисия Суска написала о дизайн-долге.

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

In English. Смотрите также статью Сэма Айронса о дизайн-долге. #process

Костя Малков выписал главные мысли и примечательные цитаты из книги Кена Косиенды «Творческий отбор. Как создавались лучшие продукты Apple во времена Стива Джобса».

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

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

Накидывание идей на белой доске, споры и обсуждения ощущаются как работа. Но это не так. Это всё абстрактные идеи, которые не дают конкретной обратной связи, каким должен быть следующий шаг. Поэтому меньше мозговых штурмов и больше демок».

#process

Ксения Беляева написала о дизайн-ревью, когда дизайнер проверяет, как разработчик воплотил его дизайн.

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

#process

Александр Кочеванов написал о немодерируемом тестировании.

— Такое тестирование позволяет выявить проблемы предлагаемого интерфейсного решения, подтвердить или опровергнуть гипотезы до того, как разработчики это решение реализуют;
— Провести его можно после подготовки первой версии дизайна;
— Процесс состоит из а) подготовки прототипов к тестированию, б) составления вопросов для респондентов, в) запуска на специальной платформе, г) обработки результатов, д) составления отчёта;
— Платформы: Userfeel, Loop11, Hotjar, UserZoom, UserTasting, Usability Hub, Maze, Marvel;
— Прототипы лучше делать как можно более полными. Например, кому-то из респондентов удобнее график, кому-то таблица, и лучше, если прототип даст возможность выбрать удобный вариант отображения;
— Перед запуском проверьте прототипы и вопросы на коллегах, чтобы выявить ошибки;
— Проведите тест сначала на части респондентов из запланированных, чтобы найти и исправить первые проблемы. Затем можно сосредоточиться на остальном;
— Начинайте тест с вводной, которая погрузит респондента в контекст. Разместить её можно на первой странице прототипа (с кнопкой «Начать исследование»), чтобы возможности платформы по оформлению текста вас не ограничивали;
— Старайтесь использовать реальный контент вплоть до актуальной текущей даты;
— Попросите респондентов озвучивать всё, что они видят и думают. Особенно, если они сталкиваются с трудностями;
— Подумайте, что может пойти не так и подготовьте респондентов. Например, расскажите, как перезагрузить прототип, если произошёл сбой;
— Просите отвечать на вопросы вслух, а не письменно, чтобы не тратить на это время;
— Используйте скрининговые тесты, чтобы отфильтровать участников, которые вам не интересны;
— Просите оставить контакты, чтобы можно было обратиться в следующий раз к тем респондентам, кто показал себя ответственным и ориентированным на результат.

#user_testing #unmoderated #process

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

— На старте проекта дизайнер перегружен информацией. Надо раскладывать её по кучкам в разные артефакты;
— Impact Mapping — фиксация целей, проверка измеримости, необходимости и возможности достижения каждой отдельной цели;
— Customer Journey Mapping — детальное описание процессов, проработка точек контакта на разных информационных уровнях;
— Event Storming — инвентаризация пользовательских действий, экранов для вывода информации и взаимодействующих систем через разметку процесса ключевыми событиями;
— User Story Mapping — формализация функциональных требований;
— Журнал проектирования — структурированное хранение и контроль входящей информации;
— Непонимание всего пользовательского пути мешает учесть все детали, приходится возвращаться и переделывать одни и те же макеты. Помогает Breadboards — выписывание названий экранов и доступных на них элементов взаимодействия. Важно связывать экраны с пользовательскими историями;
— Иногда надо пойти глубже и представить, как будут выглядеть макеты из дальней части пути. Fat Marker Sketches — изображение макетов толстым маркером без высокой детализации;
— Чтобы от возможных вариантов интерфейсных решений голова не шла кругом, стоит придерживаться алгоритмов создания макета. Например, подход Epicenter Design — в первую очередь размещать на макете его основную ценность. Или алгоритм Игоря Штанга «Содержание → Структура → Конструкция → Стиль»;
— Чтобы UI был пригоден для реальной эксплуатации, надо стремиться к максимальной полноте и точности отображаемых данных. Данные выгодно привязывать к пользовательским историям (и как следствие — определённым моментам времени);
— Удобно сохранять часто используемые примеры данных: названия регионов, ИНН, ОГРН и прочие;
— Реальные данные могут сильно повлиять на предлагаемый интерфейс.

#process

Даниил Видишев написал, как работать с мелкими багами, появляющимися при реализации дизайна.

— Они бывают визуальными (не те цвета, отступы, анимация) и функциональными (у кнопки нет тултипа). Они не мешают пользователям достигать целей, поэтому получают низкий приоритет;
— В итоге их становится слишком много, чтобы можно было легко исправить, продукт начинает отличаться от макетов, растёт поток обратной связи от пользователей;
— Оформляйте баги правильно: пишите конкретно, что и где надо исправить (карточка пользователя, изменить стиль заголовка с 24 на 28 px), группируйте их с помощью тегов или папок, прикладывайте скриншот проблемы и ссылку на макет;
— Объясняйте команде ценность дизайна;
— Документируйте дизайн: подробно описывайте работу элементов (здесь стоит упомянуть мою статью о функциональной спецификации), прикладывайте референсы анимаций, показывайте в макетах пошаговые сценарии;
— Проводите ревью вёрстки, когда она уже почти готова (вряд ли получится выделить для этого отдельный статус задачи в Джире). Фронтендер может показать наработки на коротком созвоне;
— Если перечисленные выше процессы работают, можно внедрить автотесты на pixel perfect UI.

Смотрите также статьи Алисии Суски и Сэма Айронса о дизайн-долге. #process

Андрей Кононов написал о проектировании сложной функциональности на примере заказа товаров в сетевом магазине.

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

#process

Алиса Шефер и Саша Липатова написали, как UX-редакторам встроиться в дизайн-процесс.

— Знакомьтесь с командами не только дизайнеров, но и аналитиков, тестировщиков и маркетологов, которые работают над вашим продуктом. Повторять знакомство можно раз в квартал: люди приходят и уходят, меняются зоны ответственности редакторов;
— Задачи на текст надо ставить одновременно с задачами на дизайн, а если задача небольшая, то хотя бы за неделю до дедлайна. Так можно успеть погрузиться в контекст и собрать вводные, а не просто поправить формулировки;
— Чем полнее задача описана, тем лучше. Смотрите в статье шаблоны с вопросами, что писать в задачах на текст а) целого сценария, б) экрана или попапа, в) письма, пуша или смс;
— Создайте таблицу ответственности (например, в виде модифицированной матрицы RACI), чтобы коллеги легко могли понять, к кому из редакторов обратиться с конкретным вопросом или задачей;
— Разработайте и обновляйте гайды, глоссарии и редполитику. Опишите процесс работы над задачами и отличия разных редакторских ролей: основатель проекта, партнёр, ревьюер. Чтобы эти документы оставались актуальными, бронируйте на них 1 час в день;
— Чтобы новые продакты или тимлиды не забывали подключать редакторов к задачам, проводите 15-минутные онбординги с рассказом о процессе, базе знаний и гайдах;
— Соберите всех пишущих (и UX-редакторов, и копирайтеров из отдела маркетинга) в один чат, чтобы всегда можно было обсудить какие-то изменения в тексте и не копить недопонимание.

#process #writing

Александра Савельева написала об обновлении устаревших таблиц в большом продукте.

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

#table #process

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

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

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

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

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

#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