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?