Talking to Your End Users Is Never a Waste of Time

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.

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:

USER RESEARCH TAKES AN UNEXPECTED DIRECTION

• 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.

THE FALSE ECONOMY OF SKIPPING USER RESEARCH

• 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.