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

Рассмотрим, как можно отслеживать результат/успешность решений для проектов, где данные для проверки почти отсутствуют.

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

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

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

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