Disruptive User Experience: Being a BPM Thought Leader (part 1)

When you read the title of this blog, you may think I will be talking about something bad. After all, a disruptive user experience (UX) sounds bad at face value. The best UX is when it is seamless and just feels natural. However, while the end product must exhibit those traits; to get to that point often requires a healthy degree of disruption. This is especially true in enterprises that have a legacy of convoluted process, ancient back-end systems of record, and UI’s that believe the only colors are black and green. In this type of environment, the only way to get to a seamless UX is to have people that are able to provide a level of thought leadership that not only empowers a customer to improve their core business processes, but to take a look at how those processes are experienced and make those changes as well.

Change is Hard, But Complacency Drives Customers Away

Unfortunately, to make changes to the way a customer or user experiences a process often requires a level of disruption. As a consultant who gets brought into countless customers to help define the user experience of their BPM projects, I see all forms of change resistance. This resistance can be utterly passive, such as people simply not showing up to meetings. Or it can be pretty active, with outright hostility when you propose changes. This is all part of the job of the BPM Thought Leader. When you are brought into an organization to help craft that new user experience, you have a responsibility to account for the disruption you will be causing. As a thought leader, you are also going to be called upon to help manage the change that will be occurring as part of your work.

Complacency is rampant within organizations, both large and small. Even those who advocate for change and are champions of this great BPM journey their organization is about to embark upon will have a certain degree of complacency. As a BPM thought leader, this complacency needs to be addressed by showcasing its dangers. If the UX continues to be poor,  if the process continues to be unnecessarily complicated, or if the burden of bloated data requirements continues to be shouldered, the business as a whole will suffer. This will be evident through high turnover and longer training times, decreased task performance, and a diminished capability to properly service the organization’s customers.

Everyone working in today’s world economy can easily see the dangers of complacency. When times are tough, complacency is easy and even seen as the safe, sure bet. However, anyone that works in the BPM world knows differently. In fact,  BPM can be considered the arch-enemy of complacency but its very nature. By continually examining your business  processes,  making them adaptive to daily or even hourly business needs through robust business rules, and providing a highly interactive user interface, a proper BPM solution can banish complacency forever.

Managing the Disruption: UX Considerations

For most organizations, embarking on a BPM project is intrinsically disruptive. Buying BPM software or simply going through the exercise of examining and streamlining your business processes disrupts the way things are being done within your organization. This is why many organizations bring in external BPM consultants to help them manage the change. This management of change extends to the overall user experience. Replicating existing UI and how the process is visualized in the UI is complacent. Taking the opportunity to change the UI and improve the UX is disruptive, in a very good way.

Managing UX disruption can be even harder since people have quite the emotional attachment to UI. Everything from how many clicks to the size of the tabs to the branding evoke opinions from almost everyone across the organization. I often find myself managing disruption across multiple groups, factions, and audiences and it requires different strategies and techniques depending on who you are talking with.  I will explore several of these strategies in Part 2 of this topic…

pixelstats trackingpixel

By Baruch Sachs @ Pegasystems | February 29, 2012

Leave a Reply

Your email address will not be published. Required fields are marked *