About two and a half years ago I stepped foot into a role as a UX designer within a tech company. I came into software development from a print-centric background and had worked as a graphic designer and art director. I left behind the world of drop-dead print deadlines and obsessing over paper quality and jumped head-first into a world of scrum teams, sprints and the challenges of designing user experiences on top of legacy technology.
As a designer, I’ve always thought of myself as a problem solver. But the more I encountered problems in the technosphere, the more I realised that some of our biggest problems stem from long-held behaviours, processes, tools and mindsets. And the bigger the problem, the more difficult it is to solve because of how ill-defined and interconnected it tends to be with other problems, people, or systems that are complex and unpredictable.
“We become what we behold. We shape our tools and then our tools shape us.” —Father John Culkin
Wicked Problems, Tame Solutions
We are living in a post-industrial world, and yet our working practices still reflect an industrial mindset. The problems we face now tend to be filled with uncertainty, complexity and ambiguity and yet, we’re still using linear and mechanistic processes to solve problems in a world that is chaotic, cyclical, adaptive and sprinkled with randomness.
Soon after entering the world of software development, I realised that the rose-tinted view I had of tech from the outside—as this agile, dynamic, lean and iterative environment—was not at all the reality on the inside. What I found was that the opportunistic, iterative approaches to problem solving (dare I say Agile?) that are touted in UX literature were not really functioning that well. Instead, problems were getting solved in a top-down, linear approach that looks very much like the traditional waterfall model.
And our solutions, when fully mapped out, were still taking the form of linear, binary processes that kind of look like engineering diagrams…
But the longer I spent working this way, the more I felt that these methods of mapping problems and solutions weren’t really cutting it. We could create a solution to a problem, and we knew how to develop that solution, but still many critical elements were getting missed during the design, planning and execution of all of our well thought-out UX work. I realised that the problem was that we were trying to deal with non-linear, multi-dimensional problems using linear and simplified toolkits and viewpoints. In other words, we’re trying to solve wicked problems using tame tools and methodologies.
For the uninitiated, a primer on tame vs. wicked problems:
- A tame problem is a problem that can be solved using the correct logical formula. For example, you need to design a data table that allows users to sort information in ascending or descending order.
- A wicked problem is one in which there is no known recipe or template to use in solving it. For example, building an eCommerce platform.
- Tame problems tend to be clearly defined and you know when you have a solution.
- Wicked problems tend to be open-ended, ill-defined and will require a large amount of input from various sources in order to reach a resolution. Solutions to wicked problems are not right or wrong, they are only good-enough or not-good-enough.
We’re All So Special
Another by-product of the industrial revolution that we face today is the problem of specialisation. When I was in school, I was told to find the one thing that I was good at and stick to it until I retire. In fact, I’m sure we have all been told this. But now we live in a world where specialisation is becoming an impediment to innovation.
When I first entered tech, I thought I needed to be a specialist—that I needed to be an expert in user experience and UX methodologies in order to produce the best journeys for our customers. However, the longer I practiced UX the more I realised that we were only scratching the surface of the problems that needed solving in order to create a truly intuitive and simplistic user experience. The team and I could create really well-informed interface designs and user journey flows that made for a near-frictionless user journey; however, implementing that design work wasn’t so easy, especially when working in an enterprise environment with legacy software.
The problem that we had solved in our own UX silo—designing the best possible user journey based on data, user input, and feedback—wasn’t feasible to implement without making some serious compromises and deviations. We believed that we had done our due diligence, but it turned out that the solution we’d hoped to implement was riddled with hurdles that spanned from our existing system structure to licensed integrations.
At first I started thinking in terms of extending empathy, because empathy is the very starting point we use in Design Thinking to start analysing a problem from a user’s perspective. But if we’re going to deliver a solution—to a high standard—then not only do we need to empathise with the user, but we also need to empathise with every supporting actor, process, task and workflow associated with delivering that user journey.
“Study the science of art. Study the art of science. Develop your sense — especially learn how to see. Realise that everything connects with everything else.” —Leonardo da Vinci
Over time, I became aware of our blind spots, and some features we were building weren’t getting fully implemented because we weren’t aware of all of the moving parts of our own solution. This taught me to look at problems in a new way. I learned that the best way to approach a problem is to first deconstruct it. Like… really break it down. Understand, end-to-end, what is happening within an organisation that allows that organisation to deliver a service to people. And bring other stakeholders in on the process to harness their insight and improve their understanding as well. This isn’t just another UX workshop activity, this is an in-depth, cross-functional overview that goes deep into the weeds of what actually happens behind the scenes in order for a service to exist and function. Service design blueprinting has become my latest method for approaching this process of deconstruction.
If you’re going to solve a problem, first make sure you are zooming out—way out—in order to see the more subtle dynamics that exist behind the scenes and to get an understanding of where you might hit a few bumps along the way when you start working through solutions. We can look at this through the lens of empathy:
- Empathise with your colleagues: Understand how developers write their code, how they test, how they iterate and problem-solve. Understand the development frameworks that they use and the system architecture so you can speak their language. Ask questions, lots and lots of questions, even the stupid ones! I promise, someone will be there willing to explain this stuff to you.
- Empathise with technology/tools: Understand the constraints and abilities of the technology and tools you are working with. Get to know the product, and the parts and pieces that make that product a reality. If your organisation offers multiple software solutions, get some training or test the software yourself. If your organisation has a smaller offering, get curious about the tech stack supporting that offering.
- Empathise with the business: Be inquisitive, make sure you understand the vision and strategy of the business. Knowing this will help you generate buy-in and support from senior leaders and others in the business.
- Empathise with your users: At the end of the day, you are providing a product and/or a service to a set of customers and in order for that product or service to be successful, it needs to be useful. Keep your UX practices going, but try taking a broader view of the problems you’re working on.
Be inquisitive, and document everything—this is where service design blueprinting comes into its own in that it provides a visual framework in which to collaborate on, store and analyse all of your newfound knowledge. Use this process to track everything, from the user experience to the internal experience of the teams, systems and processes involved in creating a product or service, including:
- The user journey
- Interaction touchpoints (website, email, over-the-counter)
- Actors (user or customer, internal actors, stakeholders)
- System (technology, workflows)
- Policy / rules related to the service
- General observations or facts
- Metrics / data
- Questions / unknowns
- Critical moments / pain-points
- Ideas / Opportunities
Below are some resources so you can learn more and try service blueprinting to start tackling your own wicked problems:
Service Blueprint template from Mural
Practical Service Blueprinting eBook by Erik Flowers & Megan Erin Miller of practicalservicedesign.com
Service Blueprints: Definition by Sarah Gibbons on NNgroup.com
If you’re a veteran in this wicked space, hit me up! I’d love to learn how you’ve approached and managed these types of problems.