Насколько я понял, речь про закрытое производство и операторов.
Вывод первый: это профессиональная тула и речи про всякие воронки, конверсии не стоит вести.
Есть возможность найти исходные цели, с которыми проектировалось приложение?
Должны же были удостовериться, что сделали верно. По идеи, оттуда метрики и стоит взять.
Если этого совсем нет, звучит как дискавери фаза - надо заново понять несколько вещей:
1. Кто сказал что интерфейс неудобен? Кто сказал, что есть проблема? Почему её надо решать?
2. Затем - для кого решать? Хорошо, если этот оператор один, но обычно есть супервайзер, а над ним ещё и менеджер, который распределяет нагрузку. Это уже создание и работа с персонами.
3. Экраны - они часть процесса, нужно получить весь процесс. Мы делали целую AS-IS Workflow диаграмму, где искали узкие места и непонятные белые пятна. А это недели работы.
4. Условия работы - операторы могут работать в костюмах биологической защиты с баллонами кислорода и масками, а могут быть на заводе в пыли и температуре +40°С.
Блин, вопрос не средний на самом деле и ответ на него тянет вполне себе на статью\доклад на конференцию.
Дальше уже на аудит похоже будет - без доп контекста не взлететь.
А исходя из обычных метрик, всегда можно найти вторую сторону монеты:
Одно время лишь порождает кучу вопросов: критично ли оно? Завязано ли на количество ошибок? Лучше дольше, но без ошибок, чем быстрее и с бОльшей когнитивной нагрузкой? Насколько сложен процесс и сколько ему учат оператору? Какой изначально путь выбран в системе? Например, для оператора атомной станции время критично только при авариях, в остальном это мониторинг систем.
Я считаю без мат части и деталей нормально посоветовать что-то бОльшее сложно будет.
