A UX researcher’s story of a highly usable product — that (never) got used
There I was talking to these users at the end of the usability sessions…
“It is very easy to use” they said. I would ask “Would you use it in future?”
They looked a bit embarrassed :
“It looks really nice,” they would say, pointing to the new product our company was just about to roll out.
“So why would you not use it?” I would ask.
“Well, it’s not really what we need, is it?” And then they would go on to explain…
This article is not about how to do user research, but it is about what (might) go wrong if you don’t do user research.
Background to this story is that I was pulled into an agile development team a couple years ago and I was asked to do usability testing. The product was about to go live with a selected group of users and they needed to identify what needs iteration in designs.
Imagine the following scenario. You run a bunch of restaurants distributed across the country. You spend way too much time trying to find the right staff for service, kitchen and cleaning. It would be great if someone found a solution to this problem so that you can spend your time on more value added activities.
And that was the product I was working on — A product that would connect you as the restaurant owner with the agencies that supply restaurant staff for kitchen or service. Marketplace for staffing agencies. (This is a pseudo version to keep the privacy.)
All sounds easy and straightforward: I was working within an agile team, conducting 5 to 8 usability sessions in each sprint and presenting the results in show and tells. At the beginning, there were lots that could be improved in terms of interface and interaction design. I’ve worked closely with the designer — We have iterated and re- tested and it seemed like we were on the right track.
It was only after a couple of sprints that I found myself in these strange conversations with the participants about a highly usable product that will likely not be used in future.
Here is why…
Surprise #1: Solving the wrong problem
In any business you have a value proposition — why should someone do business with you, use your product? The value proposition of this product was price — the guarantee that you will have access to best pre- negotiated rates.
Surely, cost management is very important. Especially, if you assume that this product will be used by the owners, you hit the nail — you are really solving their problem and improving their lives with this product.
Here is the thing though: when a waiter calls sick in the morning and the head waiter or the owner needs to find a substitute staff, the most important attribute for them was NOT the price — it was not how much it would cost. There were more important things than price like availability, suitability and ‘relevancy’ of candidates. Surprisingly, none of them were addressed by this product.
As better explained by one woners “when I am in the restaurant at 7am in the morning and I find out that one of the waiters can not show up to work at 8:15, I have to find the most suitable person for the job within an hour or so, I care the least whether I pay 15% less or more.”
Surprise #2: Serving the wrong end user
It turns out there were two potential scenarios when the staffing problems occur: One that’s super short notice — The waiter calls in sick and whoever comes to the restaurant first in the morning has to make the call to find a substitute for that very day. That whoever was the head waiter most of the time. The other type is the one when they know a bit more in advance that the waiter would be on a leave and then they can plan ahead, then this task would be carried out by the owners.
Here is the thing though: 90% of the time the problem of staffing would occur on a short notice. That means the main users, as assumed by the product team, were not only owners, the majority of the users were actually other service and kitchen personnel.
You might think so what? What does it change anyway? It still solves the staffing problem no matter who uses the product. There is plenty wrong with that, but the most obvious one is the whole interface was designed to be used by owners who have financial acumen, who would understand words like ‘margin rate’ whereas it meant nothing to the chef in the kitchen, even worse it intimidated them to use the product.
This could never happen to you…
Are you reading this and going “this is crazy — it would never happen to me. I know all about my users, I know all their contexts and all their problems”. I bet that’s what the business people/product managers in this example also thought. Yet, they ended up with a product that would likely be abandoned after first use. This was actually my first time with an experience like this, but unfortunately it hasn’t been the last time.
Don Norman, who is one of the leading thinkers on human-centered design, has a paragraph in his famous book‘ Design of everyday things’ :
“Engineers and business people are trained to solve problems. Designers are trained to discover the real problems. A brilliant solution to the wrong problem can be worse than no solution at all: solve the correct problem”.
That being said, we are here as user researchers to help you explore the problem space to ensure that you have a deep understanding of the users and customers and their context so that you are solving the right problem for them.
Did this ever happen to you? Tell me more…
