Про ИА. Визуальные сценарии и объекто-информационная модель.Nikita Efimov
- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
Про ИА. Визуальные сценарии и объекто-информационная модель.Nikita Efimov
- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
Как 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
Информационные и ментальные модели - WIAD 2015Yury Solonitsyn
Проектируя программное обеспечение, мы создаем его структуру, работаем над его архитектурой, в том числе информационной - создаем информационную модель. Человек, изучая программу, создает в своей голове ментальную модель - представление о нашем продукте, его возможностях и функциях. Наше представление и продукте и представление о нем в сознании пользователя встречаются в пользовательском интерфейсе, который при этом становится не просто способом взаимодействия с программой, но и учебным пособием.
TК°Conf. Красивый интерфейс — это лишь часть крутого UX. Никита Ефимов.TKConf
Красивый интерфейс лишь вершина айсберга. Под водой скрывается очень много: структура самого приложение, нужный пользователю функционал, цели пользователей и бизнеса. На примере проверенных временем моделей я покажу необходимые этапы проектирования интерфейсов и их влияние на пользовательский опыт. А чтобы окончательно вас убедить в своих словах, расскажу примеры из собственного опыта, иллюстрирующие как надо и как не стоит делать.
Информационные персоны (как люди ищут информацию)Nikita Efimov
Очередной доклад про персон-шмерсон? В какой-то степени...
Ведь, к сожалению, часто персоны просто придумывают. Причём эти "придумки" касаются цвета глаз Марины или имени её кота, что никаким образом не относится к проектируемой системе. Все становится ещё хуже, когда проектируют сложные информационные системы.
В докладе я хочу рассмотреть подход, который часто использую для проектирования сложных (с точки зрения информационной архитектуры) систем. Ведь в таких системах люди обрабатывают большое количество информации: ищут что-то новое, взаимодействуют с найденным, возвращаются к старому.
И каждый раз их поведение может меняться в зависимости от разных факторов:
от той информации, которую они ищут;
от того, какой информацией обладают на данный момент;
от того, что хотят с этой информацией сделать в дальнейшем.
Для себя я выделяю несколько состояний человека (как я их называю - режимы поиска), в котором он может находится. И на основании этих режимов прорабатываю типичных представителей и их взаимодействие с системой.
В докладе я подробно расскажу про эти "магические" режимы поиска, и как на основании этих данных я создаю информационных персон. Ну и, конечно, я расскажу про инструменты, которые мне помогают эти информационные персоны создавать.
Как 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
Информационные и ментальные модели - WIAD 2015Yury Solonitsyn
Проектируя программное обеспечение, мы создаем его структуру, работаем над его архитектурой, в том числе информационной - создаем информационную модель. Человек, изучая программу, создает в своей голове ментальную модель - представление о нашем продукте, его возможностях и функциях. Наше представление и продукте и представление о нем в сознании пользователя встречаются в пользовательском интерфейсе, который при этом становится не просто способом взаимодействия с программой, но и учебным пособием.
TК°Conf. Красивый интерфейс — это лишь часть крутого UX. Никита Ефимов.TKConf
Красивый интерфейс лишь вершина айсберга. Под водой скрывается очень много: структура самого приложение, нужный пользователю функционал, цели пользователей и бизнеса. На примере проверенных временем моделей я покажу необходимые этапы проектирования интерфейсов и их влияние на пользовательский опыт. А чтобы окончательно вас убедить в своих словах, расскажу примеры из собственного опыта, иллюстрирующие как надо и как не стоит делать.
Информационные персоны (как люди ищут информацию)Nikita Efimov
Очередной доклад про персон-шмерсон? В какой-то степени...
Ведь, к сожалению, часто персоны просто придумывают. Причём эти "придумки" касаются цвета глаз Марины или имени её кота, что никаким образом не относится к проектируемой системе. Все становится ещё хуже, когда проектируют сложные информационные системы.
В докладе я хочу рассмотреть подход, который часто использую для проектирования сложных (с точки зрения информационной архитектуры) систем. Ведь в таких системах люди обрабатывают большое количество информации: ищут что-то новое, взаимодействуют с найденным, возвращаются к старому.
И каждый раз их поведение может меняться в зависимости от разных факторов:
от той информации, которую они ищут;
от того, какой информацией обладают на данный момент;
от того, что хотят с этой информацией сделать в дальнейшем.
Для себя я выделяю несколько состояний человека (как я их называю - режимы поиска), в котором он может находится. И на основании этих режимов прорабатываю типичных представителей и их взаимодействие с системой.
В докладе я подробно расскажу про эти "магические" режимы поиска, и как на основании этих данных я создаю информационных персон. Ну и, конечно, я расскажу про инструменты, которые мне помогают эти информационные персоны создавать.
A taxonomy of search strategies and their design implicationsTony Russell-Rose
The focus of this particular talk is on extending the review of information search strategies (aka ‘Modes of Discovery‘) with a deeper exploration of their implications for design at the application (architectural) level.
Открывающая презентация на мастер-классе по проектированию в МИЭМ. В мероприятии участвовали сотрудники компаний UIDG и Mail.ru. Видео и фото с мастер-класса можно посмотреть здесь: http://miem.edu.ru/news/17-%D0%BC%D0%B0%D1%80%D1%82%D0%B0-%D0%B2-%D0%9C%D0%98%D0%AD%D0%9C-%D0%BF%D1%80%D0%BE%D1%88%D0%B5%D0%BB-%D0%BC%D0%B0%D1%81%D1%82%D0%B5%D1%80-%D0%BA%D0%BB%D0%B0%D1%81%D1%81-%D0%BF%D0%BE-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8E-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D1%85-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D0%BE%D0%B2.html
В этой презентации руководитель компании SEO-компании "Клюква" Александр Петраков рассказывает о составных частях поисковой системы и даёт представление об азах SEO-продвижения
О пользе работы над юзабилити интерфейсов.
Выступление на конференции "Интернет бизнес" 14 апреля 2011 г.
Читать заметки к слайдам в режиме примечаний! :)
Гости из Москвы из компании USABILITYLAB расскажут нам про историю HCD и usability-тестирование (виды тестирования, требования, ограничения, обработку данных)
О современном состоянии дел в Data Science (в Украине и в мире). О задачах, которые решают специалисты по анализу данных и планах ЖГТУ по подготовке таких специалистов.
Как правильно поставить ТЗ на создание сайта, Алексей Бородкин, лекция в Школ...Yandex
Лекция Алексея Бородкина в Школе вебмастеров: «Как правильно поставить ТЗ на создание сайта».
https://academy.yandex.ru/events/webmasters_school/yawebm2015/
ТЗ: две буквы с большим потенциалом
Что такое техническое задание. Какое место оно занимает в веб-разработке. Какие цели преследует. И каким требованиям оно должно отвечать.
Что нужно сделать, прежде чем садиться за ТЗ
Зачем нужна подготовка к написанию ТЗ. Какую информацию нужно собрать и как выстроить этот процесс. На каком этапе веб-разработки нужно писать ТЗ — и что будет, если этот момент упустить. Какое отношение имеют к ТЗ прототипы, пользовательские истории и прочие инструменты проектирования.
Хорошее ТЗ
Как соединить в один документ описание интерфейсов, структуру данных и много чего ещё. Структура правильного, хорошего ТЗ с подробным разбором каждого пункта. С какой стороны приступать и как эффективнее всего выстроить работу.
Кто должен писать ТЗ
Кто может написать хорошее ТЗ. Где найти такого человека и как встроить его в общие процессы. Что делать, если ТЗ пишет сам заказчик.
Плохое ТЗ
Популярные ошибки. Чем они ужасны и как их избежать.
Жизнь с ТЗ
По какой схеме нужно согласовывать ТЗ. Как применять его в дальнейшей работе. Кому не нужно показывать ТЗ ни при каких обстоятельствах. Что делать, если ТЗ никому не нравится.
ТЗ по ГОСТ: ад на Земле
Краткая история развития ТЗ со времён Брежнева и до наших дней. Почему я старательно избегаю слова «ТЗ». Почему вы должны нервно вздрагивать при слове «ГОСТ». Что делать, если вы работаете с госзаказчиком.
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 может помочь:
- Дольше оставаться в области проблем перед тем, как вы начнёте прорабатывать конкретное решение.
- Синхронизироваться со всей командой (чтобы все были на одной волне) об идеи, причинах её реализации и всего, что находится в области проблем.
- Увидеть "белые пятна" в вашем понимании контекста проблемы и пользователей. И подготовиться к исследованиям.
- Помогать контролировать себя ("А не забыл(-а) ли я чего-нибудь?") перед тем, как включить режим "Чик-чик и в продакшен".
Многие agile-команды используют в своей работе user story. Это отличный и простой в понимании инструмент. Однако, как это часто бывает, нельзя просто так взять и применить инструмент и сразу добиться нужного результата: фичи, которые были придуманы почему-то оказываются не нужны пользователям. Но не потому, что они (фичи) плохо реализованы, а потому, что эти фичи не удовлетворяют пользовательским потребностям.
В докладе я расскажу про инструмент под названием «дизайн история». Это user story на UX-стероидах, другой взгляд на привычный для многих инструмент. Мы поговорим о том, на основании чего создавать дизайн историю (точнее, как модифицировать user story). И самое главное, как эту историю использовать в дальнейшем, как на основании ее генерировать идеи и фичи для реализации.
25. Разные потребности
• Пополнить запасы на складе
• Заказать запчасти для ТО
• Заказать набор деталей для конкретного ремонта
• Заказать специфичную деталь “под клиента”
• Быть в курсе относительно стоимости и доступности
требуемой детали (консультирование)
44. • Какую пользовательскую проблему решаем?
Простой алгоритм действий
• Что это за люди?
• Зачем это нужно бизнесу?
• Какие есть ограничения/возможности?
45. Scope
• контекст использования
• потребности пользователей и их поведение
• стандарты, гайдлайны, эргономика
• требования usability (относительно задач)
• требования бизнеса (которые затрагивают
пользователей)
• требования безопасности и регуляторных документов
• и т.д.
Функционал на базе требований
47. Убрать “полезное”
8 (383) 280-42-21
Написать обращение
Нужна помощь или есть вопросы?
Обратитесь в службу заботы о клиентах
Оптовым клиентам: 5 раз в неделю
Самовывоз
Доставка по городу
Отправка по области
ул. 1-ая Ельцовка, дом 1 корпус "И"
Наличная и безналичная оплата
Водители
Воскобойников Александр
Тараканов Сергей
Чекушкин Алексей
Шагирданов Павел
Кононов Алексей
директор филиала
Егоров Алексей
менеджер по развитию
Москалюк Анна
бухгалтер
ПН – ПТ: с 9:00 до 18:00
СБ, ВС: выходной
Автопитер – Новосибирск
48. Scope
• контекст использования
• потребности пользователей и их поведение
• стандарты, гайдлайны, эргономика
• требования usability (относительно задач)
• требования бизнеса (которые затрагивают
пользователей)
• требования безопасности и регуляторных документов
• и т.д.
Функционал на базе требований
53. Всё дело в информации
Информация
Информация
Информация
Информация
54. Ключевые проблемы
• Всегда есть больше одного способа организации
информации. И не всегда ясно, какой из них лучше
• У людей разные цели и способы добраться до информации
• У людей обычно разное представление о том, где и какую
информацию надо искать (и как её описать)
• Кто-то знает больше, а кто-то – меньше (на “входе” и о
предметной области)
57. Надо задать 100500 вопросов
• Что человек ищет (какую информацию)?
• Что он с ней собирается делать?
• Какие использует термины для описания/поиска?
• Как информационные объекты связаны друг с другом?
• Как обеспечить быстрый доступ к наиболее важным
объектам?
• Какая информация важна в первую очередь (на
конкретном экране)?
• и многое другое…
58. Skeleton
Решение конкретных интерфейсных задач
• компоновка экранов и навигация между ними
• учёт типовых паттернов
• выбор типов элементов для взаимодействия
• проработка микровзаимодействия
• проработка реального контента
• учёт особенностей восприятия информации и
поведенческих факторов
65. Ограниченные возможности
• Нарушение цветовосприятия
• Проблемные дисплеи/мониторы
• Освещение
• Физические возможности человека (зрение, моторика,
скорость обработки информации и др.)
• Анимация
• и многое другое
69. If we like just looking at a
beautiful product, we’ll most
likely end up thinking it is more
usable than it actually is.
http://www.uxmatters.com/mt/archives/2016/08/designing-desirable-experiences.php
72. Люди забудут, что вы сказали.
Люди забудут, что вы сделали.
Но они никогда не забудут, что
вы заставили их чувствовать.
Maya Angelou
73. Эмоции
Мы уже почти готовы отправить акт сверки
СПАСИБО, ЖДУ
Ваш запрос обрабатывается
16.03.2016 – 16.04.2016
alexander.voskoboynikov@gmail.com
Мы не нашли взаиморасчётов за указанный период
Попробуйте запросить акт сверки за другой период.
ЗАПРОСИТЬ
Ой, что-то пошло не так…
16.03.2016 – 16.04.2016