Skip to content
End Users-1
6 min read

Talking to Your End Users Is Never a Waste of Time

Importance of Interviewing End Users

"We've already met with the end users, so we don’t need to bring them into the workshops. We’ll just send you our existing documentation."

We frequently hear this during project planning from clients who are looking to streamline the upcoming design process. You’ve already documented the requirements, known issues, and enhancement requests, so any more time spent interviewing end users would simply be re-work, right? Wrong.

Your business analysts, technical subject matter experts, and existing documentation are a great starting point. But we find that these resources are often too narrowly focused on specific
solutions – how to fix a problem. They miss the why – the underlying issues that are causing friction and frustration for the users.

Start With Why

If you take a problem at face value and jump straight to solutioning, you’ll get a band-aid fix that alleviates symptoms but never addresses the root of the problem (we understand that it’s tempting; solutioning is the fun, glamorous part after all!). However, a design engagement with ConvergentIS is an opportunity to make meaningful innovations rather than incremental improvements. Solving the right problem – the root problem – is key. So, we must take time to understand the problem space before exploring divergent solutions.

To get to the why, we have to talk to the people who will actually use the product. We begin our design thinking workshops with an activity we call Expert Interviews: end users walk us through their current process, using real examples and tools. The facilitator asks probing questions while the project team listens and takes notes. These notes form our common understanding of the problem space and the basis for subsequent ideation.

The Human Factor

Documentation tends to be dry and system-focused. While this is fine for reference purposes, it is far removed from the imperfect and deeply human world that your end users operate in, where work environment, past experiences, physical limitations, time pressure, personal preferences, and countless other factors all play a part in driving user behavior and outcomes. 


I liked having the users present ‘real-life’ so we could come up with new ideas in context.



Our informal, show-and-tell-style interviews allow us to:

  • Tap into your users’ wealth of knowledge. Your users are truly experts at what they do – it is their job, after all. Rarely is everything they know documented or effectively shared with others. This is an opportunity to access some of their tacit knowledge to improve understanding, training, and continuity.

  • Uncover ad-hoc processes. What happens in practice always differs to some degree from what is written in your policy binder. Without cross-disciplinary sharing sessions, management and IT are effectively blind to these discrepancies. We’ve seen some major epiphanies surface in these interviews – from gaps in training to extensive manual workarounds.

  • See the big picture. Telling a story is an easy, natural way to put events and ideas in context. Your users almost always have a list of pain points and useful ideas for improvement which come out spontaneously in the course of talking about their day-to-day work.

  • Create a shared understanding. Even the best documentation is open to misinterpretation. A candid dialogue with all the major stakeholders allows any clarifications or misunderstandings to be ironed out in real-time.

  • Empathize. Hearing about their experiences first-hand inspires empathy for users in a way that reading official documentation, or even hearing it second-hand from an analyst, cannot. Being able to put yourself in users’ shoes will help the team create innovative solutions with high adoption.
Design Thinking Reality for ERP Projects

The Design Thinking Approach to Requirement Gathering

Our facilitators also approach problems differently than how a business or IT analyst would. We use the following design thinking techniques to uncover underlying issues and unarticulated needs:

  • Beginner’s mindset. We begin with a rough outline for the interview but remain flexible, allowing the end users to direct the flow of the conversation to new and unexpected places. Since we’re outsiders, we aren’t afraid to ask the “obvious” questions. This can be helpful to uncover assumptions and challenge your business’s orthodoxies. Questioning “that’s the way we’ve always done it,” can open a world of possibilities.

  • Five whys. Users often have trouble expressing what they need, so we don’t take things at face value. When necessary, we keep digging down – asking why – until we get to the root cause.

  • Systems thinking. We look at the end-to-end process – how each step and touchpoint affect the overall user experience – to ensure it is comprehensive and cohesive. It can be hard to find the time to consider all the things happening outside the scope of your role, so we create dedicated time and space in the workshops to consider the whole system.

Often these techniques reveal process inefficiencies as well as technology issues. Instead of trying to solve a process problem with an application – the proverbial band-aid – we pool our knowledge and tweak the process to align more closely with the daily realities.

Case Studies

Here are two contrasting examples of real client projects we’ve undertaken:


  • Initial objective: Deploy a ready-made product application to warehouse operators.

  • Approach: Interview warehouse operators about how they plan their day, complete their work, handle exceptions, and communicate changes. Review existing process documentation to ensure the application meets their needs.

  • What we discovered: The process had hidden requirements that were handled outside the system by the operators and admin staff – their workarounds were not formally documented or written back to the system. Accommodating these required a major overhaul of the application. While some steps could be automated, manual oversight was still required in some areas.

  • Solution: Working closely with end-users, we streamlined the process by automating many of the manual steps and building a companion admin application to help staff effectively handle the remaining exception scenarios.

  • Result: Simply implementing the product app according to the original plan would have been unworkable. Because the client took time to stop and listen to their end-users, we were able to co-create a suite of applications that simplify and support the end-to-end process, with high user satisfaction.


  • Initial objective: Create a self-serve portal that covers six use cases.

  • Approach: The client wanted to save design time by leveraging the existing documentation and third-party business analysts. We created a design based on what we knew about the data structure and conversations with the third-party business analysts.

  • What we discovered: When we met with business users to review the design and sign off, we found out that we were totally missing the context of the business process. While what we designed would technically function, it was not at all aligned with what the end users were interested in or how they would like to use it.

  • Solution: Re-do the design, this time with business users’ input, to meet their needs and expectations.

  • Result: Creating solutions before understanding the “why” did not save time or resources, instead it caused re-work and delayed the project.


In Conclusion

Your end users will ultimately decide whether a project succeeds or fails. If the product doesn’t fit their needs, it will fail.

We favour a pragmatic approach: instead of making assumptions about how end users work, let’s go straight to the source and just ask them. Expert interviews are quick and efficient, low-risk and flexible, while still providing vivid detail and real-world insights.

Existing documentation is a great starting point, and your technical subject matter experts and business analysts will be invaluable resources throughout the latter stages of the design process. However, as good as they are, they usually have blind spots that might not be obvious until it’s
too late.

True time and cost savings come from understanding your end users and getting it right the first time. Only by bringing together diverse stakeholders and listening to real end users can we achieve innovative products that are feasible, desirable, and viable.

To learn more about the design thinking process and how it can help your team's next project, we encourage you to read the first blog in our series, Why You Should Care About Design Thinking.