Интересное метанаблюдение по работе за эти полгода: люди находятся в состоянии стресса с переработками, но одновременно с этим не хотят «бездельничать». Поэтому напрягают себя дополнительно, в основном когнитивно: Netflix/Twitch и одним глазом в какую-нибудь игру или паззл, домашние дела под аудиокнигу.

Эта тема всплывает сама примерно с середины первых локдаунов в июне на разных аудиториях и далёких друг от друга ислледованиях.

«Не простаивать бессмысленно» пытаются и те, кто пободрее и те, кому сейчас явно не очень. Больше всего это похоже на забивание потока внимания и попытку понизить чувствительность перегрузкой. Других выводов нет, очень удивлена этой красной нити, продолжаю наблюдения.

C кем ни заговорю, все либо уже выгорели, либо на пути туда.

Коллеги заняты без просветов, клиенты довольны, но результаты внутренних опросов про самочувствие пугают даже HR. Так в нашей experience design команде образовался еженедельный flow day в календаре (тупо не дёргают весь день), а потом добавились среды без встреч для всех в компании. Сильно ситуацию это не улучшило.

Я же всегда была уверена, что выгоранием просто называют форму усталости, принятую в западном мире и относилась скептически, пока сама не свалилась с первой в жизни мигренью от напряжения аккурат посреди рабочего дня где-то на четвёртом месяца изматывающих параллельных проектов.

Короче, только порывшись в первых исследованиях этого состояния, наконец, нашла понятную модель, которая заставила меня поменять отношение. Выгорание первым описал немец Фрайденбергер в семидесятых, начав с изучения работающих в кризисных центрах медицинских сотрудников, а потом переключившись на так называемых high performers.

Он описывает состояние выгорания как последствие целеустремлённости или рвения человека, которое множится на внутренние высокие требования к себе и внешние организационные рабочие факторы. Другими словами, от угорания к выгоранию.

В результате я ушла в саббатикал, чтобы восстановиться и честно посмотреть на внутренние требования, и признать, что умение собрать ресурсы и успешно пахать в формате «вижу цель, не вижу препятствий» привело меня в высокую точку карьеры за счёт допинга собственной кровью – а дальше здорового роста не будет, пока я это всё не пересоберу.

Судя по этому треду, всё могло быть намного хуже — человек довёл себя до ПТСР умственным перенапряжением и мозг просто временно схлопнулся

Напряжение я сбрасывала, печатая по паре предложений по интересам в Roam Research, и вот они выросли в цикл заметок про рост ux-исследователя вместе с прикладными приёмами, которые мне дико помогли не утонуть. Это ещё и вопросы, которые я чаще всего слышу через researchtalks и менторство nfng: учёба, управление сложными изменениями, как работать с разными данными, прототипы для исследований, структурная коммуникация, влияние в команде и как и никого не поубивать в процессе.

Если вы из новых читателей, добро пожаловать, я всё буду публиковать постепенно. Если вы из старых — спасибо за терпение!

Вот только я напрочь забыла всё про каналы в Tegeram, и как тут нормально сделать. Помогите понять, как мне публиковать тексты, если они довольно большие?

Я долго жила в наивной уверенности, что методология исследований и тщательный анализ плюс лазерно-точные рекомендации — это самое важное в моей работе. Этот подход очень милый, но он совершенно не учитывает, что дизайн-проекты, в основном, проваливаются из-за других вещей: организационные проблемы, сопротивление изменениям, внутренняя структура повышений и премий, динамика и зрелость команд.

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

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

На практике я успела обкатать эту модель под пять проектов: крупный редизайн на последние деньги нетехнологической компании (которая пытается догнать tech-конкурента), создание и проведение курса по коммуникации и визуализации данных для аналитиков, product-market fit для видео шоппинг b2b стартапа, и большой problem space research о мерчандайзерах Tesco. Модель работала безотказно даже на фоне беспросветных сомнений в своих мышлении, методах, знаниях и ценности для команды.

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

Для меня модель оказалась полезной дважды: во-первых, понятны критерии для успешных изменений. Во-вторых, наглядно показано влияние одного блока на всю систему. Если команда сопротивляется рабочему варианту, не зависит ли от этого их OKR на квартал? В то же время, отсутствие одного компонента прямо сейчас не обязательно означает провал в результате — просто в этом конкретном месте будет очень сложно и придётся разводить тучи руками.

Я обожаю манифесты, особенно когда есть повод.

После прошлого поста поучаствовала в паре обсуждений с недопониманием роли ux-исследователя через симплификацию до юзабилити или «кастдева» и имела время и вдохновение описать, как я вижу из своего опыта роль ux-исследователя в продуктовых командах через понятную аналогию.

Эдвард Де Боно придумал технику шести мыслительных шляп, где каждая шляпа — отдельный и самостоятельный стиль принятия решений через разные перспективы, которые мы «надеваем» по очереди и смотрим на ситуацию. Посмотрела на нашу работу через несколько шляп, где нужны все, а иногда сразу.

1. Фасилитатор
Мы часто должны вести команды, коллег и всех стейкхолдеров к общим и очень разным целям или быстрому принятию решений.

2. Стратег
Мы даём командам осязаемые возможности принимать хорошие решения и прояснять текущую и будущую работу, помогаем обнаруживать новые направления для всего бизнеса и частей.

3. Ботан-учёный
Эта часть двойная: как про личную ответственность проведения этических и инклюзивных исследований, так и про надёжные и точные результаты, строгое соблюдение методологии, статистические методы. Уверенность, что и стратегические и тактические процессы исследований (выбор правильных методов и максимально безупречное проведение) соблюдаются на высоком уровне. Сюда же идёт нейтральная позиция при работе с данными и презентации, работа с когнитивными искажениями.

4. People's advocate
«Співець горя народного». По долгу службы приходится держать бубки инсайтов в голове, быстро вспоминать о пользовательских привычках посреди митинга и рассказывать убедительные истории и всё время помнить, что итерация бессмысленных продуктов — путь в никуда, чем бесить всех, принимающих решения бизнеса на следующий квартал.

5. Дипломат
Это ещё одна коммуникационная шляпа для исследователей, без которой никак не обойтись для маневрирования через минное поле внутренней политики, хотя при этом, саму работу тоже никто не отменял. Спектр действий — от простой медиации личных трений до сложных миротворческих операций.

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

7. Детектив
«Ничего не понимаю! Или что-то случилось, или одно из двух!». Наш процесс часто начинается с вопроса, который аж печёт и включает в себя процесс сбора улик через организацию и подозрительные вопросы пользователям.

8. Технарь
Всё, что связано с владением софтом, скриптами, хоткеями, бэкапами, техникой и аппаратурой для исследований и всяким таким. Куда ж без ящиков этих дурацких.

9. Организационный терапевт
Это вообще не входит ни в одно описание вакансии и не исполняется напрямую, но исследователи помогают командам и бизнесу работать слажено, разруливать проблемки и улучшать бизнес-показатели. А если вы внимательно читали предыдущие два поста, то принять это как часть работы, выходит, неизбежно.

10. Учитель
Последняя в списке, но точно не последняя по весу шляпа. Мы учим другие команды и части бизнеса ценности нашего подхода (так иногда утомляет, сил нет), осмысленности принятия решений и помогаем коллегам (PM, продуктовые дизайнеры, PO's) делать какие-то простые исследования самостоятельно.

Если вдруг спросят про роль исследователя в команде, только так и буду отвечать теперь.

Прототипы для ux-исследований

Я никогда не упускаю случая дружелюбно сунуть нос в чужие прототипы для исследований. У большинства есть один недостаток — выглядят они хорошо, а вот для исследований не подобраны правильно, потому что не учитывают происходящее на сессии, человеческое поведение и соответствие задачам.

Прототип — это всегда репрезентация дизайна или некоторых его аспектов. Это переход от концептуальной модели к деталям имплементации. Они помогают нам быстро получать обратную связь и нащупывать unknown unknowns. Мы используем прототипы для тестирования с пользователями (формативной оценки) и обкатывания новых гипотез, поиска идей или чтобы нагляднее продать концепт или продукт. В каждом из этих случаев «прототип» будет значит что-то отдельное, поэтому я хочу описать подход для исследовательских прототипов.

Первое правило исследовательского прототипа
Детализация прототипов всегда должна совпадать с уровнем продуманности и детализации мышления. Под детализаций я понимаю, в основном сравнение прототипа ведёт себя с финальным продуктом. Если тестируется идея, её бессмысленно доделывать до последней анимации, потому что правдоподобности можно добиться и без них.

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

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

Мой подход: есть уровни детальности — низкая, средняя и высокая и пять её измерений: визуальное, ширина, глубина, интерактивность и модель данных. В зависимости от разных целей прототипа, получается разный уровень детальности для каждого измерения, но в итоге есть довольно точный подход на извечный вопрос, с чем мы тестируем, определяя что включить в прототип и как будет выглядеть смешанная детализация.

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

Гипотезы, которые обычно сопровождаются для прототипами низкой детализации: концепты высокого уровня, навигация, терминология, пользовательские сценарии, общая работа, сегментация аудитории Высокая детализация: задания на выполнение конкретных действий, понимание пользователями финальной навигации и структуры, детали визуального и продуктового дизайна (типографика, анимации).

С чего начинаются прототипы

1. Процесс прототипирования начинается с идей, а уже из них происходит переход к экранам (как кино начинается написанием сценария, а не со спецэффектов). На сессиях тоже тестируйте сценарии, а не экраны.

2. Используйте только максимально близкий к настоящему контент: текст, заголовки, картинки, уведомления. Никакого Lorem Ipsum или шуток, особенно для экспертных аудиторий. Модель данных прототипа всегда влияет на контекст пользователя и результаты. Никогда не забуду, как дизайнер вбил в продукт для спортсменов Эрдогана и героинь взрослых фильмов, люди просто сдувались на сессии.

3. До сборки прототипа, поймите его роль после тестирования: одноразовый, эволюционный или инкрементальный.

Одноразовые самые дорогие: почти выбрасываются после тестирования, вносят ясность в концептуальные проблемы. Эволюционные прототипы итерируются и постепенно вырастают в финальную форму с риском переноса плохих решений. Инкрементальные помогают построить финальную систему из компонентов.

In praise of trade-offs

Прямого аналога слова trade-off в русском языке как будто бы нет, а ведь мы только в них и работаем. Каждый проект — набор совместных компромиссов и уступок. Мыслить ими помогает строить точку зрения и принципы принятия решений.

Это мышление неплохо работает и в коммуникации, внешней и внутренней. Допустим, один старый клиент любит оспаривать утверждённые детали и выкатывать внезапные правки. Беда в том, что даже самый вежливый восточноевропейский отказ в этом случае воспринимается как приглашение к конфликту (а это смертный грех номер ноль здесь 🇬🇧). Так я впервые в жизни перестала говорить «нет» и стала заходить с согласия и перечислять последствия и картины мрачного будущего с ошеломительным успехом.

«Да, конечно, мы можем внезапно поменять состав участников исследования и добавить ещё пару пенсионеров за счёт остальных групп. Правда, это ухудшит надёжность, будет стоить дополнительных денег и рискует перекосить результаты, но этот trade-off я готова принять и сделать, если он для вас важен. Кстати, расскажите, почему».

Или вот при попытках добавить в начале, середине и конце проекта работы сверх запланированной я уже механически спрашиваю «Правильно ли я понимаю, что X больше не приоритет?», открываю календарь и мы вместе смотрим, что оттуда можно выбросить, чтобы сделать все эти новые и интересные вещи.

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

"We would like you to focus on your process, trade-offs and impact more than specific insights that you may have generated."

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

А ещё начала собирать новую навязчивую идею: описать пять препятствий современной UX-практики, опираясь на опыт, классический подход к HCI и собственный характер. Три уже есть: игнорирование информационной архитектуры и моделей поведения, практики менеджеров продуктов и перекос в предпочтительных методах исследований, ещё два препятствия пока под вопросом. Обычно я фокусируюсь на прикладных моментах и решениях, но сейчас хочется расширить масштаб от «как это делать» до «зачем это всё надо».

Препятствие 1: игнорирование информационной архитектуры и моделей поведения

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

Информационная архитектура лежит в ДНК любого сильного продукта и системное мышление невозможно без её понимания. А мы, кстати, только системы и разрабатываем.

Это не просто классическая фишка из восьмидесятых, её не вывели когнитивные психологи или ребята из Xerox PARC. Эта практика древнее языка — поиск смысла и упорядочивание мира пришли к нам с ранними периодами человечества, и уж точно древнее технологий. Возможно, поэтому те, у кого информационная архитектура вшита в процесс поиска решений, не выделяют её отдельно.

Проблема в том, что большинство команд обычно не имеют достаточных процессов системного мышления и осознанный дизайн систем и моделей — скорее исключение, чем правило.

Так растёт UX-долг и технический долг, так мы получаем (и сами делаем) хаотичные роадмапы без ключевых структур, которые просто упустить с драматическими последствиями.

Есть отдельная часть практики информационной архитектуры — sensemaking, на родном языке я могу называть это только «смыслообразованием».

Вместо того, чтобы пересказывать основы, написанные другими людьми в сто первый раз, я хочу поделиться моделью-словарём, как люди пытаются понять информацию в интерфейсах.

Она помогает отделить идеи, цели и действия от инструментов и средств интерфейса. Более того, она не привязана к какой-то одной парадигме и работает как для веба, так и для голосового управления, так и для технологии, которой пока не существует. В общем, есть 19 определений: 15 действий в 4 темах, которые и составляют обширный словарь. (Больше в книге Figure It Out)

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

Однажды мне сказали: «есть критично важное онлайн-бронирование билетов в разработке, сделано кем-то и как-то, аналитики нет. Вам надо его переделать лучшим образом, ответ обоснуйте, время пошло».

Я долго смотрела в стену, а потом сделала это (по модели постом выше), посмотрела через линзу бизнеса, убедилась, что оно складывается, и только после стала объединять, перемещать, добавлять, отрезать, перетрусить содержимое и двигать разные фичи.

Так вышел новый набор предположений, который был протестирован. Здесь надо ещё сказать, что модель user journey, основанная на исследованиях, конечно, лучше чем та, где их не было.

Но даже последняя всё ещё лучше, чем набор вшитых убеждений невидимых убеждений в интерфейсе. Одно из неоспоримых преимуществ моделирования — проясняются недоразумения, это невидимое становится видимым.

Модели, по определению — всегда сплющивание реальности, построенное на обобщениях и упрощениях.

В конце-концов, все модели неправильны, но некоторые из них полезные.

Старый ридер навсегда

Первого июля 2013 года Google Reader перестал существовать навсегда. В этом году мы живём в мире без него больше, чем с ним.

Сегодня я особенно сентиментальна, потому что я сразу иду открывать The Old Reader — собственный первый большой продукт, который получилось сделать командой из трёх человек. Сейчас ему идёт десятый год жизни.

Возможно, вы столько лет в интернете, что помните Google удаливший комментарии из своего rss-ридера. Я лично три месяца сообщала об этом примерно каждому человеку, включая незнакомцев в метро. Вместо того, чтобы задуматься, почему никто массово не делает rss-ридеры (ответ в следующем посте), решила, что пора пилить свой. На это дело я подбила двух кофаундеров: Антона Толчанова, который взял на себя серверную часть и молодого друга-программиста Диму Красноухова, который тогда имел типичную восточноевропейскую проблему «мне уже 19, а я всё ещё ничего не добился».

В марте 2012 начали, я творчески переработала Google Reader, выкинув оттуда всё бесящее, в июне сделали первую бету на bootstrap, я разослала письма всей rss-тусовке друзей, они привели своих, а дальше началась история, которая до сих пор кажется мне невероятной.

За полгода мы выросли до 5000 пользователей, всё было дико интересно: Антон управлял серверами, провернув блестящую схему с провайдером Hetzner, Дима в одиночку пилил код. Игорь Косырев сделал удачную айдентику, которая прожила лет семь до чужого редизайна. Одной рукой я придумывала какие-то продуктовые решения и рисовала кнопки, другой растила аудиторию по своей же стратегии, третьей общалась с пользователями, а четвёртой строила какие-то связи с общественностью и медиа. Думать было некогда, а благодаря этой неуёмной энергии The Old Reader выглядел и вёл себя полноценным продуктом, а не усилиями трёх человек на коленках.

Через год Google закрывает свой продукт, мы попадаем в подборки альтернатив в медиа — от Wired до HuffPo, приходят десятки тысяч новых пользователей за первые сутки, через неделю их становится в сорок раз больше, управлять этим становится всё сложнее.

К тому моменту мы уже уехали в Дублин, к постоянному стрессу адаптации добавляется запрет заниматься проектом для Антона от юристов с работы (Facebook), визовые вопросы, мы меняем базу данных с MongoDB на Tokumx, каждый день что-то ломается, и сна в хорошую ночь становится четыре часа.

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

У нас реально случайно вышло построить продукт на полмиллиона пользователей, который живёт вот уже десятый год. Каждый раз, когда у меня спрашивают, как, я стабильно отвечаю: «да чёрт его знает».

2013 год, мы ещё улыбаемся на фотографиях.

А никто не делает rss-ридеры вот почему: это проект для ботанов, который всё время только сохраняет и сохраняет весь интернет на серверы, а ваши пользователи будут требовать работать как Google.

Оказывается, это дорого и сложно, вот почему.

Были и классные моменты: вместо мобильного клиента, который мы себе не могли позволить, открыли API и наблюдали, как другие люди выкатывают два десятка клиентов для часов, windows-планшетов и телефонов nokia, и вот наш ридер становится экосистемой.

Прекрасное продуктовое решение.

Metaphors we build by

Всё — метафора. Больше об этом рассказывает классическая книга Лакоффа и Джонсона Metaphors We Live By. Немного завидую друзьям, которые прочитали её в четырнадцать — сама только на прошлой неделе осилила.

Метафора — один из базовых механизмов для понимания мира, включая физическую и социальную составляющие всего вокруг. До меня как-то важность метафор в дисциплине раньше не доходила и была скорее исторической, но в марте, когда я собирала сложный B2B2C продукт, до меня наконец-то дошло, что метафоры напрямую связаны с продуктовыми решениями.

Мы и здесь строим на метафорах, формирующих восприятие и действия.

Метафоры сопровождают интерфейсы с конца шестидесятых. Тогда Энгельбарт показал радикально новую систему для организации электронной работы: интерфейс, в котором текст и графика управляются контроллером, переходящим по страницам. Это была, конечно же, мышка.

В восьмидесятые с персональными компьютерами появился новый набор проблем и задач — как "перевести" интерфейсы для новой категории простых пользователей (раньше это были эксперты и учёные)? Большинство цифровых метафор — эволюция старых, традиционных, почти доисторических: «навигация» пришла из судоходства, «browsing» — посещение библиотеки. А вот метафора рабочего стола была полезной тридцать лет назад, а сейчас держит нас в прошлом.

Были и другие ошибочные метафоры: компьютеры не работают как мозги, и наоборот тоже не работает. (Одна из самых интересных теорий: ЭНИАК был смоделирован соответственно тогдашним представлениям об устройстве мозга, что повлияло и на железо, и на программы, и на развитие кибернетики). Отдельно проблем добавили бихеивористы, когнитивные аналитические модели вроде Model Human Processor, и то, что памятью в компьютерах называется "короткое", а не "длинное" хранение информации.

Метафоры сейчас напрямую показывают ментальные модели и продуктовые решения, от обещания (оно же — "поиск product-market fit") до деталей конкретных интерфейсов. Допустим, product-market fit — это создание максимальной ценности для минимального количества людей, чтобы потом выехать на "сетевых эффектах". В этом случае процесс начнётся с изучения ментальных моделей чтобы понять драйверы ценности, их измерения и оптимизации. Модели описывают существующие и новые поведения и описывают интерфейс как диалог через метафоры, глаголы и существительные.

Существуй закон Конвэя для продуктовых решений, выглядел бы он так:

продукт, который вы делаете, всегда будет отражать понимание пользовательского пространства.

Мысль не моя, но только сейчас дошла нормально.

​Одна из моих любимых статей этого года из Nature чем-то похожа на спецвыпуск передач «Оч.умелые ручки» и «Что? Где? Когда?». Людям предлагали поменять Lego-структуру из колонны и крыши, прикреплённой к ней одним блочком в углу. Как вы поставите новый кирпич наверх, чтобы человека не убило? А, каждая новая деталь стоит 10 центов, потому что капитализм.

Если вы подумали про дополнительные подпорки — поздравляю, вы совпадаете с большинством участников. Но проще (и дешевле!) было бы убрать подпорочку и оставить крышу на широкой колонне. При этом, когда участникам напоминали, что детальки можно не только добавлять, или давали время нормально подумать, решений через удаление становилось больше.

Серией похожих дурацких экспериментов в таком же духе авторы приходят к выводу:при решении проблем люди постоянно выбирают добавлять элементы, а не убирать их; и выводят теорию, которая описывает таким образом ежедневное принятие решений.

Это значит, что, когда мы думаем, делаем или строим продукты, надо помнить, что дефолтной стратегией изменений будет «Что бы нам сюда добавить». Поэтому, во-первых, надо сразу оптимизировать под быстродействие взаимодействий (всё равно понапредлагают добавить вяской фигни). А во-вторых, как и с другими когнитивными искажениями, надо надо сознательно искать идеи удаления.

Так я с гордостью могу сказать, что мой обычный подход к UI-процессу становится практически долгом:

1. Выписать в список элементы или целые функции
2. Удалять их очереди (важно: не все сразу)
3. Наблюдать, заметят ли или прокатит

Про продуктовые решения

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

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

На радикально разных проектах — благотворительный фонд, сайт очень вкусных молочных продуктов и ультрабогатый приватный банкинг — наблюдаю новую итерацию клиентских ожиданий за три года. Сейчас туда входит и продуктовый менеджмент в разной форме и стадиях жизненного цикла.

Во-первых, мне надо было понять, как и почему принимались решения в прошлом и сейчас. Вместо озвучивания внутреннего голоса «да что здесь происходит вообще?», начинаю с «помогите мне понять...»

- ...Как вы выбрали эту фичу?
- Из чего выбирали, какие рассматривали альтернативы и как это решение приоритизировали?
- Что здесь оптимизируется? (вот это вообще царь-вопрос)
- Какие ожидания после запуска?
- Сколько времени у вас на самом деле заняло всё сделать?
- Как сильно вы были неправы или правы? Почему?

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

Выглядит это так — показывая на каждый элемент на макете дизайнерам и девелоперам, задаю 4 вопроса:

- Откуда это берётся?
- Сколько состояний у этого?
- Что происходит в каждом из состояний?
- Что случается, когда состояние меняется?

Не могу сказать, что я лично в восторге от этой новой реальности — «продуктизацию» исследований считаю одной из больших проблем дизайн-команд. А ещё держу зуб за переупаковку традиционных HCI-инструментов и подачу этого как эффективные инновации в продуктовом мышлении (jbtd или вот так называемый custdev). Но покорно двигаю метрики и продолжаю задалбывать команды вопросами.

У меня сегодня опять день рождения, и по традиции я приношу хороший подарок всем нам — и это недельный бесплатный курс мистера Спула про досадно болезненные части исследовательской работы — как завоёвывать влияние и сделать так, чтобы вас уже послушали, поверили, купили и строить внятные роадмапы. Начинается 13 сентября, видео выходят каждый день.

https://aatur.uie.com

Спасибо, что читаете канал и оставляете очень хорошие заметки в форме, я на всё отвечу (просто скорость ответа либо 30 секунд, либо 10 рабочих дней). В комментариях устраиваю юбилейный отчёт про все интересы, а ещё AMA.