Think about your favorite products you use every day - your smartphone, your laptop, your car. All started out as basic utilities until they became so user friendly that you want all your products to be just like them. You want simple tasks to be, well... simple. You don’t want to have to think about how to use them. This is what sets great products and great experiences apart – we call it user-centered design – and it plays an important part in designing employee experiences in the workplace too.
Here at Impower.ai we believe building automations is not only about technical performance but also about user experience. If an automation works technically but interacts poorly with a process owner or end user, it creates friction. Friction can then quickly breed frustration. Ultimately end user frustration can lead to a bad reputation of your automation program for making users’ workdays actually more difficult, not freeing them up to do what they enjoy and what humans do best.
Here are some common pitfalls to avoid and some tips to use along the way:
1. Always start with the why
Even if your stakeholders know exactly what they want, if it solves the wrong problem then it’s the fault of the CoE. You’ll be surprised at how challenging it can be to clearly articulate the root problem. That’s OK, spend that time now rather than after development.
2. Determine success criteria carefully
Time savings is the default metric for most RPA’s. Depending on your organization and culture, time saved may not be valuable if that freed-up time doesn’t result in X or Y. That X or Y now becomes your success criteria. This depends on the root problem you’ve uncovered in step 1 above.
Keep in mind that success doesn’t need to always be 100% automation. If the process owners can receive their benefit from 75% automation, you may not need to spend 2-3 more sprints on getting to 100%.
3. Use flowcharts to visualize the user journey (aka journey mapping)
Journey maps are a powerful tool for process re-engineering that leaves little ambiguity. We love using swimlanes and make sure to include one for each end user group to clearly outline the experience and expectation of each group.
4. Don’t wait until UAT to design the post-run experience
It can be easy to spend most of planning on the execution steps of that automation. Thinking about how to give the product owner confidence the automation ran (and ran successfully) is often an after-thought. We recommend having a default post-run template to start but be sure to design the right experience for each automation.
Be sure to show real error messages to users during UAT so they don’t see them for the first time in production. Also be sure your error messages indicate who is now responsible to take action. Is RPA Support investigating? Is it for the process owner to execute manually?
(Please avoid the Spiderman meme situation however possible)
If the accuracy is especially important, share data back with the process owner to build confidence the automation worked as intended. No news is not always good news
5. Use mockups early and often
You don’t need Figma or a UI/UX designer to create a simple example of what an email or output could look like. The point is to test scenarios as cheaply as possible, you can use Powerpoint, whiteboards, or even the old pen and paper. Then pose questions such as “If you saw an email/output like this, would you have all the information you need to proceed?”
6. Demo throughout development
Because automations often follow a diagram or task capture exactly as a person does today, most teams resort to waterfall development. However, even if you aren’t delivering slices of value after every sprint, still show and tell for feedback frequently. You’ll be surprised at how often you’ll hear “Now that I see it in action, I’m not sure that step makes sense.”
7. User notifications - Push vs. pull
Use push notifications for messages that must be acted upon fast. They are intended to distract the user from what they’re doing in order to take action immediately. E.g. Teams or Slack message over email.
Use pull for passive communication. These can be accessed when needed but at the convenience of the audience. Remember that reports can be both.
For automation programs that are successful and mature, we notice that process owners generally have positive feelings toward RPA. It makes their days easier, not harder. For programs that struggle to grow and scale, we often find a negative reputation from business users. RPA has complicated their job and they struggle to integrate it within their day. Those users are now less likely to submit new ideas, quickly cutting off the lifeline to new projects.
Keep your users and process owners in mind from the beginning, designing around them. We can’t promise that technical issues won’t also impede your success, but end users will be much more patient if you create a pleasant experience overall.