Интерфейс как система

Ilya Aleksandrov
May 10, 2016 · 18 min read

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

Я выступал на эту тему на WUD 2013 (по ссылке видео выступления), но презентация носила поверхностный характер, и я решил написать об этой теме более подробно.

Что такое системность интерфейса

Любой интерфейс — это система и вы, как проектировщик, можете погружаться в формирование этой “системы” на разный уровень.

Разрабатывая мобильное приложение вы уже находитесь в рамках созданной системы (iOs, Android, Windows mobile) вплоть до того, что можете создать приложение полностью на стандартных компонентах. Тогда вы не думаете о создании системы, а лишь применяете ее правила.

Вы можете отойти от гайдлайнов и создать уникальные решения в своем приложении. При этом в целом вы все равно останетесь в рамках операционной системы: будете использовать стандартные жесты, навигацию между приложениями, кнопку “back” в Андройде, стандартные способы фидбека и пр.

Если вы создаете обычный веб-сайт: контентный проект или небольшой интернет-магазин, вам скорее всего будет достаточно стандартных паттернов и компонентов, которые чаще всего используются в вебе. Для них нужно создать свой стиль и скорректировать поведение. Это ваш уровень погружения в создание системы. Остальная часть интерфейсной системы лежит на плечах браузера: скрол, навигация с помощью ссылок, кнопка назад, контекстное меню по правой кнопке мыши и пр.

А вот если вы создаете, например, уникальный игровой проект, вроде клиентских MMO (World of Warcraft, EVE online) или новую операционную систему, то вам придется думать о самых базовых свойствах вашего интерфейса. Ваша задача перейдет в плоскость создания кирпичиков и правил, с помощью которых можно будет строить взаимодействия для любых задач в рамках вашей системы.


Вот несколько примеров, иллюстрирующих разницу в подходах:

Пример 1: типичный ход проектирования

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

Системный подход. Вы проектируете для всех экранов сразу. Например, вы создаете единую систему выдачи сообщений об ошибках для всего интерфейса, в том числе эти правила распространяются и на поля ввода и автоматически на них применяются. В любом новом экране интерфейса у вас уже готово решение для выдачи ошибок.

Пример 2: вы создаете навигационное меню.

Не системный подход. У вас на данный момент в приложении (веб, десктопном или мобильном) 5 разделов. Вы умещаете их в отведенное пространство экрана, задаете правила выравнивания и отдаете программистам.

Системный подход. Вы думаете: “а что если пунктов меню станет 3 или 7?, а что если места на экране не хватит? Что если надпись в одном из них будет в 4 раза длиннее другой”. Вы проектируете поведение компонента “меню” с учетом всех этих ситуаций (в разумных пределах, конечно) и имплементируете. После этого вам не нужно заниматься дизайном меню каждый раз, когда у вас появляются, меняются или исчезают его пункты. Оно будет жить по созданным вами законам уже без вас.

Пример 3: перед вами стоит задача по созданию новой фичи.

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

Системный подход. Вы смотрите, нет ли в вашей системе уже готовых паттернов или компонентов для решения новой задачи. Если вы понимаете, что стандартными средствами реализовать это можно, но будет очень плохо с точки зрения финального экспириенса, то вы продумываете новое взаимодействие, как новый компонент во всех деталях. Возможно, достаточно расширить уже существующий компонент новыми свойствами и правилами.

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

В каких случаях стоит использовать системный подход:

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

На самом деле системный подход будет правильным для проекта любого масштаба и сложности. Это вклад в его будущее.

Не стоит сильно углубляться в платформенность на самых первых этапах создания продукта. Это может сильно осложнить и затянуть разработку. Лучше всего делать это после MVP. Тогда вам проще будет сформировать требования для создания “системы” и вы не потеряете драгоценное время.


Системный подход — это не отказ от человекоориентированности. Он никак не противоречит исследованиям, аналитике и любимым вами методологиям проектирования, это лишь способ организации интерфейса и организации работы по его созданию.

Что влечет за собой системный подход:

Для пользователя

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

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

Для разработчика

Плюс: скорость разработки и поддержки, легкая масштабируемость.

Минус: сложность создания системы на начальном этапе (там где мы могли бы просто решить одну локальную задачу, мы решаем целый пул задач, должны думать на будущее).

Устройство системы

Как может выглядеть система, из каких частей может состоять? Я опишу свой опыт из “танков”. Важно учитывать, что это клиентская MMO (многопользовательская онлайн игра, запускаемая отдельным приложением на компьютере). Это накладывает ряд особенностей:

  • Интерфейс в подобных играх часто создается с нуля, он не обязан подчиняться парадигме какой бы то ни было существующей системы (например, Windows), хотя и используют некоторые привычные паттерны из этих систем. Интерфейс игры может быть совершенно самобытным;
  • Самобытность означает, что глубина проработки системы очень большая, вплоть до разработки таких деталей как: механизм блюра фона, уникальные курсоры, тонкие настройки скрола, использование 3-d камеры для навигации и др.;
  • Деятельность игрока зачастую отличается от привычных задач в веб или мобильных рабочих приложениях. Например, ориентирование и перемещение в трехмерном пространстве;
  • В играх важно вовлечение игрока, атмосферность.

Об особенностях интерфейсов игровой индустрии можно посмотреть выступление меня и Леши Копылова на ProfsoUX.

В “танках” я в основном занимался не боевыми, а сервисными интерфейсами — это все что происходит до боя или между боями (бой — это основной игровой процесс). Работал не с самого начала проекта, а когда проект уже был популярен. По сути мы унифицировали и систематизировали то, что уже было, так как неконсистентность существующих решений не позволяла нам эффективно разрабатывать новые фичи.


В общем случае, я бы выделил три глобальных уровня системы интерфейса:

  1. Манифест, UX стратегия, UX вижен — это ваши основополагающая философия, описание базовых подходов или макрофичей, касающиеся взаимодействия с пользователем. Создавая концепцию экосистемы интерфейсов для коммерческих автомобилей я начинал работу именно с этого пункта. А в танках это уже существовало до меня.
  2. Базовые правила взаимодействия — зачастую они универсальны (те же эвристики Нильсена), но имеют вариации в зависимости от платформ, культурных особенностей или контекста и области применения. Например, при проектировании автомобильного интерфейса правила будут касаться ограничений на время реакции водителя, возможность прерывания действий, деления на основную и второстепенную деятельность и др. У базовых правил обычно высокий уровень абстракции.
  3. Детальное описание решений — здесь описываются конкретные, разработанные вами элементы и правила.

Я опущу 1 и 2 пункты (они специфичны для разных областей и проектов и выходят за рамки моей статьи) и ниже опишу только третий пункт. Это не калька с гайда танков, это примерная иллюстрация составных частей системы. Другой тип проекта может иметь другую структуру. Также стоит отметить, что сейчас я не работаю над данным проектом. Все скриншоты ниже сделаны из актуальной версии игры.

Составные части системы:

UI компоненты

Это элементарные части интерфейса, из которых он “строится”. Имеют атрибуты и правила поведения. Могут быть настраиваемыми в зависимости от контекста, а также составными.

Возможные типы компонентов:

  • Курсоры. Служат для иллюстрирования типа взаимодействия, которое можно совершить, или которое уже совершается;
  • Контейнеры: экраны, окна, поповеры, тултипы и другие элементы. В них, как правило располагаются другие компоненты и контент;
Слева направо: окно, инфотип, поповер
  • Контролы (кнопки, скролы, пункты меню, слайдеры, контекстное меню, табы и пр.). То, с чем можно непосредственно взаимодействовать;
  • Уникальные компоненты, например “карусель” танков. Эти компоненты, как правило, выполняют особую функцию и редко повторяются в интерфейсе. С помощью “карусели” игрок выбирает танк, на котором он пойдет в бой. Другим примером уникального компонента может служить основное навигационное меню;
  • Списки и таблицы. Списки — один из основных элементов в интерфейсах и на них может быть завязано много разнообразных функциональностей
Таблица танков
Список боевых задач. Сложный список, который содержит в себе несколько более простых компонентов, таких как каунтер и прогресс-бар

Как видно, на двух картинках выше довольно разные элементы, но фактически это может быть один компонент с разными настройками. Самые базовые свойства у них едины, например функционирование скролинга или поведение элемента строки при наведении или при клике. Но есть настраиваемые свойства: высота строки (узкая/широкая), наличие доп. динамических компонентов в строке, кликабельность (есть/нет), способ отображения (список/тайлы) и пр.

  • Простые элементы типа иконок, прогресс баров, индикаторов;
  • Визуальное представление игровых сущностей (танки, награды, опыт, кредиты, экипаж) и отображение их атрибутов;

Возьмем для примера компонент “инфотип” и посмотрим, в чем заключается его проектирование.

Инфотип — это расширенный тултип: плашка, которая вызывается при наведении на игровую сущность.

Так выглядят инфотипы в интерфейсе
  1. Прежде всего нужно определить потребность, для которой он нам нужен и в каких ситуациях мы будем его использовать. (Например: Нам нужен элемент для выдачи расширенной информации по какой-либо сущности);

2. Разработать устройство компонента и взаимодействие с ним:

  • Как он формируется, из каких элементов состоит?
  • Каковы его ограничения по высоте? Имеет ли он фиксированную ширину или она может меняться?
  • Как вызывается пользователем? Появляется сразу или с задержкой? Исчезает ли, когда человек уводит курсор с элемента? Перемещается ли вслед за курсором?;
  • Как позиционируется относительно курсора? Что если курсор находится у края экрана, куда смещается инфотип?;
  • И так далее.

3. Инфотип — это контейнер, в нем будет размещаться разнообразный контент. Нам необходимо типизировать этот контент и разработать правила по его размещению:

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

Есть также смысловые блоки: например, вверху — заголовок, ниже — основная информация, еще ниже — дополнительная, а в самой нижней части игрок всегда найдет статус сущности (если сущность может иметь различные состояния).

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

Паттерны

Паттерны — это повторяющиеся решения, которые служат для удовлетворения определенной интерфейсной потребности. Зачастую они состоят из нескольких компонентов либо технически являются свойствами сразу нескольких компонентов, как мета-системы (читай ниже).

Примеры:

  • Использование иллюстрации в качестве фона в окне, где не много контента;
  • Способ оформления “шапки” в окне для некоторых фичей;
Типовое оформление шапки окна типа боя
Типовое оформление шапки окна типа боя
  • Способ отображения доступности и недоступности сущности (правило визуального отображения дизейбла);
Дизейбл во всем интерфейсе формируется с помощью диагональной штриховки и затемнения.

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

Еще примеры паттернов:

  • Специальный элемент для отображения “новое”;
Обозначение новой акции в списке
  • Специальный элемент для обозначения того, что сущность “участвует в акции”.
Обозначение танков, которые участвуют в акции (небольшой элемент красноватого цвета со значком процентов справа внизу)

Два последних паттерна являются свойствами компонентов, на которые они применяются. В данном случае этими компонентами являются списки. В них “зашиты” ленточка “новое” и иконка “акция”. Они автоматически применяются на нужные итемы из списка, когда сервер сообщает соответствующую информацию.

Кстати, значок “акция” — это пример, когда дизайнеру надо проектировать не конкретное решение для конкретного окна, а для всей системы сразу и продумать возможные варианты в будущем:

Во всех интерфейсах используется один и тот же значок “акция”

Создать хорошее универсальное решение гораздо сложнее, нежели сделать для каждого окна свое.

Мета-системы

Мета-системы описывают правила, которые распространяют свое действие на все компоненты и паттерны. К ним могут относиться:

  • Цветовое кодирование;
  • Шрифтовая система, сетка и отступы;
  • Система написания интерфейсных текстов;
  • Функциональная анимация;
  • Функциональные интерфейсные звуки.

Скажем, если в нашем паттерне или UI-компоненте (например, списке, или кнопке) будет использоваться текст, то мы не можем делать его каким угодно. Он будет ровно таким, как заложено в мета-системе. Это очень удобно: одно правило распространяется сразу на десятки и сотни случаев и элементов, причем и на те, что появятся позже. Но создавая подобную сквозную систему необходимо учитывать, чтобы она могла удовлетворить все многообразие интерфейсных потребностей, а это очень непросто.

Цветовое кодирование (мета)

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

В эту мета-систему могут входить правила для кодирования:

  • Эмоциональной нагрузки: положительная/отрицательная/нейтральная;
  • Смысловой нагрузки: свои / чужие в бою, опасность, похвала.
  • Интерфейсных элементов (второстепенная кнопка менее контрастная чем, основная);
  • Атрибутов игровых сущностей, например нации танков (в игре танки каждой наций имеют свой цвет).

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

Шрифтовая система (мета)

Здесь более менее все понятно:

  • Набор гарнитур и начертаний;
  • Форматирование. Стили оформления заголовков, основного и дополнительного текста, подписей и пр.;
  • Сетка и отступы.

Система написания интерфейсных текстов (мета)

Что может описывать эта мета-система:

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

Например, как правильно называть танки? На самом деле не все “танки” в игре являются танками, есть артиллерия и противотанковые установки. Для именования каждого вида сущности вводятся специальный термины. Например, когда речь идет обо всех типах танков, в интерфейсе употребляется слово “техника”, когда надо указать отдельный тип техники, употребляется “легкий танк” или “САУ” и т.д. При этом важно соблюсти эти правила во всех уголках интерфейса.

Функциональная анимация и звуки (мета)

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

  • Звуки “навешиваются” на кнопки и человек имеет дополнительное подтверждение действию (кнопка действия имеет один звук, а отмены — другой);
  • Звуки сопровождают нотификации, чтобы обратить на себя внимание (новое сообщение в чате, сообщение о результатах боя или о том, что бой начался). Причем разные события могут кодироваться различными звуками так, что человеку не нужно смотреть сообщение;
  • По окончании боя в окне его статистики проигрывается музыка, которая зависит от результата боя;

Мета-система анимации может содержать стандартные решения, которые будут использоваться в части UI-компонентов, например:

  • Чтобы сделать интерфейс более “живым” мы можем использовать анимацию появления контента в окнах. Как только игрок открывает окно, контент в нем появляется не сразу, а с небольшой задержкой из прозрачности и с движением с последующим замедлением. Как мета-система, это правило распространяется на все контейнеры в интерфейсе;
  • Для привлечения внимания игрока к отдельным элементам интерфейса используется мигание. Например, когда игроку пришло сообщение в чат, мигает его вкладка, когда в списке боевых задач появляется новая задача, она мигает.

Навигация

Концепция и правила навигации — это то, как человек будет перемещаться между разделами нашего интерфейса, как возвращаться обратно и как вызывать функции. Например, в веб-сайтах мы в основном перемещаемся по основному меню и по ссылкам, а назад возвращаемся с помощью кнопки “назад” браузера. В старых версиях Windows каждое открытие новой папки приводило к открытию нового окна, и лишь потом появилась навигация внутри одного окна с помощью кнопки “назад”. В современных тач-интерфейсах большой кусок навигации — это жесты.

В “танках” смешана концепция экранов и окон. Также есть особые игровые механизмы, типа трехмерного ангара и “карусели” танков, а также концепция отправки в бой один клик (т.е. из любого места в интерфейсе).

Что может относиться к вопросам навигации с точки зрения системы:

  • Основные принципы навигации. Как человек будет перемещаться по разделам, как возвращаться назад, может будут элементы, доступные отовсюду;
  • Устройство и работа навигационных компонентов: основного меню, кнопки “назад”, табов. Правила их применения;
  • Правила взаимодействия с окнами (если они есть), правила расположения окон по оси Z, выделение, перетаскивание окон;
  • Навигация с помощью клавиатуры. Например, перемещение по списку с помощью кнопок “вверх” “вниз”. Кнопка ESC (в танках закрывает последовательно каждое открытое окно и в итоге приводит сначала в “ангар” (основной экран лобби игры), а затем выводит системное меню) ;
  • Правила для дизайнера, например, какой тип контейнера лучше использовать для определенной фичи;
  • И многое другое.

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

Правила формирования лейаутов

Правила формирования лейаутов описывают законы, по которым контент размещается в контейнерах.

Часть этих правил являются мета-свойствами и зашиты в компонентах. Например, расстояния от краев контейнера до контента.

Красным обозначена область контента

Часть правил являются советами для дизайнеров. Например, какой тип лейаута использовать в том или ином случае:

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

Часть правил являются паттернами. Например, способ отделения одной части экрана от другой в рамках одного окна.

Правая часть находится на светлой подложке и визуально “возвышается” над левой

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

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

Инструменты

Инструменты — это функциональности, решающие задачу пользователя, которые могут использоваться в разных контекстах, формируя при этом множество возможных сценариев.

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

Примерами инструментов могут служить:

  • Контекстное меню на разных сущностях и функции которые из него вызываются. Например, из контекстного меню ника игрока, которое вызывается кликом на ник, вы можете начать с ним чат или посмотреть его статистику. Этот фокус можно провернуть в любом месте интерфейса, где вы встретите ник;
  • Стандартизированный фильтр танков. Списки танков одни из самых часто встречающихся элементов в сервисных интерфейсах, а количество танков уже приближается к 500. Контексты, в которых встречаются списки танков очень разнообразны. Так что иметь стандартизированный способ сортировки и фильтрации — это путь к эффективному взаимодействию;
  • Любой интерактивный элемент или игровая сущность в игре при наведении покажет тултип или инфотип. Это помогает человеку найти ответы на многие вопросы;
  • Перевод золота в кредиты. Игрок может по собственному желанию вызвать окно покупки кредитов. Но, если у него не достаточно денег на покупку чего-либо в магазине, то тот же самый интерфейс будет ему предложен системой;

Ниже приведен пример того, как игроки при отсутствии специально спроектированного сценария сравнения танков с помощью простых инструментов (окон с описанием танков) решают свою задачу:

Для сравнения игроки ставят рядом открытые окна с характеристиками танков (окна в игре перетаскиваются, как в Windows или MacOS)

Я не говорю, что данный пример — это хорошо. Это просто иллюстрация понятия “инструмент”.

Система отображения игровых сущностей

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

Возьмем для примера технику. Вот небольшая часть ее атрибутов:

  • Внешний вид танка;
  • Название танка;
  • Нация танка (СССР, Германия, США и т.д.);
  • Тип техники (легкий/средний/тяжелый танк, ПТ, САУ);
  • Уровень (от 1 до 10);
  • Статус (исследован/не исследован, есть в ангаре/нет в ангаре , элитный, премиумный и пр.);
  • Наличие экипажа, боеприпасов, снаряжения и пр.;
  • Наличие утроенного опыта за первый бой;
  • Технические характеристики и др.

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

Слева направо: “карусель”, статистика по моим танкам, дерево развития
  • Игрок распознает танк по изображению и по названию. Изображение танка встречается в интерфейсе в нескольких размерах, но выполнены максимально похожими;
  • Нация танка закодирована цветом (серые — Германия, зеленые — СССР), а также флагом (в “карусели” — фон, в таблице — отдельным столбцом);
  • Уровень танка везде обозначается римскими цифрами;
  • Тип танка обозначается иконка перед римской цифрой;

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

А для того, чтобы человек смог пользоваться этим алфавитом, необходимо соблюдать его консистентность на протяжении всего игрового опыта.


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

“Карусель” танков. Здесь отображено 10 атрибутов. Попробуйте найти все.

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

Что конкретно нужно делать, чтобы реализовать системный подход в своем проекте

  • Прежде всего понять, нужно ли это вашему проекту и команде на данном этапе;
  • Понять, какая степень проработки системности требуется. Возможно, вам достаточно стилевого UI Kit-а;
  • Договориться со всеми участниками процесса о том, как вы будете это делать. На уровне дизайна, технологий и процессов. Помните, что это очень непросто;
  • Создать систему))) Методика ее создания заслуживает отдельной статьи и у каждого она может быть своя. Можно создавать систему параллельно с привычным вам проектированием выделяя повторяющиеся куски и закономерности, а затем унифицировать их. Но помните, что в таком случае при проектировании вам придется думать сразу обо всех экранах и состояниях элементов;
  • Поддержка. Система не статична. Вы постоянно будете ее допиливать и переделывать. Возможно, некоторые компоненты в итоге исчезнут, у других изменится поведение, добавятся новые сущности. Если система поддержана на технологическом уровне, то вам будет в разы проще;
  • Определите правила, по которым вы будете вносить изменения. Нет смысла, если систему может изменять любой специалист при первом желании и в любое время. Каждое изменение должно быть взвешенным и система должна стремится к минимальному, но достаточному количеству компонентов и правил;
  • Определите, как технологически вы будете поддерживать системность. Есть несколько способов: 1 — железная воля дизайнеров и программистов (когда специалисты знают в уме, как надо сделать), 2 — гайдлайны, т.е. описания, как можно делать и как нельзя (это уже можно расшарить с другими спецами), 3 — имплементация на уровне кода (вам останется только “настраивать” интерфейс). Об этом написана большая статья про платформенное мышление у Юры Ветрова.

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


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

Обсуждение статьи в Facebook в группе UX club

Если вам нужно спроектировать интерфейсы или продукт целиком, то вы можете обратиться ко мне. Я работаю над софтовыми и хардварными продуктами. Портфолио и контакты на моем сайте.

Мой аккаунт в FB

Ilya Aleksandrov

Written by

UX designer

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade