A Valid Solution Needs a Valid Problem

There are two ways of building a new feature. You build them because someone told you so, or you build what users need, and the latter might be completely different than what the user story or feature request(er) tells you.

A feature is valid when you're able to connect it to a particular aspect of someone's life. It's tied to something they want to improve or some pain to get rid of. So, the first I do is to keep asking why.

"We need to support reports download." Why? "Because that has become a frequent request. "Why is it so frequent? "That's not relevant. We need to give them what they want.". Not good enough.

Secondly, I reach out to at least seven of these users who wanted to download a report. I ask them many whys until I can see the core problem behind the apparent solution.

It turns out that users take those reports and use them as part of several presentations and other group events. Afterward, they share the document by emailing it. The way they see this happening is by downloading a PDF, either to add to their keynote, either to send it to their coworkers.

My main goal so far is to create a problem statement that helps me delineate the solution. It could be something like:

When I, a Marketing Analyst, need to present and share a particular report from our CRM, but I don't know how to extract this data, help me [to be continued...], so I can stand as a data-oriented professional.

Notice that I added the outcomes they expect by solving the problem. That is part of their answer. Keep asking them why will eventually reveal what they want. Two key aspects to consider as feedback: How serious and how frequent is the situation described above?

There it is. The problem is crystal clear.

From now on, it's about finding a solution. Design work takes place, and I might present them with even more than one solution. I take the time to sit down with those same folks again; I restate the problem in a slightly different way:

When I, a Marketing Analyst, need to present and share a particular report from our CRM, but I don't know how to extract this data, help me with two versions of this report: one I can share by just copying and pasting the report's URL and one that is formated to add to a presentation, stripped down from anything besides the chart.

Sometimes, this won't even involve producing an interface, especially if you want to test different solution alternatives. The feedback I'm after at this point is how effective they perceive this solution to be. So, the key question becomes, "Is this an effective or ineffective way of dealing with this situation?" followed by "Why?".

Once I know the problem and how effective the solution is perceived to be by users who experience the pain, actual UI work starts.