Хитрости 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
Краткий рассказ про то, как аналитик и проектировщик могут построить совместную работу над пользовательским интерфейсом, чем это полезно для них и для создаваемого продукта.
Проектирование интерфейсов: Процесс+Команда=Продукт (2015)Yaroslav Perevalov
Конспект обзорной лекции на зимнем интенсиве по UI / UX в Британке (2015), описаны:
* Процесс-проектирования
* Роли в юзабилити-команде
* Организация взаимодействия ю-команды с командой проекта
* Виды требований к успешному продукту
Хорошая техническая документация окружает программный продукт - помогает его проектировать и продавать, помогает его осваивать, помогает его поддерживать и продолжать разработку.
Документация определяет User Experience или Customer Experience далеко за пределами пользовательского интерфейса.
Презентация к выступлению на встрече UX-специалистов в консорциуме Кодекс.
WIAD 2017 — Понятный продукт — От информационной архитектуры к структуре инте...Yury Solonitsyn
Пользовательский интерфейс связывает между собой продукт (приложение, сайт) и пользователя. Структура интерфейса, как зеркало, отражает одновременно заложенную разработчиками информационную архитектуру продукта и его ментальную модель, формирующуюся в сознании пользователя. В зависимости от назначения продукта и уровня подготовки пользователей можно выбирать подход к представлению информационной архитектуры в структуре проектируемого интерфейса.
Выступление на конференции WIAD-2017 — 18 февраля 2017, Санкт-Петербург, Россия.
Информационные и ментальные модели - WIAD 2015Yury Solonitsyn
Проектируя программное обеспечение, мы создаем его структуру, работаем над его архитектурой, в том числе информационной - создаем информационную модель. Человек, изучая программу, создает в своей голове ментальную модель - представление о нашем продукте, его возможностях и функциях. Наше представление и продукте и представление о нем в сознании пользователя встречаются в пользовательском интерфейсе, который при этом становится не просто способом взаимодействия с программой, но и учебным пособием.
Ксения Стернина, Дизайн-решения. Проверено экспериментомMail.ru Group
Речь пойдет о поиске и обобщении закономерностей в исследуемой работоспособности наборов традиционных решений. Выступление будет содержать интерактивную часть.
Проектирование интерфейсов: Процесс+Команда=Продукт (2015)Yaroslav Perevalov
Конспект обзорной лекции на зимнем интенсиве по UI / UX в Британке (2015), описаны:
* Процесс-проектирования
* Роли в юзабилити-команде
* Организация взаимодействия ю-команды с командой проекта
* Виды требований к успешному продукту
Хорошая техническая документация окружает программный продукт - помогает его проектировать и продавать, помогает его осваивать, помогает его поддерживать и продолжать разработку.
Документация определяет User Experience или Customer Experience далеко за пределами пользовательского интерфейса.
Презентация к выступлению на встрече UX-специалистов в консорциуме Кодекс.
WIAD 2017 — Понятный продукт — От информационной архитектуры к структуре инте...Yury Solonitsyn
Пользовательский интерфейс связывает между собой продукт (приложение, сайт) и пользователя. Структура интерфейса, как зеркало, отражает одновременно заложенную разработчиками информационную архитектуру продукта и его ментальную модель, формирующуюся в сознании пользователя. В зависимости от назначения продукта и уровня подготовки пользователей можно выбирать подход к представлению информационной архитектуры в структуре проектируемого интерфейса.
Выступление на конференции WIAD-2017 — 18 февраля 2017, Санкт-Петербург, Россия.
Информационные и ментальные модели - WIAD 2015Yury Solonitsyn
Проектируя программное обеспечение, мы создаем его структуру, работаем над его архитектурой, в том числе информационной - создаем информационную модель. Человек, изучая программу, создает в своей голове ментальную модель - представление о нашем продукте, его возможностях и функциях. Наше представление и продукте и представление о нем в сознании пользователя встречаются в пользовательском интерфейсе, который при этом становится не просто способом взаимодействия с программой, но и учебным пособием.
Ксения Стернина, Дизайн-решения. Проверено экспериментомMail.ru Group
Речь пойдет о поиске и обобщении закономерностей в исследуемой работоспособности наборов традиционных решений. Выступление будет содержать интерактивную часть.
CONCEPTUALIZACIÓN EPISTEMOLÓGICA Y ONTOLÓGICA DEL PROYECTO DE INVESTIGACIÓN:
GERENCIA DE LA MENTE EN EL LIDERAZGO AUTÉNTICO: UN ENFOQUE ÉTICO Y PRÁCTICO
Digital Marketing - From Dark Art to Illuminated Science (Guest Lecture) Deepak Mathews
Slides from the guest lecture by Deepak Mathews, Digital Marketing Expert at the University of Bern - November 25th, 2015
Communications and Sales Management (M.Sc), Institute of Marketing and Management, University of Bern.
The talk aims to chart how the relatively new field of digital marketing has evolved from it’s obscure beginnings as a niche practice into a mainstream business function adopted by almost all organizations globally.
Luego de la investigación documental se generó este archivo en respuesta a los enunciados planteados y finalmente se tomó la Teoría Fundamentada como el camino a seguir para el desarrollo de mi Tesis Doctoral en la Universidad Yacambu.
Инструменты юзабилити для роста бизнесаFedotov Alex
Обзор 5 летней практики команды юзабилити.
Как создать персонаж или архетип персоны
Как за 5 секунд понять качество вашего сайта или посадочной страницы
Как своими руками сделать юзабилити-тестирование
10 принципов юзабилити Якоба Нильсена для быстрой оценки юзабилити вашего сайта
Удаленное юзабилити тестирование, сервисы
Как создать интерактивный прототип, обзор программ Axure, Marvel и других
Обзор 5 летней практики команды юзабилити.
Как создать персонаж или архетип персоны
Как за 5 секунд понять качество вашего сайта или посадочной страницы
Как своими руками сделать юзабилити-тестирование
10 принципов юзабилити Якоба Нильсена для быстрой оценки юзабилити вашего сайта
Удаленное юзабилити тестирование, сервисы
Как создать интерактивный прототип, обзор программ Axure, Marvel и других
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
8 из 15 банков улучшили интерфейс, 7 - полностью поменяли интерфейс. В новых интерфейсах встречаются уже новые проблемы, некоторые не очевидны и часть из них критичны. Даже такое небольшое изменение, как замена иконки, может сыграть злую шутку. Не стоит забывать об устоявшихся и привычных решениях.
Все банки постоянно дорабатывают интерфейсы, функциональность наращивается ежемесячно. Появляются решения, которые могут изменить пользовательское поведение.
79,1% проблем доступности интерфейса для людей с ограниченными возможностями связан с качеством кода. Часть исправлений этих ошибок займет у ИТ-специалиста от 1 до 8 часов. Более экономичным вариантом будет включение требований по доступности в ТЗ.
SCRUM выглядит отлично, если у вас идеально сработавшаяся кросс-функциональная команда и классный клиент, который понимает процесс. На практике все совсем не так радужно. В докладе покажу как мы:
- Готовим проект к старту и планируем загрузку команды.
- Решаем проблемы с изменяющимися требованиями и архитектурой
- И почему мы не говорим клиентам, что “делаем SCRUM”
16 апреля с 14:00 до 19:30 в Сколково пройдет семинар для резидентов Сколково. Речь пойдет о работе в стартапе, привлечении инвестиций, моделях монетизации проектов, юзабилити, СММ и о пути стартапа к большому бизнесу.
Лекторы:
Дмитрий Сатин, Юлия Суворова (Usabilitylab)
Андрей Рябых (Webmaster.SPb, SeoExperts, Media Cartel, Газета.СПБ, автор книг по манимейкингу и интернет-коммерции)
Сергей Фрадков (Стартап-акселератор «Идеальная машина»)
Михаил Смолянов («Мегаплан»)
Никита Келлерман (Republic Performance)
Илья Балахин (Paper Planes)
Алексей Довжиков (Trinet)
ITGM#8 Анна Абрамова Юрий Солоницын Интерфейс - совместная работа аналитика и...SPbCoA
Совместный доклад представителей двух сообществ: аналитиков и проектировщиков интерфейсов на ITGM#8.
Анна Абрамова (СПб СоА) и Юрий Солоницын (UXSpb) рассказали, как строится совместная работа аналитика и проектировщика интерфейсов в больших проектах. Где они помогают друг-другу и где начинают "толкаться локтями".
Similar to 2015 Secon. Как сделать сервис не для программистов (20)
4. 4
!
Анализ пользовательских потребностей поможет:
определить в каком функционале действительно нуждаются
пользователи;
решить на разработку какой функциональности тратить время в
первую очередь;
выявить конкурентные преимущества.
Потребности пользователей
9. 9
!
Пользовательские истории
Пользовательская история — краткое описание возможностей,
реализация которых необходима для получения пользователем
пользы от системы. Помогает понимать, что должна делать система.
Для описания пользовательской истории подходит шаблон:
Мне как <роль> необходимо <решить задачу>, чтобы <достичь цель>.
12. 12
!
Пользовательские сценарии
Пользовательские сценарии — запросы, с которыми пользователи
приходят в систему. Запросы касаются системы и взаимодействия с
ней. Пользовательские сценарии могут группироваться по ролям,
ситуациям и задачам.
13. 13
!
Пользовательские сценарии
Из-за изменившегося законодательства я должен хранить
в системе дополнительный реквизит о заказчиках (старых и
новых). Мне надо обновить карточку заказчика в CRM так, чтобы
изменения распространились на всю систему.
.
Например:
14. 14
!
Пользовательские сценарии
1. Я хочу отредактировать поля в выбранном объекте и добавить новые.
2. Я хочу поделиться созданным объектом с коллегами из другого филиала таким образом, чтобы
они могли просто сохранить его в свою систему и начать сразу использовать.
3. Мне надо загрузить в систему присланный объект. Я хочу убедиться, что он не поломает связи
между объектами.
4. Я вношу изменения в систему и хочу удалить объект, который больше не будет использоваться.
5. Мне надо проверить, что я везде заменил старый объект на новый.
У основного сценария появляются дополнительные.
15. 15
!
Пользовательские сценарии
Из-за изменившегося законодательства я должен идентифицировать всех новых клиентов в CRM
при помощи их паспортных данных. Мне надо добавить в карточку клиента поля для хранения:
• номера паспорта;
• даты и места его выдачи;
• скана титульной страницы;
• типа документа (загран, внутренний или иностранный).
Эти поля надо сделать обязательным для заполнения у всех новых клиентов, обратившихся к нам
после 1 июня 2015 года.
Добавив данные, получаем задание для тестирования системы.
16. !
Истории и сценарии
Задача 3
Задача 2
Задача 1
Пользовательские
истории
Пользовательские
сценарии
Кейс 1 Кейс 2 Кейс 3
16
18. 18
!
Ранжирование сценариев
Ранжирование сценариев помогает оценить значимость пользовательских потребностей.
Необходимо указать приоритет каждого сценария для каждого портрета пользователя. Для этого на
пересечении сценарий/пользователь выставляется цифра от 1 до 3 (1 – низкий приоритет,
2 – средний приоритет, 3 – высокий приоритет).
Количество оценок низкого приоритета (1) для каждого пользователя должно быть > 20%.
Количество оценок среднего приоритета (2) для каждого пользователя должно быть < 20%.
Количество оценок высокого приоритета (3) для каждого пользователя должно быть < 20%.
При суммировании баллов отбираются самые важные и отсеиваются неважные потребности.
19. 19
!
Метод «модель Кано»
«Модель Кано» — используется для оценки реакции пользователей на отдельные характеристики
продукции. Полученные с его помощью результаты позволяют выявлять функционал, который
должен войти в первые итерации разработки, и управлять удовлетворенностью пользователей.
20. 20
!
Метод «модель Кано»
Функционал системы оценивается по трем свойствам.
1. Восхищающие (привлекательные) свойства, если они присутствуют в продукте, вызывают чувства
удовлетворения и восторга (балл = 5). Однако, если этих характеристик нет, пользователи не
испытывают неудовлетворения (балл = 0).
2. Желательные свойства вызывают удовлетворение, если они есть (балл = 1), или
неудовлетворение, если их нет (балл = −1).
3. Базовые свойства относятся к группе тех качеств, которые обязательно должны присутствовать
в продукте (балл = 0). Отсутствие функций вызывает неприязнь (балл = −5).
23. 23
!
Метод «модель Кано»
На основе полученных данных строится график,
показывающий, какой функционал вызовет
wow-эффект и отсутствие какого функционала
скажется негативно на реакции пользователей.
24. !
Задача 3
Задача 2
Задача 1
Пользовательские
истории
Пользовательские
сценарии
Кейс 1 Кейс 2 Кейс 3
24
Кейс 1 Кейс 2 Кейс 3
Пойдет в первую
итерацию разработки
Истории и сценарии
26. 26
!
Работая с пользовательскими сценариями, можно:
выявить важные для пользователей потребности и реализовать их;
найти функционал, которого нет ни у кого из конкурентов;
оценить качество продукта.
Итог
28. #
28
Пользовательская история:
Я как администратор хочу вести версионность объектов: сохранять
версии, загружать старые версии.
Пользовательский сценарий:
Мне заказали обновить старую систему. Мне нужно проверять кто и
что в команде программистов сделал.
Пример № 1
29. #
29
Дополнительные сценарии
1. Я хочу отменить изменения объекта, сделанные другим пользователем, т.к. он все поломал.
2. Я настраиваю системе новые объекты и не хочу, чтобы кто-нибудь помешал моей работе с ними.
3. Я хочу, чтобы система автоматически защищала объекты от изменения другими пользователями,
пока я работаю с ними.
4. Я разработал сложный объект и не хочу, чтобы кто-нибудь нечаянно его изменил и все сломал.
5. Мне надо написать правила для автоматического формирования нумерации документации,
принятой в компании.
6. Я хочу прокомментировать сложный объект для будущих поколений, т.к. он важен для нашей
системы и его очень легко сломать.
7. Я нечаянно создал объект и хочу удалить его.
8. Я случайно что-то удалил (даже не помню что) и хочу это вернуть, чтобы ничего не сломалось.
Пример № 1
30. #
30
Пользовательская история:
Я как администратор хочу посмотреть, кто и когда создал/изменил
объект.
Пользовательский сценарий:
Компания развивает новое направление, и мне надо определить,
что потребуется изменить в системе и ее компонентах.
Пример № 2
31. #
31
Дополнительные сценарии
1. Я хочу знать, к кому из коллег обратиться с вопросами по поводу объекта, давно ли «трогали» этот
объект, кто и что именно в нем изменял последним.
2. Я хочу найти все созданные мной объекты.
3. Я хочу найти объекты, созданные коллегой.
4. Я ищу объект по названию, он относится к CRM, и мне не нужны объекты, не относящиеся к
другим системам.
5. Я хочу найти объект определенного типа (справочник, сервисный класс и т.п.).
6. Я изменяю объект и хочу найти все его дочерние / связанные с ним объекты.
7. Я ищу объекты с определенными полями.
Пример № 2
32. #
32
Пользовательская история:
Я как администратор хочу использовать дебаггер для объектов
разных типов.
Пользовательский сценарий:
Хочу сделать рассылку по участникам моей группы в социальной
сети, которые еще ничего у нас не заказывали. Надо, чтобы в
систему загружались все контакты из аккаунта в социальной сети.
Пример № 3
33. #
Пример № 3 33
Дополнительные сценарии
1. Мне надо создать объект со сложными правилами использования. Я думаю, что мне будет проще
написать код.
2. Я нашел код где-то в Интернете и хочу изменить объект с помощью этого кода.
3. Я не уверен в качестве написанного / скопированного кода и хочу проверить, не поломает ли он
систему.