olena requires more research

У меня сегодня опять день рождения, и по традиции я приношу хороший подарок всем нам — и это недельный бесплатный курс мистера Спула про досадно болезненные части исследовательской работы — как завоёвывать влияние и сделать так, чтобы вас уже послушали, поверили, купили и строить внятные роадмапы. Начинается 13 сентября, видео выходят каждый день. https://aatur.uie.comСпасибо, что читаете канал и оставляете очень хорошие заметки в форме, я на всё отвечу (просто скорость ответа либо 30 секунд, либо 10 рабочих дней). В комментариях устраиваю юбилейный отчёт про все интересы, а ещё AMA.

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

​Одна из моих любимых статей этого года из Nature чем-то похожа на спецвыпуск передач «Оч.умелые ручки» и «Что? Где? Когда?». Людям предлагали поменять Lego-структуру из колонны и крыши, прикреплённой к ней одним блочком в углу. Как вы поставите новый кирпич наверх, чтобы человека не убило? А, каждая новая деталь стоит 10 центов, потому что капитализм.Если вы подумали про дополнительные подпорки — поздравляю, вы совпадаете с большинством участников. Но проще (и дешевле!) было бы убрать подпорочку и оставить крышу на широкой колонне. При этом, когда участникам напоминали, что детальки можно не только добавлять, или давали время нормально подумать, решений через удаление становилось больше. Серией похожих дурацких экспериментов в таком же духе авторы приходят к выводу:при решении проблем люди постоянно выбирают добавлять элементы, а не убирать их; и выводят теорию, которая описывает таким образом ежедневное принятие решений. Это значит, что, когда мы думаем, делаем или строим продукты, надо помнить, что дефолтной стратегией изменений будет «Что бы нам сюда добавить». Поэтому, во-первых, надо сразу оптимизировать под быстродействие взаимодействий (всё равно понапредлагают добавить вяской фигни). А во-вторых, как и с другими когнитивными искажениями, надо надо сознательно искать идеи удаления. Так я с гордостью могу сказать, что мой обычный подход к UI-процессу становится практически долгом: 1. Выписать в список элементы или целые функции2. Удалять их очереди (важно: не все сразу)3. Наблюдать, заметят ли или прокатит

Metaphors we build byВсё — метафора. Больше об этом рассказывает классическая книга Лакоффа и Джонсона Metaphors We Live By. Немного завидую друзьям, которые прочитали её в четырнадцать — сама только на прошлой неделе осилила.Метафора — один из базовых механизмов для понимания мира, включая физическую и социальную составляющие всего вокруг. До меня как-то важность метафор в дисциплине раньше не доходила и была скорее исторической, но в марте, когда я собирала сложный B2B2C продукт, до меня наконец-то дошло, что метафоры напрямую связаны с продуктовыми решениями.Мы и здесь строим на метафорах, формирующих восприятие и действия.Метафоры сопровождают интерфейсы с конца шестидесятых. Тогда Энгельбарт показал радикально новую систему для организации электронной работы: интерфейс, в котором текст и графика управляются контроллером, переходящим по страницам. Это была, конечно же, мышка.В восьмидесятые с персональными компьютерами появился новый набор проблем и задач — как "перевести" интерфейсы для новой категории простых пользователей (раньше это были эксперты и учёные)? Большинство цифровых метафор — эволюция старых, традиционных, почти доисторических: «навигация» пришла из судоходства, «browsing» — посещение библиотеки. А вот метафора рабочего стола была полезной тридцать лет назад, а сейчас держит нас в прошлом.Были и другие ошибочные метафоры: компьютеры не работают как мозги, и наоборот тоже не работает. (Одна из самых интересных теорий: ЭНИАК был смоделирован соответственно тогдашним представлениям об устройстве мозга, что повлияло и на железо, и на программы, и на развитие кибернетики). Отдельно проблем добавили бихеивористы, когнитивные аналитические модели вроде Model Human Processor, и то, что памятью в компьютерах называется "короткое", а не "длинное" хранение информации.Метафоры сейчас напрямую показывают ментальные модели и продуктовые решения, от обещания (оно же — "поиск product-market fit") до деталей конкретных интерфейсов. Допустим, product-market fit —

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

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

Старый ридер навсегдаПервого июля 2013 года Google Reader перестал существовать навсегда. В этом году мы живём в мире без него больше, чем с ним.Сегодня я особенно сентиментальна, потому что я сразу иду открывать The Old Reader — собственный первый большой продукт, который получилось сделать командой из трёх человек. Сейчас ему идёт десятый год жизни.Возможно, вы столько лет в интернете, что помните Google удаливший комментарии из своего rss-ридера. Я лично три месяца сообщала об этом примерно каждому человеку, включая незнакомцев в метро. Вместо того, чтобы задуматься, почему никто массово не делает rss-ридеры (ответ в следующем посте), решила, что пора пилить свой. На это дело я подбила двух кофаундеров: Антона Толчанова, который взял на себя серверную часть и молодого друга-программиста Диму Красноухова, который тогда имел типичную восточноевропейскую проблему «мне уже 19, а я всё ещё ничего не добился». В марте 2012 начали, я творчески переработала Google Reader, выкинув оттуда всё бесящее, в июне сделали первую бету на bootstrap, я разослала письма всей rss-тусовке друзей, они привели своих, а дальше началась история, которая до сих пор кажется мне невероятной. За полгода мы выросли до 5000 пользователей, всё было дико интересно: Антон управлял серверами, провернув блестящую схему с провайдером Hetzner, Дима в одиночку пилил код. Игорь Косырев сделал удачную айдентику, которая прожила лет семь до чужого редизайна. Одной рукой я придумывала какие-то продуктовые решения и рисовала кнопки, другой растила аудиторию по своей же стратегии, третьей общалась с пользователями, а четвёртой строила какие-то связи с общественностью и медиа. Думать было некогда, а благодаря этой неуёмной энергии The Old Reader выглядел и вёл себя полноценным продуктом, а не усилиями трёх человек на коленках. Через год Google закрывает свой продукт, мы попадаем в подборки альтернатив в медиа — от Wired до HuffPo, приходят десятки тысяч новых пользователей за первые сутки, через неделю их ст

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

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

Препятствие 1: игнорирование информационной архитектуры и моделей поведенияКоманды и организации, работают над продуктами и экосистемами, талантливые профессионалы создают свои курсы и транслируют практику, но информационной архитектуре в этом поле как будто либо нет места, либо уделяется номинальное внимание, без должного акцента на её ценность и важность. Информационная архитектура лежит в ДНК любого сильного продукта и системное мышление невозможно без её понимания. А мы, кстати, только системы и разрабатываем. Это не просто классическая фишка из восьмидесятых, её не вывели когнитивные психологи или ребята из Xerox PARC. Эта практика древнее языка — поиск смысла и упорядочивание мира пришли к нам с ранними периодами человечества, и уж точно древнее технологий. Возможно, поэтому те, у кого информационная архитектура вшита в процесс поиска решений, не выделяют её отдельно.Проблема в том, что большинство команд обычно не имеют достаточных процессов системного мышления и осознанный дизайн систем и моделей — скорее исключение, чем правило. Так растёт UX-долг и технический долг, так мы получаем (и сами делаем) хаотичные роадмапы без ключевых структур, которые просто упустить с драматическими последствиями.