Wicked, wicked problems

When a client gives you a very broad brief – “design a vision for our international digital presence” – and six weeks to get there, getting started can be a bit daunting.

When a client came to us with exactly that brief, we were both excited and nervous about the scale of the problem we were given. Are we really just redefining their digital presence? Who are we even designing for?

 

Wicked problems

In Design Thinking, briefs like this are called Wicked Problems.

They’re the exact opposite of Linear Problems where all one has to do is:

  1. Identify the problem
  2. Solve the problem

With Linear Problems, there’s enough data and insight to both define and solve a problem, and the solution is predictable at the beginning of the process.

Wicked Problems don’t follow a linear process. They have no clearly defined problem statement, and all the variables at play make it impossible to predict a set outcome.

 

Tackling the brief

To start tackling our brief, we decided to go back to square one and ask some basic questions:

  • What’s the business like, its performance, ambitions, and priorities?
  • Who are the customers we want to attract, what are their needs, expectations and current relationship with the company?

To answer them, we sifted through masses of documents and trawled the web to read comments and feedback from customers.

The most valuable thing we did was spend time with colleagues and customers.

The team not only went to customer service centres, but listened to calls coming in and chatted with agents helping customers out. We all spent days with engineers going in and fixing people’s homes and watched the interaction between the customers and engineers. We interviewed current and potential customers to get feedback from them. We spent time with people, in their homes, understanding their behaviours to design a service that would fit around their lives.

The insight we gleaned from all that work was phenomenal.

  • We all had stories of great customer service that they didn’t shout about.
  • We all met customers who valued the service, and trusted their engineer to the point of asking for them by name when something went wrong.

The needs we uncovered were not the same we set out to solve for in our initial brief. So we pivoted and focused on those instead.

In only six weeks, we had the basis for a digital vision designed to solve real customer and colleague’s needs. We had a set of unexpected insights, and that we could turn into valuable features and service.  We also had an enthused team bought into the process, and keen to begin changing the way they approached problem solving.

To find out more about the work we’re doing at Fluxx, why not take a look at our case studies.