How to Design Data Solutions That Actually Get Used

Dave Findlay
Jul 1
3 min read

Design isn’t just what it looks like.

People study a large digital table with charts and graphs in a modern setting. The mood is focused, with blue and orange visuals.

It’s how it works for the people who need it and how they feel when they use it.

In our previous posts, we walked through how to:

Now it’s time to design. But that doesn’t mean just drawing pretty charts or dreaming up a slick UI.

It means shaping a solution with the business — one that solves a real need and is simple enough to actually use.

Co-create, don’t just gather requirements

The business doesn’t want to “hand off” the problem and get a surprise in return. They want to be part of building the thing that will make their work easier.

That’s why we use collaborative design sessions to:

Explore what a good solution might look and feel like
Walk through real use cases and day-in-the-life stories
Sketch out low-fidelity prototypes together

You’re not promising perfection. You’re building shared clarity.

Don’t confuse features with needs

Stakeholders often describe a solution in terms of features, but your job is to uncover the underlying need. One way to do that is to channel your inner 3-year-old and keep asking, “Why?”

Example:

Stakeholder: "We need to download to Excel" ← that’s a feature.

You: “Why?"

Stakeholder: "We need to share our dataset with colleagues"

You: “Why?"

Stakeholder: “They need to provide updates based on the next steps for each deal record"

You: “Why?"

Stakeholder: "So we can make sure deals are progressing"

You: “Why?"

Stakeholder: "Because if deals don’t progress, we’re at a high-likelihood of losing to a competitor"

You: “So you and your team need to be aware of deal stage progression and be able to identify stalled deals early, so you can mitigate risks that could prevent you from winning the business.” ← that’s a need.

Now we’re getting somewhere.

The real need isn’t Excel. It’s visibility into deal progression to reduce risk and increase win rates.

There are multiple ways to meet that need and now you can work with your stakeholder to design the features that will meet their core need.

Good design doesn’t just deliver the requested feature. It solves the real problem, in the best way for the context.

Use MosCoW to prioritize feature ideas

During design, you’ll uncover far more ideas than you can realistically build, and that’s a good thing. But you need a way to focus.

We use the MosCoW framework:

Must have – Critical to delivering on the core need
Should have – High value, but not absolutely essential
Could have – Nice-to-haves if time allows
Won’t have (for now) – Useful ideas that won’t be in this cycle

Once you’ve categorized the features together, the data team can provide an early estimate of how far down the list they can reasonably go during your current delivery window.

That becomes your target for version 1.

Everything else gets parked on the roadmap, ready for a future iteration if and when the governance committee decides to move it forward.