A Brief on Process Experience

The Experiences

• User Experience (UX): Discovering and meeting the needs of the user so that they have an improved, effective, and delightful experience when using software.
• Customer Experience (CX): Improving how a customer engages with a brand, product, or services to engender a sense of loyalty.
• Developer Experience (DX): Creating tools and systems that make developing software applications and features easier, faster, and in a more productive fashion.

All of these *Xs are efforts to improve how humans engage with our modern world. The benefits are real, and the joy of using a system without fretting, stressing, or hitting speed bumps is a worthwhile endeavor in its own right.

These *Xs cover a lot of ground — but one thing I've noticed that is that ironically enough, are often not applied to the very people that are designing and implementing these experiences. That is, it is quite often to see that a UX team may not apply their own UX principles to themselves! CX folks may be their own worst customers and DevX people will often have the worst tooling for themselves compared to what they are offering.

There's a sort of "meta-experience" that gets lost in the shuffle of doing work for a company.

I've been mulling over this concept recently, having joined a new company recently that is still going through some growing pains. There are many departments, each with its own needs but not necessarily skilled in the art of Experience Design. As with any company, there are plenty of creative people, but not everyone is a Design Thinker.

Process Experience?

Each time I start with a new company, I quickly take note of what systems, tools, and processes they have in place. Inevitably, regardless of the size of the company, there's room for improvement.

The first thing I do, of course, is start to ask questions. And, just as inevitably, someone responds with "I don't like process for the sake of process."

I have no doubt that most people have been the victim of heavy-handed bureaucratic over-zealousness, myself included, and I curse those organizations that have traumatized my would-be and current co-workers to the point of being highly resistant to trying out new, better, processes. They've had really bad experiences in the past.

So have users, and customers, and even developers — which is how we, over time, ended up with the domains of User Experience, Customer Experience, and most recently Developer Experience, all of which ask the fundamental question, how do we make life a little less painful and even a bit more delightful, for people?

With "processes" having such a bad reputation, why don't we have the discipline of Process Experience ("PX")?