I had a meeting with two government groups last week, they were keenly interested in how they could apply user centered design into their processes. As I prepared my presentation I started looking at all the various terms and “sub-disciplines” that have popped up over the past decade.
Lean UX. Design Thinking. Customer Experience Design. Service Design. Accessibility Design. Agile UX. Business Model Canvas. Requirements Visualization.
Then I made that AUGGH! sound that Charlie Brown made famous.
While the user experience design domain has matured and gotten traction in organizations large and small, there is still a lot of confusion about what the discipline is all about. Even in my own company, an organization that has some very mature practices in this space, I frequently have to explain what the role entails. And when you look at the job descriptions out there, you can see that the confusion extends to hiring practices as well.
When you have people who don’t know what UX is, and then you through multiple labels on the domain at the same time… well, it doesn’t help matters.
So, a modest proposal: Let’s cut out all the varying terms like the ones I listed above. Let’s just call it Experience Design (or User Experience Design). Reinforce and continue to align to the ISO definition of what it is all about:
ISO 9241-210: “A person’s perceptions and responses that result from the use or anticipated use of a product, system or service.”
Everything we do should focus on that. Understanding what users expect, how they respond, and what they need. Period.
Consider all the other sub-genres and alternate labels different approaches to this activity. And guess what? There is no “RIGHT” approach or process. One thing I’ve learned over the past decade and a half of doing work in this space is that you need to be flexible. EVERYTHING is negotiable, and one approach will not necessarily fit with all “customers”.
Case in point, my chat last week. One team was waterfall, and one was agile. I used two different presentations, because how they currently develop software required two different approaches. We still talked about what we wanted to do – see that ISO definition, above – but HOW we planned out doing that was different.
So, in closing – keep it simple. Learn all about the different disciplines, so you can have more tools to bring to bear. But be smart about it.
And stop confusing people with too many terms. Customers don’t care about the disciple or process, they want effective outcomes for their users. Never forget that.