Shaping Satisfaction: How to Preempt Adoption Challenges

Every Cause Has a Source

When discussing user adoption you’ll often hear us talk about user satisfaction. And, taking it a step further, you’ll also hear us underscore the importance of causality. The point being, measuring satisfaction is one thing, but to understand what drives it — so we can nurture and develop it — we need to pinpoint its cause.

But there’s one more thing to consider: source.

Basically, in order to generate user satisfaction, causality tells us what to focus on — but source tells where and when. More importantly, understanding the time and place of causality helps us to remedy low user satisfaction, or better yet, to avoid dissatisfaction altogether.

Now, exactly where is this magical source we’re talking about? Upstream, that’s where!

So let’s take a look upstream to some of the key moments in a typical deployment cycle, and see what we can learn while up there to foster user satisfaction — and to preempt adoption challenges.

Resources: Securing the Right People & Skills

Suppose we’re experiencing low user satisfaction. Where did that originate? Surprisingly often it starts right at the beginning, when we’re assigning resources for the entire initiative.

We can’t emphasize this enough: identifying and allocating the right people, with the right skills, is a make-or-break decision for all aspects of the initiative — and certainly for ensuring user satisfaction and adoption.

This begins with Leadership: which means defining a clear destination for the initiative with shared consensus across teams, sponsorship at all levels, and definition of a core team that has intimate understanding of business processes and visceral knowledge of the enabling platform.
It continues with Roles: meaning the subject matter experts (SMEs) that are designated and assigned to the initiative. These provide the knowledge trust to represent the needs of the broader user community. Securing the right SMEs, and accurately capturing their input, will be critical since they speak for all users.
And it depends heavily on Skills: satisfaction can’t be created by proxy, and it can’t be compartmentalized — the core team has to manage it and do it themselves. This requires a broad and deep skill set, especially for the core team, spanning the range from business practices and processes to solution configuration details, augmented by extraordinary problem-solving and communication

Requirements Gathering: Capturing the Essence of Helpfulness

Shortly after securing the right resources, solution initiatives typically move into a requirements gathering phase. The idea being, with the right representation from the right subject matter experts (SMEs), the organization will be able to capture and prioritize the right needs and requirements that will successfully serve the broader user community.

Which is a great idea in theory — that often falls short in practice.

Fortunately, it’s relatively easy to pinpoint whether satisfaction issues originated during requirements gathering. A few survey questions to the SMEs that participated in requirements sessions can shed a lot of light, for example:

Do you believe the requirements gathered during requirements gathering sessions properly reflect your team’s needs? (Shown above)
Do you believe the most appropriate subject matter experts, with the most relevant knowledge, participated in the requirements gathering sessions?
Do you believe your input was taken into consideration during the requirements gathering sessions?
Do you believe that the formal documentation resulting from the requirements gathering sessions accurately captures your team’s needs?

Unfortunately, by the time we realize what happened, the damage may be done. Lackluster requirements that don’t properly reflect user needs may already be configured into the solution.

But here’s the good news: there’s always time to pause, learn and adjust how requirements are gathered. And, this kind of readjustment is exactly what will avoid lackluster requirements in the next iteration of a multi-iteration deployment cycle.

Testing: Validating Features, Capabilities & Context

After requirements are gathered, designed and configured, there’s typically a series of testing cycles that occur. Specifically, user acceptance testing (UAT). That’s where users test and validate the accuracy and robustness of the configured solution with respect to requirements, typically by following tightly orchestrated use cases, scenarios and test scripts.

Once again, it’s relatively straightforward to understand if the source of satisfaction issues is related to problematic testing. Survey questions to UAT participants can readily uncover the story, for example:

Do you believe the tests performed during the user acceptance testing (UAT) sessions properly verified the solution’s functional capabilities? (Shown above)
Do you believe participants were well prepared with respect to the testing methodologies and scripts employed during the UAT sessions?
Do you believe testing materials (e.g. scripts, instructions, cases, scenarios) used during UAT sessions were accurate and complete?
Do you believe testing results were properly reported and followed-up after the UAT sessions?

Questions such as these will give an early warning if the configured solution doesn’t conform to requirements – and more importantly, if the solution doesn’t work well within the context of day-to-day user scenarios and use-cases.

Discovering such discrepancies at the moment of UAT offers a valuable chance to revisit the solution configuration vis-a-vis user needs before going live to the broader community.

Training: Visualizing Day-to-Day Work

Every enterprise-class solution initiative includes training. However, that is not always synonymous with training that’s genuinely helpful to users.

Training on solution features and functions is standard issue and goes without saying. But how about training on the broader business context and the overall business processes that the solution strives to manage? Or day-to-day problem-solving?

Essentially, it’s the difference between training and understanding. Users instinctively know the difference. Moreover, they’ll viscerally feel the difference when training falls too much into the former rather than the latter camp.

And, by simply asking training participants a few questions we’ll be able to quantify the difference, for example:

Do you believe solution training was helpful and informative with respect to your specific job, role and responsibilities? (Shown above)
Do you believe solution training sessions were helpful and informative with respect to overall business processes and project management methodologies?
Do you believe solution training sessions were helpful and informative with respect to the solution’s features and capabilities?
Do you believe the training materials used in solution training sessions were thorough and complete?

Ineffective training is a classic source of user dissatisfaction. By not helping users to understand the broader context of business process and day-to-day problem solving, there’s bound to be confusion and frustration later on.

However, with genuinely helpful training, there’s an opportunity to preempt those two imposters right at their source — and replace them with true understanding.

And spoiler alert: users tend to like what they understand!

Support: Ensuring Continual Realignment & User Engagement

So far, we’ve been focused on upstream sources such as requirements gathering, testing and training. But for good measure, let’s consider just one important downstream source that can easily slide into user dissatisfaction if left unchecked — or alternately, could provide a source for ongoing satisfaction if delivered successfully.

Specifically, let’s consider solution support & help.

Trying to preempt user satisfaction issues at their source is certainly important, but let’s face it: it’s impossible to preempt them all. User frustration will happen. But, how we deal with it can make all the difference.

That’s where solution support comes in.

However, if we ask users a few questions about their experience with solution support & help, we often find those resources are underdelivering, underleveraged or understaffed, for example:

How satisfied are you with the answers provided by solution support & help in response to your requests for assistance? (Shown above)
How familiar are you with the solution support & help resources available to you?
How familiar are you with the solution support & help request submission process?
How satisfied are you with the responsiveness and timeliness of solution support & help resources to requests for assistance?

The reality is that solutions evolve and user roles and responsibilities change. But proper support – that users are aware of and rely on – ensures the continual alignment between solution capabilities and user satisfaction.

Needless to say, here at EMMsphere, we’re huge believers in the enormous possibilities of solution support & help.

It’s good for business, it’s good for users, and it’s great for fostering a positive and forward-looking sentiment across the organization.

Closing Thoughts

In the end, there’s no single ingredient that ensures user satisfaction. So, we always encourage organizations to think broadly about all of the various elements that typically come into play, and to think deeply about what the underlying causes of user satisfaction might be.

Because ultimately, elements that cause satisfaction in turn drive adoption. But, there’s one more thing to keep in mind:

As they say, timing is everything. By catching satisfaction challenges at the moment they originate, and readjusting for next time, you’ll actually achieve two things at once: you’ll avoid dissatisfaction, and you’ll build satisfaction.

Those two might sound like the same thing, but they’re not. Your users will notice the effort, and they’ll sense the benefit. And they’ll thank you for both.