Мы все знаем IDEO, но не все видели их прекрасный и информативный раздел со всевозможными методами исследований в процессе разработки продукта/дизайна. Очень рекомендую: http://www.designkit.org/methods

Всем чмоки 🙂

Design Thinking сегодня, как секс среди подростков 🤐 или digital 10 лет назад - все говорят, никто не делает. В общем, один прекрасный парень объединил несколько известных подходов: Double Diamond от британской школы дизайна, Human-Centered Design от IDEO и, собственно, Design Thinking.

Я бы не сказал, что получилось слишком просто🤖, но раз уж эту неделю я посвятил данной теме, будет грешно не поделиться: https://medium.com/digital-experience-design/how-to-apply-a-design-thinking-hcd-ux-or-any-creative-process-from-scratch-b8786efbf812

Неплохой способ увидеть все три методологии в одном месте и попробовать уловить их суть.

И раз уж мы говорим о юзабилити - не забываем, что в Shared Media этого канала вы можете удобно видеть список всех ссылок и файлов:

Классный анализ упущенных перспектив Trello на фоне их недавней продажи за $425 млн компании Atlassian (создателям JIRA /Confluence).

Анализ от Hiten Shah, фаундера KISSmetrics, фокусируется на нескольких ключевых возможностях Trello:

1. Начать монетизироваться раньше. Trello были сильно сфокусированы на расширении базы free пользователей - и она у них была намного больше, чем у Dropbox в тот же период (10 млн юзеров через 3 года после запуска против 4 млн у Dropbox).

2. Дать более явные выгоды от платной подписки. Набор эмоджи и кастомные бэкграунды досок - явно не то, что стоит дополнительных затрат (для сравнения тот же Dropbox Professional, которым я пользуюсь не один год, увеличивает объём диска с 2 Гб до 1 Тб - то есть, в 50 раз).

3. Раньше задуматься о малом бизнесе. SMB ждали понятных предложений и прайсинга, но и здесь Trello потерпели неудачу. Как горизонтальное решение, они боялись сузиться до конкретной ниши/ниш, делать отдельные лендинги и фичи под сегменты рынка, в итоге бизнесы не получили ожидаемой пользы, коммуникация была размыта, а прайсинг не отражал реального использования продукта внутри компании.

4. Делать интеграции - раньше и больше. Яркий пример - управление issues из Github внутри Трелло. Эта возможность была упущена, а технология быстро синхронизируемой канбан-доски уже перестала быть недостижимой. В итоге Github сделал это сам.

5. Делать продукт для Enterprise. Хотя Trello и заявили о стратегии выхода в энтерпрайз через год после запуска, их стратегия была наивной: "Мы приходим в компанию и говорим: у вас 2000 человек пользуется Трелло, не хотите поговорить об этом?".
Да, возможно и пользуются, го это отдельные департаменты, отдельные доски. Это очень далеко от единой системы записей и уж тем более от бизнес-процессов и workflow (что в базовом виде хорошо реализовано в той же JIRA от Atlassian).

Полная история - по ссылке: https://blog.usejournal.com/why-trello-failed-to-build-a-1-billion-business-e1579511d5dc

Интересных вам выходных! 🤓

Продолжаю делиться любимыми блогами.

Сегодня попался замечательный пост с верхнеуровневым обзором самых важных вещей при разработке продукта. Начал делать саммари на русском для вас (и для себя), в итоге получилось чуть больше, чем ожидал - а это говорит о том, что пост был наполнен смыслом 😉 Сделал вам Medium-пост на русском.

Если на этой неделе вы планируете прочитать один пост, то стоит почитать именно этот - в оригинале или в моем вольном переводе.

Итак, вице-президент Facebook по продуктовому дизайну (Julie Zhuo) отвечает на вопрос: «Как разработать полезный продукт с ноля».

https://medium.com/@mishanestor/как-разработать-полезный-продукт-с-ноля-378536be35eb

Неплохой гайд по составлению роадмапов и "продаже" их стейкхолдерам от ProductPlan.com . Сам софт мне с первого раза не зашел, но намерен тестировать далее, напишу по результатам.

Objectives and Key Results  - методология постановки целей от Google, которая учитывает острую потребность гармонизировать потребности/стратегию организации и личные цели/амбиции каждого сотрудника.

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

5-минутный обзор 80-минутного воркшопа  - ниже по ссылке. Автор воркшопа для портфельных компаний Гугла - бывший продакт-менеджер blogger.com (третий по траффику бизнес Google), а сейчас - партнер в GV (Google Ventures).

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

https://medium.com/@mishanestor/objectives-and-key-results-методология-постановки-целей-от-google-aa3cba5e763b

«Все заняты» - это НЕ стратегия приоритезации.

Постоянное обучение и улучшение должны быть встроены в рабочий процесс команды.

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

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

🕹Решение:

Командами нужно управлять по результатам (outcomes), а не количеству написанного кода. Результаты - это измеряемое поведение клиентов.

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

🏋️‍♀️ Как это работает:

Ожидаемые результаты (outcomes) работают как фильтры.

Каждая новая задача должна пройти через анализ по двум непростым пунктам:

* Как эта идея поможет нам достичь желаемого поведения клиентов (customer behavior)?
* Почему эта идея выглядит более привлекательно, чем другие идеи, над которым мы сейчас работаем?

Если идея, независимо от того, насколько она драйвит или кто ее автор (читай: топ-менеджер), не согласуется с ожидаемыми целями команды в терминах поведения клиентов/пользователей, у вас есть прозрачный, объективный способ сказать «НЕТ»😾

Оригинал поста от автора LEAN UX на англ.: https://medium.com/@jboogie/everyone-is-too-busy-is-not-a-prioritization-strategy-45ac4d525ab5

Используя код - elevatedesign - вы можете получить доступ к просмотру фильма Design Disruptors от InVision (https://www.designdisruptors.com). В создании фильма приняли участие представители ведущих технологических компаний мира - от Head of Design Dropbox до VP Product Design Facebook. Фильм сделан очень качественно.

Не так много фильмов о продуктовом дизайне есть в принципе. Прекрасное занятия для воскресного вечера 😉

Ссылка на просмотр: https://www.designdisruptors.com/priority-access

Сегодня некоторым товарищам я обещал выложить еще материалов по UX/UI.
У меня есть несколько самых любимых системных описаний темы, сегодня выложу одно из них, на днях - следующее. Поскольку вчера мы сомтрели фильм, спонсором которого выступил InVision (см предыдущий пост), то и начнем мы с их ресурса DesignBetter. Ниже ссылки на 4 прекрасные интерактивные книги, с врезками из видео, аудио комментариев ведущих специалистов, ссылками на полезные материалы, в общем - настоящее сокровище, не на один вечер/день. Итак:

1. Principles of Product Design от InVision: https://www.designbetter.co/principles-of-product-design

2. Design Thinking Handbook: https://www.designbetter.co/design-thinking

3. Design Leadership Handbook: https://www.designbetter.co/design-leadership-handbook

4. Design Systems Handbook: https://www.designbetter.co/design-systems-handbook

В принципе, уже неделю можно ничего не писать 😉 Но есть еще один кладезь ресурсов по UX/UI, и уже после него с этой темой можно будет сделать паузу, и делиться материалами по другим аспектам Product Development.

Atomic Design - одна из популярных методологий UI/UX дизайна, предполагающая работу с компонентами интерфейса на разных уровнях - от сайта до кнопки.

Популярность методологии вызвана тем, что она позволяет реиспользовать и миксовать разные компоненты и блоки, при этом обеспечивать единое ощущение и целостность UX.

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

⭐️⭐️⭐️ http://atomicdesign.bradfrost.com/table-of-contents/

Если вы все еще не верите, что это важно и полезно, вот несколько публикаций об этой методологии:

1. 10 reasons you should be using Atomic Design: http://www.creativebloq.com/web-design/10-reasons-you-should-be-using-atomic-design-61620771

2. Atomic design: how to design systems of components: https://uxdesign.cc/atomic-design-how-to-design-systems-of-components-ab41f24f260e

3. Brad Frost: Atomic Design - видео от автора: https://vimeo.com/109130093

Почему я пишу о системах UI и почему такой акцент на UX? Во-первых, это очевидно - сложно делать продукт, не разбираясь в эих темах. Даже если у вас в команде замечательные дизайнеры, логику интерфейсов важно понимать (и часто прототипировать) самим. Во-вторых, важно быть способным оценить решения, которые вам предлагают. В-третьих, это просто очень интересно, ведь дизайн в разработке софтовых продутов - это не картинки в фотошопе/иллюстраторе, а прежде всего логика и experience.

Попался замечательный канал с массой видео от авторов и продактов из крупнейших технологических кампаний. Все бесплатно, но на английском (но без англ в этой сфере нечего делать в принципе):
https://www.youtube.com/channel/UC6hlQ0x6kPbAGjYkoz53cvA

Для примера - видео от Head of Product о ее десятилетнем опыте запуска продуктов в Amazon:

https://youtu.be/4BPUMsDdR0c
(не забывайте смотреть описания видео - там основные пункты и ссылки на слайды)

Перестаньте играть в Тетрис (в разработке продукта) 🤹‍♀️

На прошлой неделе я делился замечательной цитатой:
«If Tetris has taught me anything it's that errors pile up and accomplishments disappear»

Я сделал саммари оригинального поста с некоторыми рефлексиями из собственного опыта (здесь: https://medium.com/@mishanestor/перестаньте-играть-в-тетрис-в-разработке-продукта-a89cb55bb681 ).
О чем же идет речь?

КТО ВИНОВАТ?

Несколько признаков того, что вы играете в тетрис в своей работе РМ:

1. Докинуть несколько маленьких историй в спринт, чтоб дать всем ощущение инкремента и скорости в разработке. 🎰
2. Ориентироваться на то, чтоб все выглядели занятыми, независимо от влияния на бизнес-результаты и эффективность/комфорт работы команды. 🚣‍♀️
3. Попытки планировать на год/квартал с участием топ-менеджмента, которые выглядят как «а как бы нам этот паззл собрать так, чтоб побольше впихнуть в квартал» 🤞
4. Просить другие функции (напр., UX) делать работу «впрок», что приводит к неадекватным зависимостям и блокирует полезные улучшения в продукте. 🤦‍♂️
5. Никогда не возвращаться чтоб фиксить дырки в продукте. Приводит к тому, что коллективное бессознательное команды погружается в грусть и фрустрацию. 🧟‍♂️
...

ЧТО ДЕЛАТЬ?

(в посте по ссылке⬇️)

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

https://bangbangeducation.ru/talks

Интересный список инструментов для продакт-менеджера, собранный по нескольким категориям:

* Product Roadmapping
* Project Management
* Product Research
* Wireframing/Specs
* Analytics
* User Experience
* Landing Pages
* Email Marketing
* Design & User Interface
* Stock Photos & Videos

Список небольшой, но лично я не люблю мега-каталоги из 100+ инструментов, там легко потеряться и пропустить что-то действительно интересное - например, https://thenounproject.com (всевозможные иконки на любой случай жизни), или http://emptystat.es (Empty States, идеи для пустых экранов в ваших приложениях ! 😉 )


https://www.aha.io/roadmapping/guide/product-management/which-tools-do-product-managers-use

Говорят (спасибо, Женя!), ссылка из последнего поста об инструментах не всем видна, вот она ещё раз:
https://www.aha.io/roadmapping/guide/product-management/which-tools-do-product-managers-use

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

Роадмаппинг здорового человека

"Roadmaps should be lists of questions, not lists of features"

Парадоксальную вещь напишу. Если вы время от времени думаете: “а запишу-ка я себе заново вот самые срочные доработки/улучшения в продукте, которые вот нужно сделать совсем в следующем спринте”, и у вас получится список на 6 месяцев - значит, все хорошо. Ну в самом деле. Это значит, что вы думаете о вечном (зачеркнуто) о важном, и знаете чего от вас ждут пользователи/бизнес. И главное, у вас есть простор для полезных упражнений по приоритезации. Ограничения ресурсов есть везде - будь вы стартап, энтерпрайз с миллионами долларов дохода, или Google.

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

Одна из самых полезных вещей, которые быстро можно сделать (кроме сортировки по принципу business value vs. оценка времени на разработку, конечно) - это:
1. Взять свой роадмап на период (квартал, полгода, год, просто набор самых важных фич которые вам “очень нужно” произвести)
2. Убрать из него таймлайн и любые привязки ко времени (комитменты, запросы от клиентов, обещания стейкхолдерам..)
3. По каждому эпику/истории/фиче задать себе один из двух вопросов (на выбор, с чем вам в данный момент комфортнее работать):
* Зачем мы это делаем? Как это облегчит жизнь нашему пользователю (клиенту, сейлзам, CSM, - но первично все же юзеру)?
* Если мы реализуем эту фичу в самом офигезно идеальном виде, как мы об этом узнаем? (подсказка: метрики).

Поскольку с “зачем” нам все же проще (специфика, в которую здесь вдаваться не буду), мы по каждому эпику написали список метрик, по которым мы явно можем отследить влияние (impact) нашей работы на жизнь живых пользователей. Например, уменьшится количество инцидентов/обращений по этому блоку функционала, увеличится количество создаваемых сущностей в этом разделе, снизится время на онбординг новых пользователей, снизятся затраты на поддержку вот этой фичи, увеличится доход с вот этого типа лицензий и т.д. У вас это могут быть метрики, характерные вашему продукту и бизнесу.

Самое главное - они легко рождаются в процессе таких размышлений. Сам процесс выглядит незатейливо: если у вас есть продуктовая команда, возьмите список фич и каждый отдельно выпишите по ним на стикеры свои метрики/признаки. Потом сравните ваши идеи, объедините их в кластеры, обсудите. Итоги впишите в документ (Confluence, GoogleDoc..).

Что интересно - на первый взгляд это мало связано с приоритетами, но на самом деле нет. Как только вы думаете о метриках, вы автоматически начинаете думать о пользовательском поведении и его изменении в результате вашей работы. Это очень тонкий момент, и очень продуктивный способ начать думать именно в таком ключе (не говоря уже о том, что вы получаете субпродукт в виде метрик, по которым можете впоследствии отслеживать эффективность/целесообразность внедрения функционала и улучшений (все же вы могли ошибаться, и это тоже бывает: build-measure-learn цикл никто не отменял).

Как только вы начинаете думать о поведении пользователей, вы можете увидеть новые способы удовлетворить их потребности, или же несколько фич, направленные на решение одной и той же проблемы. В последнем случае вы можете от чего-то отказаться, или напротив - объединить несколько эпиков в один и сэкономить на оверхэдах в виде кик-офф презентаций, сдаче эпиков по Definition of Done, нагрзочному тестированию и т.п. Последний вариант звучит не очень lean, но вы можете быть уже далеко позади стадии поиска product-market fit, и искать способы оптимизации.

Пост, который меня вдохновил вспомнить об этом полезном занятии как раз перед каникулами: https://medium.com/@jboogie/roadmaps-are-linear-software-projects-arent-e50fb142036f

Желаю вам продуктивного подведения итогов и разумного взвешенного планирования - с вашими пользователями в уме 😉