7

Huzzah! You just launched your brand new feature/product X. You've been working on it for months, usability tested the crap out of it, and feel really good about how it all came together.

After a few days you become impatient that no one has mentioned your new feature. No one loves it. No one hates it. Maybe no one even cares at all.

How do you answer the question: is the thing that I just built actually helping anyone?

That can be hard to answer qualitatively. What if you knew, "2% of people have used feature X?" Is that any better? What about 10%? Are we getting warmer [and helping users achieve their goals] or just making it more likely for X to be used?

Knowing the answer also helps you build better features and products in the future.

How do you use data to help your teams build better products?

noluckmurphy
  • 2,580
  • 1
  • 17
  • 19

5 Answers5

4

just a few random thoughts...

If possible, you could build a function into your website/product, so that actual use is measured. This would of course be interesting data for every product, not just new features. Could be used to prioritize usability efforts for example. You could even make the product simpler by removing unused features -- without the data, convincing a product team to remove things can be nearly impossible.

But any single number is useless without context and comparison, so you would need to collect the data before and after changes, or even continuously.

Come to think about it, how does my company get along without "anomynous usage data"?

4

I find it easier to ask this question before we build the feature. If we have our success criteria before we start designing then it becomes much easier to figure out whether we've succeeded or not, and it also helps drive the design process in the right direction.

adrianh
  • 10,338
  • 2
  • 24
  • 39
  • Follow up: do you work on agile team(s)? If so, how would you attempt to answer, "how much usage/adoption is good? how much is bad?" I feel like I'm pulling numbers out of my ass when we're looking at brand new stuff. It's much easier when you're trying to improve upon something you already have metrics for. – noluckmurphy Aug 23 '10 at 14:37
  • Usage or adoption, in itself it not necessarily the right measure. What business problem is your product trying to solve? What is the reason the product exists in the first place? eg. A co. I work for has goal of reducing errors on customer applications. They redesigned a form and 50,000 per month switched from paper. The error rate didnt really go down though, customers were still not providing all the information needed. Usage is not a problem here, the design of the form is. – Nathan-W Aug 23 '10 at 19:58
  • Spend less time on X, more on Y. 2. Win more Z.
  • Some of these metrics are outside the boundaries of the app. However, I realize I need to align my measurements with these intrinsic (to the customer's process) goals. Ultimately everything we do should be helping those two things

    – noluckmurphy Aug 24 '10 at 13:20
  • @Kyle With agile teams look to the stories that you're implementing. Each story should be delivering business value. Each of those stories should have acceptance criteria. Ask your business owner what they would consider success/failure for that bit of business value. You might also find googling around "Customer Development" and "Lean Startup" gets you some useful ideas. – adrianh Aug 24 '10 at 14:33