- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
Хитрости 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
Доклад рассчитан на создателей и руководителей продуктовых команд, проектировщиков, дизайнеров. Разработчикам тоже может быть интересно.
Последние два года я работаю в довольно интересном веб-сервисе. Хочу поделиться кейсами из опыта.
Как быть, когда в вашем портфеле несколько продуктов, каждый продукт развивает отдельный юзабилити-специалист, и у подразделения нет начальника?
Что делать, если каждым из этих продуктов пользуются «немного разные» люди, а навигация общая? (и вообще, продукты живут в едином веб-сервисе и должны между собой как-то дружить)
Как договориться, если все эти продукты — часть единого большого веб-сервиса с кучей общих мест?
Как решать общие проблемы?
Как синхронизироваться и быстрее внедрять лучшие решения из опыта коллег?
Как вообще работать без «арт-директора», «менеджера проекта» или другого начальника?
Никита Ефимов Lead UX Architect, New Cloud Technologies Anton Anokhin
"Унификация взаимодействия: как мы проектируем интерфейсы нескольких приложений в рамках единого продукта."
"В своём докладе мы расскажем про то, как работает наша дизайн-команда:
- как организован процесс внутри команды
- как мы взаимодействуем с командами разработки
- как проверяем качество итоговой реализации
- как мы внедряем ux-культуру внутри компании (первые шаги, набитые шишки и наша стратегия)
Также поделимся опытом того, как мы прорабатываем один функционал сразу на несколько платформ."
Как и когда использовать айтрекер на юзабилити тестированииПрофсоUX
Доклад ориентирован на юзабилити исследователей, которые открыты к новым знаниям, и их не устраивает уровень данных, которые они получают сейчас. Так же доклад будет полезен руководителям проектов и дизайнерам, которые хотят повысить показатели в своих проектах, но не догадываются как это можно сделать с помощью юзабилити тестирования.
В последнее время технология айтрекинга стала доступне. Уже за 99 долларов можно купить не дорой айтрекер. И почти у каждого возникает проблема, как его использовать после покупки. Что означают эти точки и что с ними можно делать. Я расскажу, как использую я.
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
Хитрости 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
Доклад рассчитан на создателей и руководителей продуктовых команд, проектировщиков, дизайнеров. Разработчикам тоже может быть интересно.
Последние два года я работаю в довольно интересном веб-сервисе. Хочу поделиться кейсами из опыта.
Как быть, когда в вашем портфеле несколько продуктов, каждый продукт развивает отдельный юзабилити-специалист, и у подразделения нет начальника?
Что делать, если каждым из этих продуктов пользуются «немного разные» люди, а навигация общая? (и вообще, продукты живут в едином веб-сервисе и должны между собой как-то дружить)
Как договориться, если все эти продукты — часть единого большого веб-сервиса с кучей общих мест?
Как решать общие проблемы?
Как синхронизироваться и быстрее внедрять лучшие решения из опыта коллег?
Как вообще работать без «арт-директора», «менеджера проекта» или другого начальника?
Никита Ефимов Lead UX Architect, New Cloud Technologies Anton Anokhin
"Унификация взаимодействия: как мы проектируем интерфейсы нескольких приложений в рамках единого продукта."
"В своём докладе мы расскажем про то, как работает наша дизайн-команда:
- как организован процесс внутри команды
- как мы взаимодействуем с командами разработки
- как проверяем качество итоговой реализации
- как мы внедряем ux-культуру внутри компании (первые шаги, набитые шишки и наша стратегия)
Также поделимся опытом того, как мы прорабатываем один функционал сразу на несколько платформ."
Как и когда использовать айтрекер на юзабилити тестированииПрофсоUX
Доклад ориентирован на юзабилити исследователей, которые открыты к новым знаниям, и их не устраивает уровень данных, которые они получают сейчас. Так же доклад будет полезен руководителям проектов и дизайнерам, которые хотят повысить показатели в своих проектах, но не догадываются как это можно сделать с помощью юзабилити тестирования.
В последнее время технология айтрекинга стала доступне. Уже за 99 долларов можно купить не дорой айтрекер. И почти у каждого возникает проблема, как его использовать после покупки. Что означают эти точки и что с ними можно делать. Я расскажу, как использую я.
Как правильно составить структуру сайта, Дмитрий Сатин, лекция в Школе вебмас...Yandex
Лекция Дмитрия Сатина в Школе вебмастеров: «Как правильно составить структуру сайта».
https://academy.yandex.ru/events/webmasters_school/yawebm2015/
Структура сайта, ориентированная на человека; построение структуры, карточная сортировка
Содержимое сайтов часто организовано так, как кажется удобным разработчику или контент-менеджеру компании. Чаще всего такие структуры неудобны для реальных посетителей, потому что не совпадают с их знаниями, не поясняют, как устроен материал, и не помогают найти желаемое. Структура, ориентированная на пользователя, повышает вероятность того, что посетители найдут нужную информацию или товар и сделают это быстро.
Стройте структуру, исходя из пользовательских сценариев. Выделение на сайте разделов, соответствующих структуре компании или схеме процесса закупки, как правило, усложняет навигацию для пользователя. Правильная структура учитывает уровень знаний покупателя и использует понятные ему термины и способы группировки.
Разные типы структур, средства навигации, дальнейший поиск информации на странице
Структуры сайтов, на которых ищут что-то определённое, отличаются от тех, что используются на сайтах, посетители которых ещё не уверены, что именно они хотят или как называется нужная вещь. Строгие структуры — например, организация по наименованию товара, производителю, — предполагают один способ группировки. При нестрогой организации данные можно группировать по теме, по жизненной ситуации и так далее. Используйте средства навигации, которые помогают понять, как организован материал. Решая, какой будет визуальная реализация навигации на сайте, необходимо учитывать количество разделов и связи �
Презентация с доклада на SPC UA 2012. Видео тут - http://sharepoint-channel.com/stanislav-vyshhepan-iskusstvo-upravleniya-sharepoint-kak-poluchit-maksimalnuyu-vygodu-dlya-biznesa-videozapis-doklada-na-spcua-2012
"Пользователи: сигнал из космоса". CodeFest mini 2012Michael Karpov
О способах получения обратной связи от пользователей в российских и иностранных интернет-компаниях.
Также, на основе различных жизненных кейсов рассмотрим их полезность и применимость.
Михаил рассмотрит основные случаи и всякие примеры применения на основе Яндекса и нескольких других российских и иностранных компаний.
Bitrix 24 - единое рабочее пространство для компании или отдела, которое повышает эффективность работы
и позволяет каждому из сотрудников стать успешнее
How to study your audience? End user researchEugene Kulakov
‘Media in Digital Environment: Challenges and Possibilities’, an international conference, Internews (Dushanbe, Tajikistan)
— ‘How to study your audience? End user research’
3 способа проверки гипотез, когда у вас ещё ничего нетNikita Efimov
Доклад в рамках ProductConnect, Minsk.
Рассказал про 3 способа проверки гипотез о фичах/решениях на той стадии, когда вы ещё даже не сделали прототипа:
- модель Кано
- карточная сортировка
- интервью о решении с пользователями
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 может помочь:
- Дольше оставаться в области проблем перед тем, как вы начнёте прорабатывать конкретное решение.
- Синхронизироваться со всей командой (чтобы все были на одной волне) об идеи, причинах её реализации и всего, что находится в области проблем.
- Увидеть "белые пятна" в вашем понимании контекста проблемы и пользователей. И подготовиться к исследованиям.
- Помогать контролировать себя ("А не забыл(-а) ли я чего-нибудь?") перед тем, как включить режим "Чик-чик и в продакшен".
Информационные персоны (как люди ищут информацию)Nikita Efimov
Очередной доклад про персон-шмерсон? В какой-то степени...
Ведь, к сожалению, часто персоны просто придумывают. Причём эти "придумки" касаются цвета глаз Марины или имени её кота, что никаким образом не относится к проектируемой системе. Все становится ещё хуже, когда проектируют сложные информационные системы.
В докладе я хочу рассмотреть подход, который часто использую для проектирования сложных (с точки зрения информационной архитектуры) систем. Ведь в таких системах люди обрабатывают большое количество информации: ищут что-то новое, взаимодействуют с найденным, возвращаются к старому.
И каждый раз их поведение может меняться в зависимости от разных факторов:
от той информации, которую они ищут;
от того, какой информацией обладают на данный момент;
от того, что хотят с этой информацией сделать в дальнейшем.
Для себя я выделяю несколько состояний человека (как я их называю - режимы поиска), в котором он может находится. И на основании этих режимов прорабатываю типичных представителей и их взаимодействие с системой.
В докладе я подробно расскажу про эти "магические" режимы поиска, и как на основании этих данных я создаю информационных персон. Ну и, конечно, я расскажу про инструменты, которые мне помогают эти информационные персоны создавать.
Многие agile-команды используют в своей работе user story. Это отличный и простой в понимании инструмент. Однако, как это часто бывает, нельзя просто так взять и применить инструмент и сразу добиться нужного результата: фичи, которые были придуманы почему-то оказываются не нужны пользователям. Но не потому, что они (фичи) плохо реализованы, а потому, что эти фичи не удовлетворяют пользовательским потребностям.
В докладе я расскажу про инструмент под названием «дизайн история». Это user story на UX-стероидах, другой взгляд на привычный для многих инструмент. Мы поговорим о том, на основании чего создавать дизайн историю (точнее, как модифицировать user story). И самое главное, как эту историю использовать в дальнейшем, как на основании ее генерировать идеи и фичи для реализации.
3. О чём сегодня поговорим
• Проблемы перехода от этапа анализа к проектированию
• Информационная архитектура и модели поиска
• Визуальные сценарии
• Объектно-информационная модель
7. Мы часто тратим силы на “игры” с
позиционированием UI-элементов,
зачастую не понимая приоритетов
информации для пользователей…
“
8. Designers don't search for a solution until
they have determined the real problem, and
even then, instead of solving that problem, they
stop to consider a wide range of potential
solutions. Only then they will converge upon
their proposal.
“
Donald Norman
13. Всё дело в информации
Информация
Информация
Информация
Информация
14. Donna Spencer
ИА отвечает за:
• Организацию информации (объектов)
• Их (объектов) четкое описание
• Предоставление человеку способов до
этих объектов добраться
15. Ключевые проблемы
• Всегда есть больше одного способа организации
информации. И не всегда ясно, какой из них лучше
• У людей разные цели и способы добраться до информации
• У людей обычно разное представление о том, где и какую
информацию надо искать (и как её описать)
• Кто-то знает больше, а кто-то – меньше (на “входе” и о
предметной области)
26. Важные особенности
• Описываем взаимодействие с системой, но не оперируем
интерфейсом
• Можно составлять как для “всех пользователей сразу”,
так и для каждой группы отдельно
• Можно рассматривать как высокоуровневые сценарии,
так и конкретные точечные
27. 1. Первоначальная визуализация
1. Фиксируем все шаги
• основной путь
• возможные отклонения
• переходные состояния
2. Разбираем каждый шаг
• Что пользователь должен найти/сделать, чтобы двинуться
дальше?
• Какие действия он может выполнять в рамках этого шага?
• Какие есть ограничения (привычки, контекст, технические и т.д.)?
• Куда он может “свернуть” с этого шага и почему (чего ему не
хватает)?
• Что может послужить причиной прекращения выполнения задачи?
28. Пример
Список листов
рассылки
Детальное по
листу рассылки Поиск и
добавление
участника
Список листов
рассылки
Не нашел
Нужно поискать
Нашел
Сценарий “Добавление пользователей к списку рассылки”
Не тот лист
29. Пример
Детальное по листу
рассылки
• Убедиться, что это тот самый лист рассылки
• Убедиться, что пользователя тут ещё нет
• Добавить нового пользователя
• Поискать конкретного пользователя
• Не смог добавить пользователя
• Пользователь не был найден (во время добавления)
• Слишком много однофамильцев, не смог различить
Цели:
Почему может прекратить:
Возможные действия:
30. 2. Проверка входов и выходов
• Всегда ли пользователь начинает свой сценарий именно
так?
• С какой информацией человек пришёл?
• Зачем он может “выйти” из сценария и вернуться
заново?
• Какие проблемы могут возникнуть во время перехода?
• В каком “режиме” поиска он сейчас находится?
• Продолжается ли сценарий вне системы?
32. Продолжаем пример
Список листов
рассылки
Добавить конкретного
человека в лист
рассылки
Добавить нового
сотрудника в
несколько листов
Вопрос в Telegram:
Почему Васе не
приходят письма из
“лидских” рассылок
33. Пример
Список листов
рассылки
Детальное по
листу рассылки Поиск и
добавление
участника
Список листов
рассылки
Сценарий: “Добавить нового сотрудника в несколько листов
рассылки”
Проверка
работоспособности
И так много раз
34. 3. Оптимизация шагов
• Можно ли упростить какие-либо шаги?
• Можно ли изменить последовательность шагов?
• Можно ли уменьшить количество переходов?
35. Что дальше?
• Хорошая основа для проработки навигационной модели
интерфейса
• Можно начинать “накладывать” интерфейс и разбивать
по состояниям
• Объединение карт для разных групп пользователей
36. Срок жизни артефактов
• Можно пытаться делать общую карту всех сценариев, но
это сложно
• Основа для проработки интерфейсов в рамках
конкретной задачи
• Можно сохранять карты для последующих сверок, но
поддерживать их в актуальном состоянии довольно
сложно
38. Нас окружает информация
1. Основная информация
То, что ищет пользователь для решения своей задачи
2. Вспомогательная информация
Дополнительная информация, которая помогает принять решение
3. “Нажималки”
То, что производит определённое действие с информацией или помогают
пользователю двигаться дальше
39. Как формировать модель
• Что (какую информацию) человек ищет?
Т.е. какие объекты он хочет найти.
• Какая дополнительная информация ему нужна?
Т.е. какие атрибуты у объекта ему могут пригодиться.
• Что он с этими объектами хочет сделать?
• Как много таких объектов может быть? Сколько реально
нужно пользователю?
• В каком виде эти объекты могут быть представлены?
+ Расставляем приоритеты у информации!!!
40. “Карточки” объектов
Объект: Заявка
Атрибуты:
• Краткое описание
• Срок исполнения
• Статус
• Уведомление о просрочке
• Тип заявки
• Кол-во связанных сущностей
• Ответственные
Действия:
• Просмотреть
• Сменить ответственного
• Эскалировать
• Архивировать
• Изменить статус
Объект: Ответственный
Атрибуты:
• ФИО
• Фото
• Подразделение
• Должность
• Линия поддержки
• Телефон
• Email
• Процент загрузки
• Индикатор “горящих” задач
Действия:
• Написать сообщение
• Посмотреть загрузку
• Посмотреть подробную
информацию о человеке
41. На основании чего создавать
• На базе визуальных сценариев
• На базе use cases, требований и других “описательных”
форматов
• На уровне эмпатии
Когда других вариантов не осталось
42. • Менеджер заходит в систему и выбирает нужный список рассылки
На базе описательных форматов
Сценарий “Добавление пользователей к списку рассылки”
После того, как менеджер создал список рассылки для нового проекта “Норка
Тушканчика”, ему необходимо добавить пользователей.
• Менеджер добавляет каждого пользователя (либо сразу всех) к проектному
листу
• Менеджер отправляет тестовое сообщение на проектный список рассылки
для проверки корректной работоспособности списка. В данном сообщении
менеджер просит каждого получившего это письмо написать ответ в этот
список рассылки. Этим менеджер проверяет возможность пользователей
как получать, так и писать письма на проектный лист.
44. В чём ценность
• Формирование интерфейса на базе понимания требуемой
пользователю информации
• Осмысленная аргументация
• какие визуальные объекты нужны и как их упорядочить
• на чём сделать акцент
• какое использовать именование
• для себя: при проработке вариантов
• для других: при защите своего решения
• Упрощение передачи задачи дальше (или приёмки)
• постановка на отрисовку интерфейса
• разработке в качестве основы для объектной модели
• для проверки решения
45. Срок жизни артефактов
• Обновлять и поддерживать в актуальном состоянии на
протяжении всего проекта
• Переиспользование готовых “карточек” в других
состояниях
48. Если подытожить
• Люди по-разному ищут одну и ту же информацию
• Минимизируйте количество “магии” в вашем процессе с
помощью разных инструментов
• Наша задача корректно упорядочить информацию в
интерфейсе и предоставить лёгкий способ до неё
добраться и что-то с ней сделать
49. Ну вот и все…
slideshare.net/nefimov
efimov.nikita@gmail.com
fb.com/nikita.efimov
For graphics thanks to freepik.com