When we create data tools and products, our aim is for them to be used by the people we’re designing them for. Seems straightforward, right? Well in practice, a few things have to go right to build a product that’s actually useful for people.
Here are three important factors to consider when building something that your customer will genuinely use.
Start by Recognising Key Limitations
If you’re tasked with “automating” a complex data analysis and report generation process, it’s wise to ask yourself whether simplifying one part of the process would be more beneficial than completely replacing everything.
Remember that our stakeholders also have their own stakeholders. Certain aspects might be unchangeable or require extensive buy-in from parties you can’t easily access. Outputs or reports might need to maintain a certain appearance or format, which is non-negotiable. Ensure that whatever you create can produce these required outputs. Cover this during your requirement gathering sessions. Understand your client’s obligations. Not addressing this from the beginning leads to wasted effort and resistance, even if the existing process is slow.
Prioritise User-Friendly Design from the Start
Your objective is to make things easier for your end users, not burden them with learning something new. The user interface (UI) of your data product should reflect this goal. New products should be easy to use, tailored to the user’s data literacy level, and visually appealing. Ask yourself: Does my tool or app need an instructions page or manual? Can I expect my average user to use this tool without extensive guidance?
Building wireframes for data products often becomes an afterthought, but it’s a critical part of the process. Wireframes set expectations and ensure everyone understands what will be delivered. Don’t skip this step! Develop wireframes and, if possible, interactive prototypes (tools like Figma work well). Conduct a UI workshop with your client or end user, observing their interactions with your wireframes and prototypes. Note where they encounter difficulties and inquire about their assumptions while navigating your designs. Do not just email the wireframes and hope for meaningful written feedback!
If your team lacks a designer—or if you are the designer, the product manager, the project manager, and the developer—I highly recommend reviewing Google’s Material Design resources. Using familiar patterns goes a long way towards making your product easy to use. Remember, adopting new software always has a cost for users. They use consumer products every day that adhere to specific guidelines.
Your client is a liar, sometimes… Unintentionally
Asking people whether they’d use a data product is the worst way to get their feedback. Rob Fitzpatrick discusses this in “The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you.”
Here’s an example: while on holiday in Porto, I took part in a survey from the Porto Tourism board. One question rated the importance of visiting museums and galleries when visiting a new place using a Likert scale. Despite marking “very important,” I didn’t actually visit any on that trip. In fact, I can’t recall the last time I did got to a museum when I was away on holiday. My stated behaviour differed from my actual behaviour. Thinking something was important wasn’t enough to motivate me to actually do it.
Accepting everything clients say at face value is risky. It’s easy to become a feature factory, draining your energy and resources. During the requirement gathering phase, schedule a session with your client or stakeholder to walk through their current process (if automating data extraction or processing). This reveals what works well, what doesn’t, and where the most time is spent. Also, use this time to identify their deal-breakers (as discussed earlier). Action yields information, so establish your requirements based on this information from the start to avoid building something ultimately ineffective. An easy way to combat this is to get to something that they use as part of their processes as soon as possible and iterate from there.