Part 3 - Help Your Users Love Their New System (Part 3 of 3)

Embrace The Change You Bring.

This is the final post in a 3-part blog sharing the secrets to selecting and implementing the right customer interaction software for your company. Here in Part 3 – Help Your Users Love Their New System, we look at how to overcome the fear and resistance users typically have when a new system goes live. The sooner and better your users accept or adopt the system, the more quickly your business will realize the benefits of making the change.

Let’s be honest. Users usually feel like victims when there’s a change to a system or process. It's not necessarily because the new thing is bad, or even because it’s a change. It most often has to do with users feeling like they have no control over the situation. And typically, they don’t. Prevailing wisdom says you ask users what they need up front, show them what you’re doing along the way, then ask them to accept it at the end. This is true whether you use waterfall, agile or any other methodology. Is there a better way to handle this and is it worth it? Yes!

Everything we’ve written about in parts 1 and 2 of this blog series has been leading up to this moment. In Part 1 – How To Pick The Best CRM Solution For Your Business, we covered capturing what your business needs in the new solution. In Part 2 – Implementing Software Doesn’t Have To Be Painful, we looked at managing expectations and using the work you did on your requirements to keep everyone on the same page about what success looks like at the end of the project. In this post I’ll share an activity you can do to amplify the ownership and voice of the users in this process and get the best results possible when you go live. It’s so simple, and yet so powerful: Create user stories and make them the basis for user acceptance testing (UAT). Here’s how you can do it and why it’s important.

The “what” from the business requirements you created in Part 1 are the things that your users at various levels of seniority said they need in order for the system to be good. Success at the end of the project means the users reach a comfort level that all those needs they described are met despite the appearance of the underlying system or series of clicks they’ll now take. You could have hundreds of requirements. Trying to test out each one independently is inefficient and unreasonable. But each “what” actually fits together into a collection of needs, a series of short stories or sets of actions or processes that are familiar to the users. Instead of disembodied requirements, with user stories you now have mini scripts that your users can follow in testing to ensure their needs are met.

Describing those stories also puts the user needs in context of actions and process. Being able to share the stories helps others gain understanding. Without the additional context behind the requirements, the implementation team will make assumptions to fill in the gaps which can decrease the chances that the configurations will meet the needs harmoniously. Plus it's easier to see where a new best practice can be implemented and how that will change things for the users when it is shown in context.

Here's how to create user stories. First think about these stories as ways to describe what users do day-in and day-out. It might be scheduling a client appointment, sending out a product, generating an invoice, or creating a report to review with management each week. Then describe Who, What, When, Where, Why and How for these processes. Building them as part of collections that match up with the high-level process flow from Part 1 is a good idea. Find a downloadable user story template here.

User stories can be built as soon as the project begins so don’t wait to start this! User story creation is best done before users are exposed to the new system, before there's a chance for bias. The reason is that the users will be able to say, “As long as I can do the following things in the system, it will meet my needs. I can trust that if the steps in my story work, the system will work for me.” It’s another way to free your business from the “how” and for your users to know that no matter what form the new system takes, they can feel in control that their needs will be met.

If your business is like most, it can feel weird to your users to write about their work this way. Maybe things are too busy to set aside time for it. But don't let that stand in your way. You can utilize a screen recording capture program. A designated user, preferably the person who is most expert at the process, can simply turn on the screen recording when it's convenient, then talk and click while doing the typical process they follow as part of normal operations. You can build your documentation from that recording.

There are 3 major benefits to following a process of creating user stories beyond generating a blueprint for UAT. The first is that the stories provide context for the vendor or technologists who might not understand the users’ perspective on how each of these needs or requirements fit together into the business operations. Select a user representative in each topic area to conduct a review and walk through of the user stories with your vendor. This shared experience facilitates stronger understanding on both sides.

The second benefit is that you will see clearly what your users are doing to accomplish any given business process. This is always enlightening. You’ll find opportunities to improve from identifying false assumptions, revisiting the purpose of steps that fall under the category of “we’ve always done it that way,” and allowing moments of creativity when users suggest a new way of doing something. You might also identify risks such as compliance failure, or areas where fraud, waste and abuse are occurring. It’s helpful to be aware that this step can introduce changes to what you originally defined in the requirements or the scope of the project – another reason not to delay this part of the process!

The typical flow to this process is that a collection of user representatives with multiple levels of experience contribute to the stories to bring in all perspectives. A single internal point of contact familiar with the business should lead the effort to get the processes mapped out and documented. Next, a select group of stakeholders conducts an internal review with leadership where any changes to be made to the stories are agreed upon and compared to the requirements from Part 1. Note any updated requirements. Then these user stories, any process changes that will occur as part of the project or with the new system, and any changes to the requirements should be reviewed with the vendor. Remembering the 3-legged stool from Part 2, if there are changes to the scope of the project because of how the process needs to function then the team should be prepared to see an impact on the timeline and/or the budget.

The third major benefit to writing out and reviewing user stories is that these become not only the UAT scripts but also feed training materials and employee manuals. If the users know what their system must accomplish and it’s written out step-by-step, capturing screenshots of the new system and pasting those into the user story at the appropriate points gives you an incredibly powerful document. Any user familiar with the business process should be able to pick up that user story with screenshots and run through a test of the system. Users can refer to that same documentation for training. It merges not just what the system can do, but how it works in the context of their specific needs.

One last tip is to do a requirements traceability exercise which is a fancy way of saying that for each need or requirement you listed from Part 1, make sure it’s tied to at least one user story. That way you will know the system will be thoroughly tested during UAT. The free user story template on our website includes a section for listing out the requirements aligned with the story.

This approach of integrating the users’ voice and needs into every part of the process brings a sense of control back to your users. Can you envision them being more excited knowing that the solution will directly support the process they describe? Absolutely. It also eliminates the worry about what to test when it’s time for UAT. The user playbook is ready. Your trainers will be less anxious because the training materials and testing materials will be aligned. Everyone will be ready to move forward when the new system goes live!

If you enjoyed this 3-part blog series, please follow Hartary Consulting on LinkedIn.

Hartary Consulting strives to build great client partnerships by providing practical business operations advice to small and medium-sized companies.