Про ИА. Визуальные сценарии и объекто-информационная модель.Nikita Efimov
- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
Про ИА. Визуальные сценарии и объекто-информационная модель.Nikita Efimov
- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
33й вебинар UX Russia: Андрей Сикорский и Дмитрий Сатин обсуждают особенности проведения интервью с пользователями и заказчиками на этапе юзабилити-исследований.
Собеседование как секс. Удовольствие должны получить обе стороны :)Viktoriya Pridatko
Считаю, что собеседования должны быть умными, вдохновляющими, информативными. А выражение лица эйчара не должно вызывать ощущение, что мухи дохнут и молоко киснет :)
Собеседование от слова беседа. Разговаритвайте друг с другом, слушайте, а не проецируйте свою картину мира на собеседника.
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
33й вебинар UX Russia: Андрей Сикорский и Дмитрий Сатин обсуждают особенности проведения интервью с пользователями и заказчиками на этапе юзабилити-исследований.
Собеседование как секс. Удовольствие должны получить обе стороны :)Viktoriya Pridatko
Считаю, что собеседования должны быть умными, вдохновляющими, информативными. А выражение лица эйчара не должно вызывать ощущение, что мухи дохнут и молоко киснет :)
Собеседование от слова беседа. Разговаритвайте друг с другом, слушайте, а не проецируйте свою картину мира на собеседника.
В этой презентации вы найдете ответы на вопросы: что важно в SEO в 2013? На какие моменты обратить внимание в SEO маркетологам? Как с наименьшими затратами обеспечить достойные позиции в поисковой выдаче? И многое другое...
Этот фреймворк помогает делать продукты, пользующиеся спросом. С помощью него вы сможете лучше понять пользователей и их проблемы, создать или улучшить продукт, начать разговаривать с покупателем на понятном ему языке. Фреймворк позволяет сделать это всё довольно быстро за счет глубинных интервью и четкого формата постановки задач дизайнерам, программистам, копирайтерам и т.д. Может прозвучать как таблетка от всех болезней, но это действительно фундаментальный инструмент. Во многом он идёт вразрез с традиционными маркетинговыми канонами, например Human Centred Design с его "персонами" — об этом расскажем подробно на митапе :)
2009 год, Челябинск, совместно с Денисом Ивановым
www.andbusiness.ru
- как ведет себя пользователь при возникновении потребности
- как ориентируется на сайте после перехода с поиска
- элементы, вызывающие доверие
- пара примеров
Мониторинг интернет пространства, Дарья РождественскаяAlex Zagoumenov
Одна из встреч в нижегородском Циферблате. В этот раз Дарья Рождественская говорила о том, за чем нужно и стоит следить в сети, чтобы оставаться конкурентноспособной компанией.
Любишь и умеешь эффективно общаться с людьми?
Тебя не пугает многозадачность и разнообразие проектов?
Хочешь получить престижную и перспективную IT профессию?
→Lviv PM School в Одессе приглашает на презентацию курса "Управление командами в IT".
Ни один из ВУЗов не готовит специалистов по управлению проектами, а высшие школы менеджмента, такие как МБА или РМА нуждаются в наличии значительного управленческого опыта.
Мы хотим разорвать этот замкнутый круг, предложить первый шаг на пути к освоению этой профессии, для которой достаточно живого интереса и готовности взять ответственность за свою карьеру в собственные руки.
Это вводная программа по развитию управленческих и лидерских навыков для специалистов, которые работают в IT области.
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). И самое главное, как эту историю использовать в дальнейшем, как на основании ее генерировать идеи и фичи для реализации.
6. Donna Spencer
ИА отвечает за:
• Организацию информации (объектов);
• Их (объектов) четкое описание;
• Предоставление человеку способов до
этих объектов добраться.
7. Ключевые проблемы
• Всегда есть больше одного способа организации
информации. И не всегда ясно, какой из них лучше;
• У людей разные цели и способы добраться до
информации;
• У людей обычно разное представление о том, где и
какую информацию надо искать (и как её описать);
• Кто-то знает больше, а кто-то – меньше (на “входе”
и о предметной области);
20. ИКЭ “в целом” для групп
• Сильнее погрузиться в группы
Брейнсторм с нужными вопросами и раскладыванием “по полочкам”
• Провалидировать свое понимание групп
Вряд ли первые гипотезы были верны
• Сформировать новые группы
Следующая итерация гипотез
21. 1. Что человек ищет?
• Какая у человека цель?
Какую информацию и для чего ищет?
• Какая дополнительная информация может понадобиться
человеку?
В каких ситуациях и почему именно она?
• Как человек поймет, что нашел искомое?
Какие внутренние и/или внешние критерии прекращения поиска?
22. Пример
Одну или несколько деталей, чтобы:
• Спланировать покупку деталей и наполнить склад требуемой номенклатурой;
• Под заказ клиента;
• Осуществить ТО/ремонт клиента;
• Быть в курсе (самому или клиенту) относительно стоимости и доступности
требуемой детали (консультирование);
• и др.
Для конкретной детали:
• Сколько стоит оригинал? (прицениться)
• Сколько стоит аналог/заменитель? (прицениться)
• Сколько времени (минимально) займет доставка нужного ему количества?
• Какие есть аналоги (что за производители)?
• и др.
23. Пример
Как поймет, что нашел нужное?
• Стоимость;
• Срок поставки;
• Качество (оригинал/аналог/производитель);
• Обладает требуемыми характеристиками (например, свечи);
• Подходит конкретному автомобилю;
Найденная деталь удовлетворяет исходным требованиям:
24. 2. Что знает на момент поиска?
• С какой информацией начинает поиск?
Как в голове, так и на других “носителях”
• Что знает об искомой информации?
• Что знает о предметной области в целом?
25. Пример
• Номер детали и/или VIN и/или параметры автомобиля;
• Предполагаемый бюджет (как часто такое бывает?);
• Срок, к которому нужен товар (как часто такое бывает?);
• Срок, к которому нужно найти деталь (напр., в течении получаса дать ответ
клиенту);
• и др.
26. 3. Какими словами описывает?
• Как человек формулирует поисковый запрос?
У себя в голове
• Как трансформирует запрос из головы в систему?
• Какие слова и термины использует, когда ищет?
• Какие вопросы могут возникать в процессе поиска?
• Как воспринимает ту или иную информацию?
Если речь про существующую систему
27. Пример
• “Нужна надежная поставка. Привезут ли через день?”;
• “Надо бы понять минимальные цены на проверенных производителей аналогов”;
• “Почему это предложение такое дешевое?”;
и много других
Вопросы:
• “Нужен сайлент-блок на Авео. Почему рычаги выводит?”;
• “Закупить пару комплектов 1321517 на склад”;
• “Нужно процедить кузовщину на Логан: переднее левое крыло, переднюю левую
фару, бампер, заклепки еще для локеров”;
и др.
Исходные запросы:
28. 4. Что делает при поиске?
• Какие действия совершает?
Зачем? Какие есть триггеры? Кто или что влияет на эти действия?
• Есть ли между действиями устойчивая связь/
последовательность?
• Почему может прекратить поиск?
Что будет делать в этом случае?
• Какие проблемы могут возникнуть?
Как их будет решать?
• Почему может прервать поиск?
На какой период времени?
29. Пример
Триггеры
• Пришел клиент в магазин;
• Мастер принес список деталей на проценку (машина на подъемнике висит);
• Продал деталь со склада и увидел, что осталось всего 2 штуки;
и др.
Почему может прервать?
• Отвлек клиент (лично/по телефону);
• Нужно согласовать варианты с клиентом;
• “Пойду, проверю стоимость и других поставщиков”;
и др.
30. 5. Где и для чего будет использовать?
• Информация нужна здесь и сейчас или будет использовать
в другом месте?
• Что будет делать с информацией дальше?
• Есть ли другие действующие лица, которым эта
информация может быть нужна?
31. Пример
• Сразу закажет, нужна только одна конкретная деталь для склада;
• Нужно зафиксировать разные варианты, чтобы обсудить с
клиентом;
• Надо отложить, чтобы потом единым заказом оформить все детали
по автомобилю;
• “Отлично, ценник поднялся. А у меня запасы. Все ко мне пойдут”;
и др.
32. 6. Частотность
• Как часто человек совершает эти действия?
• Почему именно такая частотность?
33. 7. Важность
• Насколько важно для человека найти искомую
информацию?
• Почему именно такая важность?
