A small eruption emerged on Twitter in response to my article that covered the Adaptive Path acquisition. At the root of it was a conversation about the differences and overlaps between user experience (UX) and service design. Patrick Quattlebaum, managing director at Adaptive Path and esteemed former colleague sat down with me to see if we could suss out the overlaps and distinctions between each approach.
Our conversation lasted a few hours and covered the state of the experience design industry and underlying craft. As a starting point for our discussion, Quattlebaum pointed me to a blog entry of Kerry Bodine, Forrester analyst who has also been covering this topic. I diverge from Bodine's perspective in several places, most notably the idea that “customer experience” (CX) fully contains all of “user experience.”
The Experience Primer
Bodine used diagrams to describe the percentage of overlap of each discipline. While I respect her perspective, I wasn't satisfied that it captured either the similarities or the differences between the disciplines.
Bodine writes: "As the image below shows, I believe that all UX work is a subset of CX work. Customer-facing digital touchpoints are by definition part of the CX, and employee- or partner-facing digital touchpoints either directly or indirectly affect the customer experience in some way."
Bodine’s model, where UX is a conceptual subset of CX is in my experience untrue, given that employee-centered experience work (e.g., intranets, career portals, collaboration platforms, etc.) is quite often inside UX and rarely, if ever, inside CX.
When speaking about the customer experience discipline, Bodine says that customer experience "encompasses a complex set of relationships among a company’s employees, partners and customers — and it’s these people’s decisions and actions that collectively determine the quality and characteristics of all customer interactions.” This idea illustrates how the two disciplines separate at the core reason for being.
My point is this: CX and all of its ethos is centered around the customer (i.e., the purpose of a business is to serve a customer). This isn't a horrible idea. But this orientation leads to ROI litmus tests which tend to kill anything that is primarily meant to improve the employee work life (e.g., look at the employee issues faced by Amazon and Walmart who live for the customer often at the expense of the employee and society around them).
Bodine's diagram, while simple to understand, also suffered from lack of discussion on the scope of application, the motivations involved and where each school of thought falls down. In an effort to move through my own conceptual struggles, I laid out my own primer and a new diagram for how the disciplines match up with and against each other. My conceptual view is laid out like this:
Customer Experience (CX)
Mission -- To enhance the experiences of customers as they engage with businesses and to make these experiences distinct and memorable.
Target -- Customers who interact with technology and physical touch points, more often than not, to accomplish a goal.
Domain -- Touch points between businesses and customers
Ethos -- Businesses exist to serve a customer and the business that delights its customers the most will be the most successful.
Achilles Heel -- Reductionist, profit driven ethic very often creates an enterprise view where customers exist at the expense of employees.
User Experience (UX)
Mission -- To enhance the experiences of people as they engage with technology based systems (there are non-tech based applications, but these are the minority).
Target -- People who interact with technology systems, more often than not, to accomplish a goal.
Domain -- Web and software based applications.
Ethos -- People deserve better experiences when interacting with software and we can improve people's satisfaction and company's profits by taking design seriously.
Achilles Heel -- Near universal co-opting by profiteers and visual interface designers to the point where enterprises devalue the research, strategy and much of the design activities which results in the practice becoming indistinguishable from basic interactive design.
Mission -- To create great sustainably great contexts and interactions for and between enterprises, customers, employees and partners.
Target -- People who interact with digital, physical and people based systems, more often than not, to accomplish a goal.
Domain -- Earth.
Ethos -- We the design community can think and act bigger in our approach to make service contexts and interactions sustainably great for all parties involved in the creation and consumption of services.
Achilles Heel -- Given the newness of the movement, the achilles heel of service design is unknown at this time.
In practice, you can find many practitioners tend to self select which of the camps that they fall into based on one or more of the aspects described above. Some individuals identify much more with the UX and service design movements because of the notion that CX is a poor attempt to make marketing slightly more hip and human centered by dropping in the word experience. On the other side, some people just cannot bring themselves to believing that a non profit-driven movement can ever be sustainable in a mainstream business environment. This is where the DevOps movement enters.
The Artisan Experience Primer
As I spent time thinking about the three movements above, I kept returning to another movement: DevOps. DevOps, much like Design Thinking, puts an additional focus on the person working through the problem, and their associated mindset, as opposed to the end that the worker is striving for. The added lens of the artist as separate from and part of the art they create has made this movement a little tougher to define than the others which also makes it a little harder to adopt holistically.
Mission -- To improve the lives of technology workers around the world and the profitability of the companies they work for.
Target -- Development and operations staff inside IT enterprises and startups.
Domain -- Software and hardware infrastructure built and maintained by people.
Ethos - Employees who develop, operate and maintain software and hardware are people who deserve opportunities for self actualization inside of enterprises. When companies treat these employees as humans, they gain opportunities to become more profitable and competitive in the marketplace.
Achilles Heel -- If we truly automate all the things, will there be any more work to do?
Prior to my conversation with Quattlebaum, I had come from a full day at DevOps Enterprise 2014 and I was struck by something beautiful coming out of this technology driven humanist movement. Even though many people try to define models to describe this amorphous discipline, everyone accepts that the individual truth for each practicing shop and professional will be a little bit unique and that no one governing body or expert owns the defining characteristics of the movement.
The Origins of a Movement
Leave it to operations geeks near the bottom of the enterprise totem pole to emerge with one of the most organic and beautiful things to come out of corporate America in a time where employee disengagement is an epidemic.
This is yet another similarity between the design and DevOps movements. Much of the migration from UX to service design comes from human-centered design professionals not wanting to be associated with the fully corporatized and commercialized practice that UX has very often become (e.g., the waft of SharePoint shops that put a graphic designer on a project and call it “UX”).
While not exactly parallel, many former ITIL professionals have run screaming out of the robotic clutches of ITIL dogma to a human-centered movement that has yet to be despoiled by the profiteers and the poseurs. A large amount of enterprise and enterprise-vendor attention has taken notice of and is beginning to embrace this shift. The question is, who will prevail: The humanists or the wannabes?