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

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

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

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

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

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

repost

15

input message

напишите коммент

еще контент в этом сообществе

еще контент в этом соообществе

войдите, чтобы увидеть

и подписаться на интересных профи

в приложении больше возможностей

пока в веб-версии есть не всё — мы вовсю работаем над ней

сетка — cоциальная сеть для нетворкинга от hh.ru

пересекайтесь с теми, кто повлияет на ваш профессиональный путь