Базовый принцип №2. Продумывайте сначала концепции, а потом их представления. Это совершенно НЕ означает, что нужно сначала проектировать функциональность продукта, а потом уже думать о его внешнем виде. Многие разработчики и даже проектировщики интерфейсов начинают работу над проектом, представляя как будет выглядеть пользовательский интерфейс, на что он будет похож. Они рисуют свои идеи на бумаге или в виде макета, а иногда даже создают работающий прототип. Не делайте этого! Не ставьте лошадь впереди телеги. Позаботьтесь сначала о содержимом, а потом уже о внешнем виде.

Это означает, что нужно ответить на вопросы:

• Какие концепции будут видимы для пользователя? Знакомы ли эти концепции пользователю из его предметной области или нет? Если нет, то могут ли они быть представлены как дополнения к уже известным концепциям или они чужды пользователям и пришли из компьютерного мира?
• Какие данные пользователи будут создавать, просматривать или изменять?
  
• Какую информацию пользователи будут получать из этих данных? Как? Какие для этого нужны шаги? Откуда поступают входные данные и где будут использоваться полученные данные? 
• Какие опции, варианты выбора, настройки и элементы управления будут представлены в цифровом продукте?
  Это не о том, какими элементами управления представить данные (радиокнопки, меню, раскрывающийся список и прочее). Это об их назначении, цели и роли (день недели, валюта, адрес электронной почты и прочее)

Если вы ответите на предыдущие вопросы, то вы готовы к созданию концептуальной модели. 

Создание концептуальной модели

Концептуальная модель – это не пользовательский интерфейс, она не выражается в терминах кнопок, диалоговых окон или других элементов управления. Она выражается в терминах пользовательских задач: данные, которыми манипулируют пользователи, как эти данные организованы и что пользователи делают с этими данными. 

Концептуальная модель объясняет абстрактно предназначение цифрового продукта и с какими концепциями должны быть знакомы люди, чтобы пользоваться им.
Идея заключается в том, чтобы сначала создать ясную и простую концептуальную модель и потом по ней спроектировать пользовательский интерфейс.

Концептуальная модель – это модель программы или веб сайта, которую разработчики хотели бы, чтобы пользователи поняли.

Создайте простую и понятную концептуальную модель, а потом проектируйте по ней пользовательский интерфейс.

“Просто насколько возможно, но не проще.” Albert Einstein.

Одна из целей создания концептуальной модели – сделать цифровой продукт настолько простым, насколько это возможно. Чем меньшим количеством концепций можно обойтись, тем лучше, пока это позволяет пользователям выполнять их задачи.

“Меньше, значит больше.” Mies van der Rohe.

Например, для программы указывающей направления движения на автомобиле не нужно говорить пользователю “поверните на северо-запад” достаточно сказать – “поверните налево”.

Примером концептуальной модели для программы отображающей структуру организации может быть набор прямоугольников, подписи к прямоугольникам, цвет прямоугольников, соединительные линии и т.д., что будет более понятно программистам, которые имели дело с графиками и диаграммами, но не будет понятна всем остальным.

Или структура организации, структура отделов, работники и т.д. Такая модель более понятна людям, которые имели дело с построением структуры организации и легко смогут её использовать.

Сохраняйте фокус концептуальной модели на задачах и концепциях с которыми знакомы пользователи, а не которые следуют из мира компьютеров или откуда-то ещё.

Применяйте новые для пользователя концепции, только если это действительно оправданно! 

Новые концепции незнакомы даже экспертам в предметной области и придётся потратить много времени, чтобы их изучить. 

Они потенциально будут взаимодействовать со всеми остальными концепциями в системе и сложность системы возрастёт не в арифметической, а в геометрической прогрессии!

Каждая новая концепция должна доказать, что её применение абсолютно необходимо и цена её внедрения должна быть ниже, чем польза от неё. 

Помните – меньше, значит больше! 

Анализ объектов/действий очень важен! Он помогает определить все концептуальные объекты, которые будут показаны пользователю в интерфейсе, все доступные действия с этими объектами, атрибуты (видимые свойства) каждого типа объектов и взаимосвязи между объектами. [Card, 1996; Johnson and Henderson, 2002]

В цифровом продукте могут быть другие объекты, не только те, что перечислены в концептуальной модели, но они должны быть скрыты от пользователя.

Анализ объектов/действий определяет концепции, которые будут видимы для пользователя.

Программисты наверняка заметили схожесть определения объектов их свойств и действий с ними с похожими действиями в Объектно-Ориентированном программировании. Это позволяет начать продумывать ОО структуру программы сразу же после проведения анализа объектов/действий.

Если нечто не входит в список объектов/действий из концептуальной модели, пользователь не должен об этом знать! 

Если мы будем проектировать программу для работы с банковскими счетами, анализ объектов/действий будет включать в себя такие объекты как проводка, счёт, платёж и прочее. В нём не будет таких объектов как буфер, окно диалога, режим, база данных, таблица или строка.

Также, в нём будут такие действия как выписка чека, внесение депозита, снятие со счёта, подведение баланса и прочее и не будет таких действий как нажатие кнопки, загрузка базы данных, редактирование столбца в таблице или переключение режима.

В концептуальной модели не должно быть компьютерных терминов, таких как тип шифрования, и прочее.

Например, на сайте Яндекс.Деньги есть такая возможность – выбрать один из предыдущих платежей и повторить его с минимальными изменениями. Это избавляет пользователей от заполнения всех полей каждый раз.

Взаимоотношения объектов

Объекты в концептуальной модели могут находится в разных типах взаимоотношений: один может быть более специфическим типом другого (иерархия) или один может быть частью другого. 

Например, платёжный счёт является одним из типов банковских счетов, цифровая камера является одним из типов камер и прочее. Выстраивание чёткой иерархии объектов в концептуальной модели помогает сделать модель более понятной для пользователя. 

Это может помочь вам сделать одни и те же действия для объектов в одной иерархии. Например, те же операции, которые применимы для банковского счёта, должны быть применимы и для текущего счёта. 

Чем меньше разница между набором доступных действий в иерархии – тем лучше. Пользователь научившись работать с одним объектом в иерархии сможет легко понять и научиться работать с другим. 

Также, важно различать часто применимые действия и редко применимые. Это поможет при проектировании.

После анализа объектов/действий вам нужно составить словарь пользователя, чтобы использовать только эти термины в программе и в документации. Как только вы определите все видимые для пользователя концепции, вам нужно согласовать как вы будете их называть. 

В этом процессе может принимать участие вся команда разработки, но лучше поручить это дело профессионалу – техническому писателю. 

Лучше всего, если терминология будет взята не из заданного промышленностью лексикона, а из реальной жизни. Для этого нужно проанализировать записи интервью с пользователями и составить единый словарь терминов. 

Использование словаря пользователя поможет вам избежать двух распространённых ошибок: когда один и тот же объект называют в разных местах по разному или для разных объектов используется один и тот же термин.

Прописывайте варианты использования (use-cases) и создавайте базовые контекстные сценарии

После создания концептуальной модели нужно прописать варианты использования программы или сайта и базовые контекстные сценарии. В этих документах должны использоваться только термины из словаря пользователя. 

Эти сценарии могут быть использованы не только для проектирования, но и для составления документации по программе, справки, при подготовки сценариев функционального и юзабилити тестирования.

Прежде чем делать изменения в коде, они должны быть одобрены всеми членами команды и внесены в концептуальную модель! В противном случае эти изменения приведут к развалу концептуальной модели и краху программы.

Нельзя делать изменения, которые противоречат концептуальной модели.

Преимущества создания и использования концептуальной модели в фокусе на задачах пользователя и в общей целостности картины.

Продумывание концептуальной модели вынуждает проектировщиков рассматривать только важные задачи, относящиеся к каждой видимой пользователю концепции с учётом взаимоотношений между объектами. Это позволяет создавать программы, поддерживающие задачи пользователя наиболее естественным образом.

Создание списка всех объектов и действий позволяет обнаружить общие действия, у многих объектов. Это позволяет унифицировать интерфейс при работе с похожими объектами. Это делает интерфейс проще, сохраняет целостность восприятия у пользователя и позволяет более быстро обучаться.

Преимущества создания и использования концептуальной модели:

• Приоритеты
  Создание списка всех видимых пользователем концепций позволяет определить их приоритеты как для проектирования пользовательского интерфейса, так и для реализации.
• Лексикон/словарь пользователя
  Создание словаря пользователя помогает достичь целостности в терминологии, которая затем применяется не только в интерфейсе, но и в документации и справке.
• Варианты использования и контекстные сценарии
  Прописывание вариантов использования и создание базовых контекстных сценариев помогает не только в проектировании интерфейса программы, но и в подготовке функционального и юзабилити тестирования.
• Валидация изменений
  Изменения кода проходят проверку и вносятся только если соответствуют концептуальной модели.

В предыдущей статье мы уже рассказали про базовый принцип детального проектирования №1. Фокусируйтесь на пользователях и их задачах, а не на технологиях.

Полезные ссылки по теме:

• UX-школа Артема Кузнецова – обучаем за 3 месяца всем основным методам UX-исследований, теория и практика, международный сертификат.
• Телеграм канал “UX-школа Ю-эксперт” – бесплатные материалы тренингов, вебинаров и выступлений на конференциях и в СМИ.
• Курс по юзабилити-аудиту – обучаем проводить юзабилити-аудит на самом высоком уровне и уверенно и аргументированно представлять его результаты Заказчику.
• UX-стажировка в компании Ю-эксперт – бесплатная практика в реальных проектах под руководством опытных специалистов.

Интересно, а вы применяете базовые принципы детального проектирования для своих сайтов и мобильных приложений? Предлагаем проверить это прямо сейчас! → Узнайте больше о том, что такое юзабилити-экспертиза, и какую пользу она может дать вашему проекту