Обычно мы живём в парадигме, что у нас мало пользователей, поэтому количественные исследования затруднительны и в целом мы на цифры не смотрим.
И ещё есть мнение, что хороший дизайн на метриках не построишь.
Я с этим согласна, но метрики нужны для другого.
Во-первых, проверить, сработали ли идеи, это нужно для себя и для собственного роста. Во-вторых, для разговоров с продуктовой командой и бизнесом (защитить решение, затащить идею,
Метрики бэкофиса можно разделить на 4 основные группы. Удовлетворённость пользователей, производительность, ошибки, метрики относящиеся к дизайн-процессу.
С продуктовыми метриками они соотносятся примерно так: производительность (эффективность) влияет на финансовые показатели, метрики ошибок почти одинаковые, метрики дизайн-процесса влияют на ttm (time to market).
Самое сложное, но очень важное — объяснить как удовлетворённость пользователей влияет на продукт. Часто встречается контраргумент: у пользователей нет выбора, это их рабочий инструмент, поэтому их удовлетворённость не критична. Сложно представить, что пользователи станут саботировать свою работу из-за неудобного интерфейса.
Но когда мы хотим проверять продуктовые гипотезы, затаскивать новые бизнес-процессы или подключать другие группы пользователей — вот тут удовлетворённость начинает играть большую роль, потому что при проблемах будет сложно понять, это просто гипотеза не подтвердилась или дело в другом.
Как их мерить — отдельная тема, постараюсь когда-нибудь расписать подробнее. Но что важно: многое можно померить без систем аналитики и без привлечения разработчиков, хватит опросов и даже интервью.
И ещё, метрики нужны только для работы внутри продукта, рисовать их для красоты кейса в портфолио — сомнительная история, требовать их на собесах — ещё более сомнительная.