МИО | 659368

Что такое МИО?
1. МИО - много-много вопросов, которые люди задают системе.
2. Вопросы
  1. Основные
    1. Вопросы глобальной МИО следуют из жизненной ситуации и из понимания пользователя.
    2. Иначе говоря, для составления вопросов для глобальной МИО вам не нужен сам интерфейс и его содержание. Нужны только аналитические данные, пусть и самые обобщённые.
  2. Уточняющие
    1. Уточняющие вопросы уточняют то, что пользователь успел воспринять и переварить в интерфейсе.
    2. При взаимодействии с интерфейсов у человека часто возникает желание вступить в диалог:
      1. Написано, что с вами можно связаться. Как?
      2. Вот вы пишете, что ручку надо крутить по часовой стрелке. Это куда?
      3. Акция действует только 4 дня. Какие именно 4 дня?
      4. У меня в путёвке написано, что мы прилетаем в Анталию. Но я же в Турцию тур покупал, верните деньги!
      5. Я скачал файл. Где он?
      6. Вот у вас цены на замену шин зависят от радиуса диска. А какой у меня радиус?
    3. Иногда уточняющие вопросы остаются локальными. Но чаще оказывается, что один и тот же вопрос возникает во многих местах системы.
    4. Для решения вопроса пользователю нужны дополнительные экраны (или части экранов). Например, куда он сможет перейти для получения справочной информации или для восстановления доступа к данным.
    5. Из уточняющих вопросов структура интерфейса растёт быстрее.
  3. Как составить вопросы?
    1. именно предложения, оканчивающиеся знаком вопроса.
    2. Вопросы позволяют сверить постановку задачи с её результатом.
    3. Вопросы должны быть простыми и короткими, занимать одну строку, а лучше полстроки.
    4. Примеры:
      1. Сколько у меня... ?
      2. Как я могу... ?
      3. Где мой... ?
      4. Когда мне... ?
    5. Приоритеты
      1. Какие вопросы для пользователя важны, а какие нет?
      2. От чего в крайнем случае можно отказаться?
      3. Чему нужно выделить на экране больше места, а что можно отодвинуть?
      4. Визуальные приоритеты в дизайне должны быть синхронизированы с приоритетами пользовательских ожиданий.
      5. Интерфейс может колебаться вместе с приоритетами пользователя, когда важность ответа зависит от ситуации, например, актуальность расписания работы выше в период новогодних праздников.
      6. Поиск визуальных решения — это уже непосредственно дизайн-работа, но важно отследить и протестировать, что при переходе от букв к дизайн-решению сохраняются.
    6. User Story -> МИО
      1. Примеры
      2. Как сотрудник, я хочу оформить заявление на отпуск, чтобы сходить в отпуск
      3. Как мне оформить заявление на отпуск?
      4. Как менеджер, я хочу получать уведомления, когда израсходовано 80% бюджета, чтобы избежать перерасхода
      5. По каким проектам заканчивается бюджет?
      6. Как покупатель, я хочу доставку продуктов за 15 минут, чтобы успеть приготовить из них ужин
      7. Мне успеют доставить продукты за 15 минут
      8. Как обучающийся, я хочу сегодня разобраться в материале, чтобы завтра применить новые знания на практике
      9. Как бы мне побыстрее понять, что тут написано?
    7. МИО -> User Story
3. Действия
  1. действия, отвечающие на вопросы что сделать, глаголы в инфинитиве (пойти, посмотреть, купить, узнать, заказать, закрыть, забыть), а НЕ существительные и даже НЕ отглагольные существительные.
4. Первый и главный вопрос, который всегда фоном висит в голове у пользователя — «Тут есть то, что мне нужно?». В переводе на наш усложнённо-дизайнерско-модельный язык — «Моя модель информационных ожиданий соответствует экрану, на котором я нахожусь?».
5. Плюс - возможность предугадать вопросы пользователя при проектировании взаимодействия с интерфейсом
6. это инструмент для непрерывного использования
7. 99% интерфейсов дизайнеры и разработчики собирают из готовых интерфейсных паттернов, которые тянут за собой готовые решения для готового набора вопросов и действий.
  1. У пользователей сформированы МИО, оторванные от системы и привязанные скорее к паттернам.
  2. Этими паттернами можно (хоть и не обязательно) пользоваться.
  3. проблема: велик соблазн при дизайне сразу начать мыслить ответами (то есть паттернами). И забыть о вопросах. Результат — «программерские» интерфейсы: функциональность избыточна (потому что паттерны с лихвой перекрывают потребности ваших пользователей), а самые важные задачи в интерфейсе спрятаны так же глубоко, как и второстепенные.
  4. Примеры паттернов:
    1. Ссылаешься на что-то — поставь ссылку
    2. Просишь сделать — объясняй, как
    3. Не описывай, а показывай
    4. Незнакомый термин — разъясни
    5. Изживай умолчания по возрасту, географии, полу и т.п.
    6. Нужно что-то посчитать — посчитай за человека, предложи калькулятор
    7. Ничто не должно в интерфейсе выглядеть так же, как в 1С
    8. Есть зависимость от единиц измерения, географии — предлагай сменить, сообщай
  5. Антипаттерны
    1. Стандартные неудачные какбыответы, недоответы и вообщенеответы, которые не закрывают вопрос пользователя, а то и вызывают новые вопросы.
    2. Примеры:
      1. Запрос на действие, которое непонятно где
      2. Избыточная функциональность
      3. Отсутствие геолокации
      4. Default city (не указывать город, если этот город — Москва)
      5. Ссылка на десктоп-версию из мобильного приложения
      6. Отсутствие ссылки на упоминаемый в тексте раздел
      7. Избыточный текст
      8. Нарушение принципа «Не расскажи, а покажи»
Уже существующие
1. Как найти?
  1. Цель - понять, работает ли информационный интерфейс так, как хотелось бы пользователям
  2. Составить список вопросов и действий, которые этому экрану соответствуют
  3. Большинство современного IT — это работа с legacy.
2. Как оценить?
  1. Составить МИО
  2. Сравнить с МИО с интерфейсом
    1. Ответ есть/ нет?
    2. Насколько явный?
    3. Если ответ неявный, насколько это критично в этом случае?
3. Как улучшить?
  1. После сверки с МИО
    1. Какие интерфейсные элементы нужно заменить?
    2. Какие интерфейсные элементы нужно добавить?
    3. Где нужна подсказка для пользователя?
    4. Посмотрите на структуру интерфейса
      1. Если вам кажется, что на несколько вопросов лучше отвечать рядом, а не раскидывать ответы по всему экрану — вам не кажется.
    5. Оцените уровень информационного шума
      1. Если вам кажется, что на экране много интерфейсных элементов, которые непонятно на какой вопрос отвечают и к какой жизненной ситуации относятся — вам не кажется.
  2. Поиск уточняющих вопросов
    1. Тщательно изучаете интерфейс по МИО и просто так. Подумайте, в каких местах у пользователя возникнут уточняющие вопросы. Посмотрите результаты тестирования — какие уточняющие вопросы появились у ваших респондентов?
Как проектировать многостраничные интерфейсы
1. МИО - вспомогательный инструмент
  1. Используйте для проектирования привычный вам подход, будь то сценарии, CJM или согласованная-пересогласованная карта сайта.
  2. При работе над информационно насыщенными страницами и разделами используйте МИО — быстро набросайте его на коленке и тут же примените для улучшения вашего интерфейса.
2. МИО - основной инструмент
  1. Составьте подробное МИО по всему интерфейсу
  2. Структурируйте вопросы. Здесь возможны варианты.
    1. По страницам сайта (контакты, продукция, конструктор).
    2. По интерфейсным фокусам (шапка, подвал, навигация).
    3. По крупным блокам (FAQ, продукция, онлайн-обучение)
    4. Каким-либо еще оправданным в вашем случае образом.
  3. Проектируйте.
  4. Исправляйте МИО по ходу проектирования, исправляйте интерфейс по ходу работы с МИО.
Как проектировать МИО простого интерфейса?
1. Как составить?
  1. Представьте вашего пользователя и запишите его жизненную ситуацию
    1. Где находится человек? Как он сюда попал?
    2. Зачем он вообще полез на сайт, в мобильное приложение, в почту?
    3. Что он хочет и хочет ли что-то вообще?
    4. Какие у него есть ограничения, особенности?
    5. Пишите в свободной форме, не запаривайтесь на полноту описания и стопроцентную точность. 3-5 предложений достаточно.
  2. Сфокусируйтесь на ситуации, запишите я-вопросы и я-действия.
    1. Какие у человека есть вопросы к странице, системе, вселенной?
    2. Что он хочет сделать на странице, в приложении и вообще?
    3. Пишите всё, что приходит в голову. Лучше выкинуть лишнее, чем забыть важное.
  3. Проверьте формулировки.
    1. Все вопросы сформулированы как вопрос и снабжены забавной закорючкой в конце предложения: «?».
    2. Вопросы и действия сформулированы простым разговорным языком.
    3. В вопросах и действиях есть слова «я», «мой», «мне». Или эти слова подразумеваются по смыслу.
  4. Выделите самые важные вопросы и действия
    1. Количество этих самых важных никак не регламентировано. Действуйте по обстоятельствам и исходя из здравого смысла.
  5. Если вопросов и действий получилось больше 20 штук, то можете попробовать структурировать их по темам или разделам.
2. Как составить для всех пользователей и ситуаций?
  1. Зафиксируйте портреты пользователей.
    1. Не тратьте время на третьестепенные детали. Обозначьте самое важное, то, что имеет отношение к использованию вашего интерфейса.
    2. Если групп пользователей получается много, они разные и никак не хотят объединяться в 3-5 портретов, опишите каждого 1-2 фразами или сгруппируйте в таблицу.
  2. Опишите ситуации
    1. Опишите все разумные ситуации, в которых может оказаться первый пользователь
    2. Подумайте о втором пользователе и его ситуациях. Они отличаются от первого? Вот те, что отличаются — дополняйте в список.
    3. И так со всеми портретами.
  3. Составьте МИО
    1. Запишите все вопросы и действия по первой ситуации.
    2. Подумайте о второй ситуации. Какие есть новые вопросы и действия? Добавляйте их в список.
    3. Аналогично со всеми ситуациями.
3. Как нарисовать?
  1. Составьте МИО.
  2. К каждому вопросу или действию нарисуйте интерфейсный ответ. Делайте пошагово, фокусируйтесь на одном вопросе и не отвлекайтесь на другие.
  3. Посмотрите на свои наброски и подумайте, какие элементы стоит объединить. Объедините элементы так, чтобы группа одновременно отвечала на несколько вопросов/действий, связанных по смыслу.
  4. Нарисуйте экран целиком, не бойтесь ошибиться.
  5. Если после этого поняли, что можно сделать лучше — переделайте.
  6. Протестируйте самостоятельно или с помощью товарища. Ищите как ошибки, так и уточняющие вопросы.
  7. Внесите правки. Добавьте ответы на уточняющие вопросы, которые появились у вас и ваших респондентов.
4. Как протестировать?
  1. Составить МИО
  2. Найти респондента, похожего на потенциального пользователя
  3. Рассказать ему, что требуется от него
    1. Описать ситуацию
    2. Предоставить интерфейс в любом виде
    3. Предупредить, что способности респондента не тестируются, неправильных ответом быть не может
    4. Задавайте респонденту вопросы из МИО и просите найти ответ в интерфейсе.
      1. Нашел/Нет?
      2. Насколько быстро?
      3. Какие были сложности, вопросы?
    5. Попросите сделать действия из МИО
      1. Понял, как сделать?
      2. Какие были сложности, вопросы?
    6. Запишите всё, что говорит респондент по ходу тестирования
      1. На какие пункты МИО пользователь не нашел ответа/действия?
      2. Какие пункты вызвали сложности?
      3. Какие уточняющие вопросы появились у пользователя?
Какие бывают элементы интерфейса
1. Типовые
  1. Главный экран системы
  2. Навигация (шапка и подвал)
  3. Вспомогательные экраны с информацией о компании-владельце продукта
  4. Экран (или часть экрана) про помощь
  5. Стартовая страница личного кабинета
  6. Страница ключевого объекта, например, товар в интернет-магазине
  7. Страница каталога
  8. Экран результатов поиска
2. Более мелкие
  1. Текст
  2. Фото
  3. Кнопки
  4. Видео
  5. Карта
  6. Схема
  7. Расписание, график
  8. Чат
  9. QR-код
  10. Все что угодно
3. NB! Нужно вытаскивать набор экранов и интерфейсных компонентов из вопросов и других вспомогательных документов.
4. Чем раньше разработчики узнают об ожиданиях пользователя, тем меньше непонятных фич и неожиданностей, рушащих архитектуру