Проектирование интерфейсов
Серия 02. (Не)важность визуальных форм.

В мире дизайна интерфейсов есть несколько десятков законов, часть названа нормально, часть — в честь умных дядь и тёть, сформулировавших их в первый раз. Я не дизайнер, а моё понимание хорошего интерфейса сложилось задолго до того, как я прочитал по нему первую умную книгу. Да и вряд ли кто-то планирует сдавать экзамен, а если и так — вряд ли пост в тг правильная основа для подготовки. Так что в топку всех этих Фиттсов и Хиков,

Из мира бизнес-приложений на законы UX/UI открывается одна очевидная проблема — на них всем (почти) похрену. Функциональность всегда будет превалировать над красотой или удобством. Интерфейс будет иметь значение только если возможности системы не уступают конкурентам. Да и ПО зачастую выбирают не те люди, которые будут им потом чаще всех пользоваться. С наиболее жёсткими требованиями к интерфейсу команда разработки будет сталкиваться в инхаус-формате, когда заказчик имеет непосредственное влияние на конечный продукт.

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

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

➡️Минимизация визуального шума. Раскрашивать интерфейс во все известные цвета - плохо. Красный/жёлтый/зелёный идеально подходит для выделения важности, степени проёбанности или указания куда нажать, чтобы случилась магия. Если уж надо что-то прям разукрасить — мягкие цвета, максимально близкие к общей цветовой гамме. Много пиктограмм - плохо, особенно если понимание их смысла требует лупы.

➡️Концертировать пользовательское внимание в привычных областях и в привычном порядке. Человек уж так устроен, что ему удобно смотреть в центр чего-либо, в данном случае - монитора. Именно там следует фокусировать наиболее частые пользовательские действия. Место по краям - преимущественно для информации или навигации. Вверху или слева - для важной, внизу и справа - для второстепенной (может отличаться для культур, где принят иной порядок письма, или маководов).

➡️Снижение когнитивной нагрузки. Необходимый баланс между функциональностью (фильтры, настройки, параметры, данные), способностью пользователя её воспринимать и доступностью. Один из лучших способов управлять нагрузкой на рабочее место пользователя — определить для каждого сценария 3 возможности задать настройки: фиксированные (видны всегда), сворачиваемые (доступны без перехода в новое окно, но спрятаны «под катом») и скрытые - доступны при открытия в новом фокусе. Позволить пользователю ограниченно управлять распределением параметров между местами отображения.

➡️Подчинение сценариям. Связанные действия должны располагаться рядом. Вариации объединяться в группы. Порядок выполнения тоже имеет значение: неправильно размещать поле подбора контрагента после кнопки "Выставить счёт".

В некотором смысле создание интерфейса бизнес-приложения всегда война с пользователем. К примеру, в топе частых фраз, которые слышат 1Сники за последние несколько лет, прочно обосновалась "а вот в SAPе..." Стремление заказчика к привычному иногда может доходить до фактического бойкота, а требования добавить "ещё колонку" со временем превращают лаконичный список достаточной информации в простыню из данных, которую необходимо крутить во всех направлениях. И это опять понижает удовлетворённость пользователя от продукта по вине самого же пользователя. Этакий замкнутый круг. Работать с этим сложно, но можно. Как — в следующих сериях.

#медведьразмышляет #проектированиеинтерфейсов