Don’t Just Ask. Engage!

To me, the theme of “Users First!” (and yes, the exclamation point is obligatory) speaks to the centrality of end users in much of our work. Whether it’s providing customer support, fixing software bugs, or (re)designing business processes, the end user experience is the measure by which define our success. Or it should be. After all, the whole point of our work (be it a project, application, service, etc.) is for it to be used by and useful to its intended audience. And yet, we often hear about, and sometimes get to experience, a kind of disconnect between the work we do and how our users experience it. How do we bridge that gap?

One obvious way, I’m told, is to just ask. “Ask your users, they’ll tell you what they want.” Yes, but I think there’s more to it than that. To my mind, the “just ask” approach is as true and important as it is incomplete. Having meaningful dialogue with your users requires context, trust, and regular communication. Traditional methods like surveys and focus groups are useful, but you need more than that to understand where your users are coming from. You need to get out there and observe, see how people work and use your product or service. Talk to people, engage with them. What are their challenges, what features really matter in their actual use of your service?

And don’t stop there. What does an outage feel like for them? Sure, you can guess what people do (or don’t do) if your service or program is unavailable. But how do your users cope? What doesn’t get done? Do they have any workarounds? You may be surprised by the ingenuity of local, ad hoc alternatives that spring up to address unmet needs. The point is, you want to understand what really matters to your users; and you also kinda want to feel their pain and know what it’s like to be in their shoes. Fuller engagement will help you understand your users and your work better. And they’ll appreciate knowing you understand them.

Put another way, where are users in the classic RACI model(which ascribes roles for parties that are Responsible, Accountable, Consulted, Informed) Sure, end users are almost never the R or A (and shouldn’t be, they have day jobs and lives to lead), but they should be in the C and I groups. It’s a common mistake to treat Consulted and Informed as throwaway categories, thinking the “real” work gets done by the Responsible and Accountable parties. But that’s not quite right. Doesn’t it make sense to regularly consult with and inform your users? If you build checkpoints into your work that allow for meaningful consultation with your end users, you begin to see the value of the full RACI model.

Sure, your developers, and BAs, and project managers are working hard and keeping busy; and it may feel like there isn’t always time to check in with your users. But your hard work is all the more reason to make sure you’re on the right track and are working on what they perceive as valuable and the right priority. Properly construed, the role of a consulted party can add real value by lending an outside perspective and providing useful and timely feedback. It’s also a good reminder of why you’re doing the work in the first place. The same goes for informed parties. When was the last time your users said they were too informed about your service or project?

And engaging users is not just a nice thing to do, it’s smart, too. Making sure your work is aligned with users’ needs and expectations can avoid headaches later. And if your users are engaged in the process, they’re more likely to forgive mistakes or unavoidable delays. Being engaged in a process makes all participants invested in the outcome, even if they didn’t participate in the actual decision-making. And even if they disagree with something you’re doing, an engaged user at least knows they were listened to and taken into account. 

What about you, is user engagement baked into your processes? How have you engaged users in your work? Has it paid off, either by soliciting actionable ideas, offering different perspectives, or even just making users feel like they matter? 


‘Consult’ should not translate as asking users what they want in an application.  That can generate a long list of feature requests – but it is not the end-user’s job to know what features an application should offer – that is the developers job.  The questions to ask are ‘What do you need to accomplish?’ and ‘How do you measure success’.  Even better is to observe them in current processes to find the gaps, choke points, and other systemic problems.  This allows a focus on identifying the actual problem, and avoids a rush to solve with a list of desired features. 

Agreed. The idea of “consulting” your users is that it should be a two-way engagement (as opposed to Inform, which is a one-way communication). And it can be iterative. At various points, you should build in consultation or review with your users, which can be a conversation, observation, demo, etc.

Ricardo’s post suggests that we should solicit feedback from users not just once during a development project but “at various points.” I agree, but we’ve struggled sometimes to determine the best points in a project to bring in the target audience for input, and also the best type of input to solicit at different points.  Any thoughts on when, during a typical development cycle, to get which types of information from users? 

So true, and so important!!  Understanding “why” a user needs functionality is invaluable to the development of a feature.  The developer or BA gains insight into the business use of the product, and can then make informed decisions about the way something is displayed, calculated or tested.  So often the user is included for requirements-gathering, but never asked for the purpose or application of the product.  Learning “why” from the users goes a long way to making a feature effective and avoiding defects.