Чем отличаются профессиональные системы от массовых

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

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

Вместе с тем, я до сих пор не уверен, что сам термин «профессиональные системы» корректен. Можно даже предположить, что нет никаких профессиональных систем как таковых — в конце концов, взаимодействие с какой-нибудь АСУ ТП или рентгеновским аппаратом посредством компьютерного терминала мало отличается от взаимодействия с Фейсбуком — те же кнопки, те же принципы визуальной иерархии и акцентов, те же метрики юзабилити.

Но, с другой стороны, очевидно, что управление рентгеновским аппаратом — не то же самое, что листание Фейсбука. А значит что-то отличное все же есть. Поэтому возьмём за основу рыхлую аксиому, что профсистемы существуют и отличаются от массовых по подходам к проектированию, и попробуем таки поковырять эту тему.

Проблема идентификации

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

Как следствие, собрать их под одну гребенку трудно.

Получается, что сам термин «профсистемы», родившийся в UX-тусовке — лишь попытка каким-то словом назвать очень разные системы по факту, а не по замыслу — и она сродни попыткам классифицировать музыкальные группы по жанрам. Где-то когда-то собрались несколько человек в гараже и стали бацать музыку на консервных банках и железяках с дешевой драм-машиной, а потом в другой точке мира совсем другие товарищи тоже стали что-то делать нечто похожее (точнее, такое же непохожее на то, что делали до них). Уже потом слушатели и критики придумали им некое общее имя — «индастриал» или «пост-рок». Однако возьмем Nine Inch Nails и Throbbing Gristle — что одни, что другие хоть и называют индастриалом, но что общего у них? Хотя это явно не рок-н-ролл, не танцевальная электроника и не хип-хоп.

В общем, больше не будем копать в эту сторону.

О подходе

Поэтому я решил пойти немного другим путём — описать наборы факторов, которые делают конкретную систему «профессиональной» в той или иной степени. Чем больше факторов встречается у неё — тем, значит, более она «профессиональна».

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

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

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

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

Фактор 1. Использование для работы

Основная задача профсистемы — поддерживать какую-либо профессиональную или иную процессинговую (нацеленную на получение результата) деятельность пользователя, помогать ему в ней — или даже делать принципиально возможной. Конечно, это не обязательно исключительно работа как то, за что платят зарплату — это может быть и сложное хобби и иное занятие (например, система для построения чертежей, используемая при строительстве дачи и для 3D-печати).

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

Следствие 1.1. Эффективность важнее эффектности

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

К слову, самим пользователям также довольно всё равно на то, насколько «актуальна» стилистика продукта, в отличие от дизайнеров. Главное чтобы она не была вырвиглазной и не мешала воспринимать информацию и работать с системой — хотя, как всегда, и тут есть свои «но», чтобы давать однозначное суждение. Если, конечно, сами дизайнеры не являются пользователями этой профсистемы.

Следствие 1.2. Многоролевая модель взаимодействия

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

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

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

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

Следствие 1.3. Широкий диапазон кастомизации

Учитывая что разработка подобных систем является довольно дорогой, ресурсоёмкой, а область автоматизации — весьма сложна, то разумно предположить, что одна система делается для самых разных эксплуатантов (с позиций UX, сложно назвать какой-нибудь горно-обогатительный комбинат «пользователем»).

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

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

Фактор 2. Сложная предметная область

Часто профессиональные системы не «вещи в себе» (как многие выстрелившие в свое время массовые продукты типа Instagram, Facebook, мессенджеры и т.п.) — они существуют в сложившихся предметных областях с большим объемом знаний — многие из которых были накоплены задолго до появления не только каких-либо систем, но и даже компьютеров как таковых, и далеко не все из этих знаний можно автоматизировать очевидным образом. Иногда это наследие может быть негативным, тормозя развитие новых подходов (вспомним только проблемы с переходом на электронный документооборот), но чаще всего оправдано — резкие изменения могут приводить к непредсказуемым рискам.

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

Тут стоит отметить, что приложения могут быть посвящены узкой предметной области, а могут быть и универсальными, но посвященными какой-либо конкретной задаче (их иногда называют инструментальными). Это, например, могут быть достаточно универсальные текстовые редакторы (MS Word или Pages), а могут быть текстовые редакторы для писателей, учитывающие процессы создания художественной и нон-фикшн литературы (Scrivener). Причём расширенные возможности и характеристики универсальных приложений (которые люди «со стороны» могут, не зная, начать критиковать за громоздкость или фичеризм) также могут быть признаком профессионального ПО — хорошей аналогией является разница между любительскими ножницами и профессиональными ножницами парикмахера с разницей в цене на пару порядков.

Следствие 2.1. Необходимость тренингов

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

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

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

Следствие 2.2. Большие объемы данных

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

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

Фактор 3. Критичность последствий ошибок

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

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

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

Следствие 3.1. Регулирование и сертификация

Разумеется, следствием высокой критичности последствий является пристальное внимание к безопасности и надежности подобных систем со стороны государства, различных ассоциаций эксплуатантов, да и международных регуляторов, типа IMO, ICAO или МАГАТЭ. В масс-маркете принято морщить носы от упоминаний стандартов («ограничивают свободу своими идиотскими требованиями»), но меж тем они в основном предназначены для задания минимально необходимого уровня качества систем.

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

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

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

Фактор 4. Нетиповые контексты использования

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

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

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

Из этого фактора следует несколько очень важных других.

Следствие 4.1. Аппаратные средства выбираются для системы

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

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

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

Отдельно стоит отметить, что сами системы могут быть неотделимы от аппаратных средств — например, профессиональная кинокамера, осциллограф или аппарат УЗИ.

Следствие 4.2. Наличие сопряжений с внешним миром

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

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

Следствие 4.3. Работа в реальном времени

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

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

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

Фактор 5. Пользователь — не покупатель

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

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

Разумеется, исключений много, но даже в случаях личного применения мы бываем ограничены в выборе — например, если результат нашего труда применяется другими. Например, всё сложнее продолжать проектировать сайты в Axure, когда все вокруг ждут макеты в Figma.

Следствие 5.1. Отрицательная мотивация пользователя

У указанного выше фактора есть очень важное следствие, которое очень трудно представить в масс-маркете (если только мы не имеем дело с продуктом монополиста) — пользователь системы может откровенно ненавидеть её, но продолжать вынужденно ей пользоваться, например, чтобы просто не потерять рабочее место.

Следствие 5.2. Массовый продуктовый маркетинг не работает

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

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

Разумеется, потом это аукается, но коммуникативные барьеры могут приводить к тому, что при наступлении проблем во всём обвиняются операторы или какие-то внешние обстоятельствам, а значит проблемы пользовательского опыта и его влияния на эффективность/безопасность остаются маскированными, пока не случится что-то совсем серьёзное (вспомним недавние авиакатастрофы и последующие проблемы у одного крупного авиапроизводителя). Законы B2B-рынков, что уж сказать.

Вместо итогов

Это, конечно, не единственные факторы, типичные для профессиональных систем. Но они характерны для многих из них.

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

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