Understanding User Experience
A way to describe UX without talking about deliverables
I have been working in various aspects of user experience, primarily with agencies, for over 10 years and in those 10 year UX discussions have gone from looks of confusion to nods of it being the hippest buzz word at that moment in time. In a way it’s great to be the coolest kids in the room, but unfortunately the room’s understanding of UX is too often limited by physical deliverables they get from us rather than the thinking that goes into creating them.
Let me try to explain. In March of 2000, Jesse James Garrett published a PDF called The Elements of User Experience.(here: http://www.jjg.net/elements/pdf/elements.pdf ) Its goal was to define terms within UX and clarify their relationship with developing for the interactive web… and as such it does an excellent job, withstanding the test of time making it a staple in the UX wheelhouse ever since.
However it also laid out the framework of site objectives, information architecture, interaction design, content [strategy], etc. It’s my opinion that as UX grew as a desired role in agencies, and the role had to be defined, the ease of understanding this graphic led to the deliverables that are mapped to its framework defining our roles.
The problem comes from other roles being so clearly defined. Producers, produce — Strategist, define strategy — Developers, develop. User experience, well… umm.
Additionally, UX as a department is different everywhere you go. Some have content strategy in there, others have QA and analytics. It’s easier to expect a document than it is to understand all the different processes.
So as I’m talking to people about my next career move I’m getting asked “what is it you want to do?” Explaining my desire led me to what I think is a good reset for how we as UX practitioners can avoid being defined by our documents.
User Experience is two things. Design Thinking — which encompasses wants and needs of users and the creative solutions to meet them, and Critical Thinking — which evaluates the solutions for their strategic success.
Knowing this I first approach the design thinking with a scientific method. This isn’t to say that everything has to be based in proof, rather it is a process by which I generate hypothetical solutions to the design problems I face. Each hypothesis is then tested to determine it’s viability. This is cyclical in that many hypothesis require multiple iterations to be considered an option.
For instance, maybe the drop off rate on a form is 75%. One hypothesis is that the form is on too many pages and should only be on one. Simply by bringing all the content onto one page gives a visual indication of success that can be quickly tested.
In the middle you can see that the result of this approach is a variety of options. Those options should vary from comfortable to disruptive. If they don’t you probably need to test more ideas.
Finally, on the right, solutions are evaluated and implemented. Evaluation consists of working with anyone who could kill the idea and getting their buy-in. It could be marketing, tech, etc. Implementation is half obvious in that it’s the deployment of the idea. The less obvious half is actually more important. Implementing correctly means tracking success with some level of analytics.
None of this is to say that UX doesn’t, or shouldn’t, produce things like site maps or wireframes. Those documents will always be valuable to the creation of the end product, they just aren’t good ways to define the actual value that a UX process brings by first understanding the problems and testing possible solutions before committing to a final product.
Using the above method to talk about the UX role has helped me build understanding with my colleagues and clients regarding the thinking that has to happen in order for my teams to produce the documents we’re known for.
Now if I could just get everyone to stop calling my interaction designers “IAs”.
