Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
Про ИА. Визуальные сценарии и объекто-информационная модель.Nikita Efimov
- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
Про ИА. Визуальные сценарии и объекто-информационная модель.Nikita Efimov
- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
У семи нянек дитя без глаза? Пара лет проблем и решений в UX зарубежного веб-...ПрофсоUX
Доклад рассчитан на создателей и руководителей продуктовых команд, проектировщиков, дизайнеров. Разработчикам тоже может быть интересно.
Последние два года я работаю в довольно интересном веб-сервисе. Хочу поделиться кейсами из опыта.
Как быть, когда в вашем портфеле несколько продуктов, каждый продукт развивает отдельный юзабилити-специалист, и у подразделения нет начальника?
Что делать, если каждым из этих продуктов пользуются «немного разные» люди, а навигация общая? (и вообще, продукты живут в едином веб-сервисе и должны между собой как-то дружить)
Как договориться, если все эти продукты — часть единого большого веб-сервиса с кучей общих мест?
Как решать общие проблемы?
Как синхронизироваться и быстрее внедрять лучшие решения из опыта коллег?
Как вообще работать без «арт-директора», «менеджера проекта» или другого начальника?
Как и когда использовать айтрекер на юзабилити тестированииПрофсоUX
Доклад ориентирован на юзабилити исследователей, которые открыты к новым знаниям, и их не устраивает уровень данных, которые они получают сейчас. Так же доклад будет полезен руководителям проектов и дизайнерам, которые хотят повысить показатели в своих проектах, но не догадываются как это можно сделать с помощью юзабилити тестирования.
В последнее время технология айтрекинга стала доступне. Уже за 99 долларов можно купить не дорой айтрекер. И почти у каждого возникает проблема, как его использовать после покупки. Что означают эти точки и что с ними можно делать. Я расскажу, как использую я.
Хитрости UX-дизайна: ключевые лайфхаки, которые должен знать разработчикNick Grachov
UX-design: main life hacks every engineer should know
Nick explained how beautiful design can be even worse than ugly one and explain:
• what is UX and where is its place in the design
• what is the difference between usability and UX
• what are the levels and stages of the UX
• what tools and techniques are used in the UX
У семи нянек дитя без глаза? Пара лет проблем и решений в UX зарубежного веб-...ПрофсоUX
Доклад рассчитан на создателей и руководителей продуктовых команд, проектировщиков, дизайнеров. Разработчикам тоже может быть интересно.
Последние два года я работаю в довольно интересном веб-сервисе. Хочу поделиться кейсами из опыта.
Как быть, когда в вашем портфеле несколько продуктов, каждый продукт развивает отдельный юзабилити-специалист, и у подразделения нет начальника?
Что делать, если каждым из этих продуктов пользуются «немного разные» люди, а навигация общая? (и вообще, продукты живут в едином веб-сервисе и должны между собой как-то дружить)
Как договориться, если все эти продукты — часть единого большого веб-сервиса с кучей общих мест?
Как решать общие проблемы?
Как синхронизироваться и быстрее внедрять лучшие решения из опыта коллег?
Как вообще работать без «арт-директора», «менеджера проекта» или другого начальника?
Как и когда использовать айтрекер на юзабилити тестированииПрофсоUX
Доклад ориентирован на юзабилити исследователей, которые открыты к новым знаниям, и их не устраивает уровень данных, которые они получают сейчас. Так же доклад будет полезен руководителям проектов и дизайнерам, которые хотят повысить показатели в своих проектах, но не догадываются как это можно сделать с помощью юзабилити тестирования.
В последнее время технология айтрекинга стала доступне. Уже за 99 долларов можно купить не дорой айтрекер. И почти у каждого возникает проблема, как его использовать после покупки. Что означают эти точки и что с ними можно делать. Я расскажу, как использую я.
Хитрости UX-дизайна: ключевые лайфхаки, которые должен знать разработчикNick Grachov
UX-design: main life hacks every engineer should know
Nick explained how beautiful design can be even worse than ugly one and explain:
• what is UX and where is its place in the design
• what is the difference between usability and UX
• what are the levels and stages of the UX
• what tools and techniques are used in the UX
"Пользователи: сигнал из космоса". CodeFest mini 2012Michael Karpov
О способах получения обратной связи от пользователей в российских и иностранных интернет-компаниях.
Также, на основе различных жизненных кейсов рассмотрим их полезность и применимость.
Михаил рассмотрит основные случаи и всякие примеры применения на основе Яндекса и нескольких других российских и иностранных компаний.
Impact Map & Feature Canvas. Как держать фокус на целях при внедрении новых фич.Nikita Efimov
Доклад с Growth Business Forum '18.
Если в вашей компании ставятся амбициозные квартальные (или другие) цели: OKR, SMART, KPI, но нет понимания, как функциональность связана с целями, как контролировать достижение целей, как валидировать идеи по улучшению продуктов до проработки и как не тратить время и силы на никому ненужную функциональность.
Инструменты Feature Canvas и Impact Mapping не решат всех проблем с продуктом или бизнесом, но помогут начать договариваться, обоснованно говорить "нет" всем хотелкам и "крутым" идеям.
Feature Сanvas. С чего начать работу над новой идеей.Nikita Efimov
Доклад с ProductSense'18 Moscow.
Feature Canvas может помочь:
- Дольше оставаться в области проблем перед тем, как вы начнёте прорабатывать конкретное решение.
- Синхронизироваться со всей командой (чтобы все были на одной волне) об идеи, причинах её реализации и всего, что находится в области проблем.
- Увидеть "белые пятна" в вашем понимании контекста проблемы и пользователей. И подготовиться к исследованиям.
- Помогать контролировать себя ("А не забыл(-а) ли я чего-нибудь?") перед тем, как включить режим "Чик-чик и в продакшен".
3 способа проверки гипотез, когда у вас ещё ничего нетNikita Efimov
Доклад в рамках ProductConnect, Minsk.
Рассказал про 3 способа проверки гипотез о фичах/решениях на той стадии, когда вы ещё даже не сделали прототипа:
- модель Кано
- карточная сортировка
- интервью о решении с пользователями
Информационные персоны (как люди ищут информацию)Nikita Efimov
Очередной доклад про персон-шмерсон? В какой-то степени...
Ведь, к сожалению, часто персоны просто придумывают. Причём эти "придумки" касаются цвета глаз Марины или имени её кота, что никаким образом не относится к проектируемой системе. Все становится ещё хуже, когда проектируют сложные информационные системы.
В докладе я хочу рассмотреть подход, который часто использую для проектирования сложных (с точки зрения информационной архитектуры) систем. Ведь в таких системах люди обрабатывают большое количество информации: ищут что-то новое, взаимодействуют с найденным, возвращаются к старому.
И каждый раз их поведение может меняться в зависимости от разных факторов:
от той информации, которую они ищут;
от того, какой информацией обладают на данный момент;
от того, что хотят с этой информацией сделать в дальнейшем.
Для себя я выделяю несколько состояний человека (как я их называю - режимы поиска), в котором он может находится. И на основании этих режимов прорабатываю типичных представителей и их взаимодействие с системой.
В докладе я подробно расскажу про эти "магические" режимы поиска, и как на основании этих данных я создаю информационных персон. Ну и, конечно, я расскажу про инструменты, которые мне помогают эти информационные персоны создавать.
Многие agile-команды используют в своей работе user story. Это отличный и простой в понимании инструмент. Однако, как это часто бывает, нельзя просто так взять и применить инструмент и сразу добиться нужного результата: фичи, которые были придуманы почему-то оказываются не нужны пользователям. Но не потому, что они (фичи) плохо реализованы, а потому, что эти фичи не удовлетворяют пользовательским потребностям.
В докладе я расскажу про инструмент под названием «дизайн история». Это user story на UX-стероидах, другой взгляд на привычный для многих инструмент. Мы поговорим о том, на основании чего создавать дизайн историю (точнее, как модифицировать user story). И самое главное, как эту историю использовать в дальнейшем, как на основании ее генерировать идеи и фичи для реализации.
16. 1 Описание идеи
В 2-3 предложениях фиксируем описание идеи.
Не можем описать просто и понятно? И реализовать не сможем просто и
понятно.
17. 2 Проблема
• Какую проблему мы пытаемся решить?
Можем ли мы однозначно описать проблему?
• Откуда мы узнали об этой проблеме?
Исследования, отзывы, сами придумали выдвинули гипотезу и т.д.
• Как частно нам о ней сообщают?
Это было один раз или каждый день об этом пишут?
• Как давно эта проблема известна?
Может она уже устарела?
18. 3 Кого затрагивает
• Каких пользователей затрагивает эта проблема?
• Являются ли они основной ЦА в данный момент?
• Как часто они сталкиваются с данной проблемой?
Каждый раз при работе, периодически, раз в жизни и т.д.
• Насколько критичны последствия проблемы?
Блокирует работу, мешает эффективно работать, “мелочи жизни” и т.д.
• В какой момент времени возникает проблема?
Что происходит с пользователей в данный момент?
• В каком контексте возникает проблема?
19. 4 Текущее поведение
• Как пользователи сейчас решают данную проблему?
И решают ли вообще
• Какие альтернативные решения используют?
Есть ли у нас аналоги/конкуренты?
• Что их не устраивает в текущем варианте решения
проблемы?
20. 5 Ценность
• Какую ценность мы принесём пользователям?
• Почему люди захотят пользоваться предлагаемым
решением?
• Чем новое решение будет лучше их существующего
поведения?
22. 6 Цели бизнеса
• Какую ценность получит бизнес от реализации?
Почему для бизнеса важно это реализовать?
• Какие проблемы могут возникнуть, если не решить
данную проблему?
23. 7 Метрики
• Как мы поймем, что достигли успеха?
Что сумели донести ценность пользователям и решить их проблемы
• Какого типа данные/исследования нам нужны?
Качественные и/или количественные
27. 1 Задачи пользователей
• Какие задачи пользователи будут выполнять с новым
функционалом?
Как они это делают сейчас мы уже посмотрели
• Какие задачи будут наиболее частотны?
• Какие задачи будут наиболее важны?
28. 2 Осведомлённость
• Как люди узнают о появлении (или наличии) данного
функционала?
• Нужно ли нам что-то делать для этого?
Уведомления в интерфейсе, рассылки, реклама, публичные ресурсы и т.д.
29. 3 Помощь и поддержка
• Нужна ли помощь при работе?
Чтобы начать работу с функционалом, во время работы с функционалом
• Что это должна быть за помощь?
Контекстная помощь, какие-либо интерфейсные решения, новый раздел в
хелпе и т.д.
30. 4 Ограничения
Что нам может помешать или осложнить жизнь?
Люди, время, технологии, текущие интерфейсные решения, контекст, навыки
пользователей и т.д.
31. 5 Возможности
Что нам может помочь или упростить жизнь?
Люди, время, технологии, текущие интерфейсные решения, контекст, навыки
пользователей и т.д.
32. 6 Ключевые активности
Что в итоге нужно сделать, чтобы донести до
пользователей обозначенную ценность?
33. 7 Ключевые ресурсы
• Кто и что нам нужно, чтобы всё это реализовать?
• Кого затрагивают ключевые активности?
35. Помогает
• Структурированно разбирать входящие идеи и хотелки;
• Не забывать важные детали при обсуждении;
• Подольше оставаться в “области проблем”;
• Отсеивать на раннем этапе ненужные (людям в первую
очередь) фичи;
• Фасилитировать командные обсуждения;
• Опираться при проектировании и разработке;