Хитрости 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
Интерфейс — Совместная работа аналитика и проектировщикаYury Solonitsyn
Краткий рассказ про то, как аналитик и проектировщик могут построить совместную работу над пользовательским интерфейсом, чем это полезно для них и для создаваемого продукта.
Хитрости 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
Интерфейс — Совместная работа аналитика и проектировщикаYury Solonitsyn
Краткий рассказ про то, как аналитик и проектировщик могут построить совместную работу над пользовательским интерфейсом, чем это полезно для них и для создаваемого продукта.
Про ИА. Визуальные сценарии и объекто-информационная модель.Nikita Efimov
- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
Хорошая техническая документация окружает программный продукт - помогает его проектировать и продавать, помогает его осваивать, помогает его поддерживать и продолжать разработку.
Документация определяет User Experience или Customer Experience далеко за пределами пользовательского интерфейса.
Презентация к выступлению на встрече UX-специалистов в консорциуме Кодекс.
Информационные и ментальные модели - WIAD 2015Yury Solonitsyn
Проектируя программное обеспечение, мы создаем его структуру, работаем над его архитектурой, в том числе информационной - создаем информационную модель. Человек, изучая программу, создает в своей голове ментальную модель - представление о нашем продукте, его возможностях и функциях. Наше представление и продукте и представление о нем в сознании пользователя встречаются в пользовательском интерфейсе, который при этом становится не просто способом взаимодействия с программой, но и учебным пособием.
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
WIAD 2017 — Понятный продукт — От информационной архитектуры к структуре инте...Yury Solonitsyn
Пользовательский интерфейс связывает между собой продукт (приложение, сайт) и пользователя. Структура интерфейса, как зеркало, отражает одновременно заложенную разработчиками информационную архитектуру продукта и его ментальную модель, формирующуюся в сознании пользователя. В зависимости от назначения продукта и уровня подготовки пользователей можно выбирать подход к представлению информационной архитектуры в структуре проектируемого интерфейса.
Выступление на конференции WIAD-2017 — 18 февраля 2017, Санкт-Петербург, Россия.
Бизнес-анализ и юзабилити - найдите 10 отличий (и 10 сходств).Yuri Vedenin
В докладе рассматриваются две дисциплины: бизнес-анализ и юзабалити (точнее, в более широком смысле - UX). Авторы рассматривают сходства и различия двух дисциплин. В итоге находят много общего и подсказывают, куда и где надо посмотреть специалистам обеих дисциплин.
Про ИА. Визуальные сценарии и объекто-информационная модель.Nikita Efimov
- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
Хорошая техническая документация окружает программный продукт - помогает его проектировать и продавать, помогает его осваивать, помогает его поддерживать и продолжать разработку.
Документация определяет User Experience или Customer Experience далеко за пределами пользовательского интерфейса.
Презентация к выступлению на встрече UX-специалистов в консорциуме Кодекс.
Информационные и ментальные модели - WIAD 2015Yury Solonitsyn
Проектируя программное обеспечение, мы создаем его структуру, работаем над его архитектурой, в том числе информационной - создаем информационную модель. Человек, изучая программу, создает в своей голове ментальную модель - представление о нашем продукте, его возможностях и функциях. Наше представление и продукте и представление о нем в сознании пользователя встречаются в пользовательском интерфейсе, который при этом становится не просто способом взаимодействия с программой, но и учебным пособием.
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
WIAD 2017 — Понятный продукт — От информационной архитектуры к структуре инте...Yury Solonitsyn
Пользовательский интерфейс связывает между собой продукт (приложение, сайт) и пользователя. Структура интерфейса, как зеркало, отражает одновременно заложенную разработчиками информационную архитектуру продукта и его ментальную модель, формирующуюся в сознании пользователя. В зависимости от назначения продукта и уровня подготовки пользователей можно выбирать подход к представлению информационной архитектуры в структуре проектируемого интерфейса.
Выступление на конференции WIAD-2017 — 18 февраля 2017, Санкт-Петербург, Россия.
Бизнес-анализ и юзабилити - найдите 10 отличий (и 10 сходств).Yuri Vedenin
В докладе рассматриваются две дисциплины: бизнес-анализ и юзабалити (точнее, в более широком смысле - UX). Авторы рассматривают сходства и различия двух дисциплин. В итоге находят много общего и подсказывают, куда и где надо посмотреть специалистам обеих дисциплин.
ITGM#8 Анна Абрамова Юрий Солоницын Интерфейс - совместная работа аналитика и...SPbCoA
Совместный доклад представителей двух сообществ: аналитиков и проектировщиков интерфейсов на ITGM#8.
Анна Абрамова (СПб СоА) и Юрий Солоницын (UXSpb) рассказали, как строится совместная работа аналитика и проектировщика интерфейсов в больших проектах. Где они помогают друг-другу и где начинают "толкаться локтями".
Проектирование интерфейсов: Процесс+Команда=Продукт (2015)Yaroslav Perevalov
Конспект обзорной лекции на зимнем интенсиве по UI / UX в Британке (2015), описаны:
* Процесс-проектирования
* Роли в юзабилити-команде
* Организация взаимодействия ю-команды с командой проекта
* Виды требований к успешному продукту
Классический процесс юзабилити-проектирования достаточно сложный и дорогой, рассчитан на полноценный цикл производства продукта, с существенным бюджетом и планом.
Быстрая-экстремальная разработка в условиях ограниченных временных и прочих ресурсов требует дешёвых и быстрых юзабилити-методов.
Это рассказ о таких экстремальных методах, как экспресс-аналитика, зкспресс-экспертиза, коридорное юзабилити-тестирование: плюсы и минусы каждого метода, ограничения, область применения, примеры.
www.productdesign.center
Актуальные задачи обучения современных UX -специалистов, проектировщиков продуктов и UI, продакт- и проджект- менеджеров. Новый образовательный курс.
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). И самое главное, как эту историю использовать в дальнейшем, как на основании ее генерировать идеи и фичи для реализации.
10. Аналитик
Цель:
Выявить основную
проблему бизнеса
(основной объект
автоматизации) и
предложить способы ее
решения
UX-специалист
Цель:
Выявить основную
проблему
пользователей и
выстроить наиболее
удобный и эффективный
способ их
взаимодействия с
продуктом
11. Аналитик
• Провести исследования пользователей;
• Выявить бизнес-цели;
• Разработать пользовательские истории и
сценарии использования;
• Описать основные workflow;
• Разработать use cases;
• Выявить и разработать функциональные
и нефункциональные требования;
• Выявить различные ограничения;
• Разработать прототип пользовательского
интерфейса;
• Проверить прототип на соответствие
функциональности.
Процесс:
UX-специалист
• Провести исследования пользователей;
• Выявить бизнес-цели;
• Разработать пользовательские истории и
сценарии использования;
• Описать основные workflow;
• Выявить и разработать функциональные
требования;
• Выявить различные ограничения и
контекст использования;
• Разработать прототип пользовательского
интерфейса;
• Проверить прототип на соответствие
функциональности и ожиданий.
Процесс:
17. Ключевые различия
• Разные “взгляды на мир” (идеология);
• Подход с разных сторон;
• По-разному фиксируем модель использования;
• По-разному проверяем итоговое решение.
19. Аналитик
Достигнута основная цель,
но применен
безэмоциональный,
формальный подход
Учтена специфика работы
пользователя, но не все
его особенности
без UX
UX-специалист
Достигнуто удобство для
пользователя, но нет
полного понимания
основной проблемы
без аналитика
Красиво/удобно, но есть
риск быть оторванным от
реальности
22. Аналитик
После понимания “что
нужно, кому и как этого
достичь”, может
спроектировать
интерфейсы
взаимодействия по
выявленным workflow и
use cases (и прочим
артефактам)
UX-специалист
Может выявлять цели (и
бизнеса в том числе),
описывать процессы и
функциональность. Одним
словом, понять “что
нужно, кому и как этого
достичь”
24. Аналитик
Ищет выгоду для
бизнеса и системы
(эффективно, быстро и
понятно)
UX-специалист
Ищет выгоду для
пользователей
(понятно, эффективно,
привлекательно)