As any User Experience professional does, I like to talk about touchy/feely things such as experience, emotion, empathy. I'm stepping onto a soapbox to say it… I believe that the most important thing a business can do is put Design Thinking and User Experience at the top, an important job function of nearly everyone. I believe that dedicating the most resources to improving our understanding of what it means to create "an experience", finding ways to evangelize UX and more broadly, design thinking, to all leads to better products, happier customers and employees, and success for any business. Today's post is all about how you can participate in understanding experience. The methods I will describe are accessible, easily understood and attainable.
A customer is discussing with you a feature, or lack-thereof, or a defect, or this grand idea, or something that is confusing… Some of my go-to "to-do's" are listed below:
a. Define and Diagnose.
Have you asked enough questions from the customer and others to have a deep understanding of the problem? A deep understanding means that you get the pain, have empathy for them. Having empathy isn't enough, however, you also need to understand the systematic details and limitations causing that pain to be present. This is the meeting with a doctor when he is diagnosing your symptoms. Every time we talk with a customer we have to be the doctor. We are the expert, yet the patient is well informed, perhaps more than us about their unique experience. We also need to understand how many patients are affected by a similar diagnosis, how severe it is, and the provenance of the concern.
The most important thing for me when I'm diagnosing is immersion. Have you immersed yourself in the problem space? Have you observed a user interacting with the culprit technology at hand? Have you personally used the system enough to achieve a "flow" within the application's processes and design? All of these things are necessary to achieving a good level of immersion which leads to a better understanding of what we have, what's missing, where there are gaps, and how/why the current solution is designed the way it is.
Ask yourself, "What is this an example of?". What I mean here is to examine something completely unrelated that has a similar problem or set of problems. How did they approach the problem and what does their solution look like? What is novel about their approach? Perform background research, including reading industry and academic papers, interviewing customers, stakeholders, and decision makers, and any other research method that fits the unique problem at hand. The key here is that through research, you can gain insights which can be applied to the problem.
How would you fix it? Here I want you to literally draw what you would do to make something better. Draw the experience. Prototype the experience. Re-create it with people and scenarios; iterate and enumerate upon your ideas. Multiple concepts, multiple passes at each concept.
How would the customer fix it? Ask them, involve them, user experience is all about connections - with people, technology, experiences. Show the customer what you found out from doing the above steps. Ask for their feedback on that, involve them in the next iteration of the concept. Doing so will enhance shared understanding, create buy-in, and lead to an "out of the box" appreciation that those customers involved will have once the new functionality is released.
User Story. User Story. User Story. This is the best way to communicate a software need to developers. The folks that take all of these enhancement requests, defects, problems, killer ideas, systematic issues and create new things for the rest of us to use. Every single person in an organization should know what a story is, why it's important, and how to write one. I could do an entire blog post on user stories (that might come next), however for today, a user story is simply describing...
It seems too simple, terse, how in the world could a developer understand and build solutions with only the above? User stories are often enough to build the functionality to improve upon a given problem. This is another place where design thinking comes to the forefront, to help the developer go even further in ensuring solutions are made to be beautiful to look at, simple to use, and most importantly, solutions which create "an experience". All of the collateral developed over the course of the project, specifically from the above steps, will get wrapped into a nice little package for the developer in the form of a requirements and specifications document. We're well on our way to success…
I would first encourage anyone interested in learning more about design thinking to read The Reflective Practitioner (Schön). While working through A-E above be reflective. Ask yourself, "How did that go?", "How could that have been better?", "What are the things that went really well and why?" To be a reflective practitioner constant reflection must be present. This reflection should also include critique of oneself and others, critique of the solution, and also reflection regarding the unique process that was followed to arrive at a particular solution.
304 West Kirkwood Avenue Bloomington, IN 47404 USA
USA/North America +1 812 330-4361 UK/Europe +44 33 0808-0139 Chile/South America +56 2 835-5184
Cornerstone Product Information & Promotions