Когнитивная нагрузка интерфейса и почему этим нужно управлять

[DvoiNic]

а что такое "Что такое когни...влять.docx"?

[Kekero]

Нейросетка, которой дали на откуп редактуру, в ступор впала🤣

[BrokenDawn]

Да, вычитка - это и правда долго. А статья первая. Спасибо что так внимательно изучили и дали обратную связь)) Мне приятно

[pomni]

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

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

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

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

Хотелось бы увидеть разбор хотя бы одного конкретного экрана любого продукта 1С, с которым вы регулярно работаете. Например:

• какие проблемы есть у этого экрана с точки зрения пользователя;

• какие ошибки или избыточную когнитивную нагрузку он создает/какой сценарий использования;

• какие изменения были предложены и реализованы;

• как проверялось, что стало лучше, а не хуже.

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

В целом статья напоминает ситуацию из серии: «Я хожу и наблюдаю, как люди кормят уток в парке. Эти утки кряквы. А вот еще вода в реке, где кряквы грязная, но вернемся к кряквам. Кто такие кряквы, какие они бывают, почему их нельзя кормить хлебом и чем кормлю их я».

[BrokenDawn]

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