Problem finding is always the designer’s first job

Problem finding is always the designer’s first job

The identification of the problem to be solved is the golden ticket which gives your product VIP access into your user’s world. It is the price to play at the table. It is the process which humanises your product, generates happy customers and drives loyalty.

Without it, your product can at best aspire to be functional. With it, your product can be useful, usable and most importantly, used.

The reason that problem-finding is such a critical skill is because it connects what is inside your user’s brain with the functionality your product offers. By understanding it, your product can frame the functionality in the right way, grasp design trade-offs and prioritise accordingly, and incorporate functions which most neatly align with your users’ mental model.

Back in my agency days, we did some work for a Belfast-based theatre who had just launched a new website. As part of that project, they had invested in usability testing, and had engaged users of various types to book tickets for shows using the site being developed. In general, users were able to complete the tasks presented, and modest changes were made to content layout and flow in response to observational findings from the exercise.

You can imagine their surprise therefore, when they launched their new website to discover that conversion rate had gone down, not up! They phoned us in somewhat of a panic, trying to work out where it might all have gone wrong. We looked under the bonnet a little, prepared and sent a proposal, and were appointed to carry out a programme of observational and attitudinal research, which included more usability testing.

So why did we propose repeating an activity that had already been done, and which appeared at first glance to have had a neutral (or potentially negative) impact on site performance? The reason is because when we reviewed the initial round of usability testing, the scenarios and tasks were based around problems which users didn’t have.

The previous usability testing incorporated scenarios such as “You are wanting to watch 39 Steps on 7 May with your spouse, booking drinks during the interval. Please go ahead and make the booking.” This scenario was relevant, but only to one very specific user problem, which was unrepresentative of how most theatregoers booked tickets in the real world.

Ticket-booking in the real world is much less clean than the usability test was designed for, and the problems users wanted help with are much more nuanced:

  • Should I go to matinee or evening showing and what is the price difference?
  • We are free on the 7th, 8th and 10th and want to go on the evening where we can get the best seats.
  • I am in Belfast for a weekend with some friends from 10th to 12th May and we are thinking of seeing a suitable show – what is on offer?

Having identified these user problems, we were then able to design the usability testing around scenarios and tasks which users had in the real world. That in turn enriched the observational research, which subsequently provided the insights to guide designing the system for problems which actual users were having in the real world.

We encountered a similar situation some years later when we worked with one of the largest ferry companies in Europe. Their site had been operational for some years, but their analytics pointed to a large drop off in the early steps of their booking process. This was curious because while we’re used to significant user drop-off early in travel booking (often users are just researching times, dates and prices before making a decision later), the numbers for the ferry company were particularly stark.

Similar to the theatre company, the website they had built was functional – it allowed the user to book ferry crossings – but didn’t solve problems – it didn’t work hard to answer users’ questions or deal with their concerns. So, if the user’s need was “I wish to book my family in a car on a crossing from Ireland to France on 19 May” the website could meet it, but only a small subset of users had that need.

Typically, user needs were more complex, more nuanced and less sanitised:

  • I need to cross from Ireland to France between 18 May and 24 May and want the shortest crossing
  • I need to cross from Ireland to England for a wedding on 26 May and want to land in England as close to the wedding venue as possible
  • I need to cross from England to France any time in May and want to travel as cheaply as possible

Our early work on that project focused on explorative research, engaging with users to ensure we understood their full range of problems, tasks and motivations before designing the usability tests.? Again, by investing in understanding the problem, we were able to align the design with how real humans use the website in the real world.

The commercial performance of products which solve problems people don’t have is sobering.

They fail.

According to product watchdog company CB Insight’s 2021 report, the most common reason start-ups fail (42%) is that there is no product-market fit. The product is solving a problem the user doesn’t have. The Harvard Business Review’s 2021 editorial on what to do about it is crystal clear:

  1. Problem definition
  2. Solution development
  3. Solution validation

Products which solve problems users don’t have die. The only way to breathe life back into them is to problem-find first, problem-solve second.

Jenna Lloyd

Fractional CMO | Menstrual Health Advocate I help Women’s Health brands market previously stigmatized topics like menstrual health, fertility, sexual well-being, menopause, postpartum and mental health.

4 个月

Products which solve problems users don’t have die.! Well said!

要查看或添加评论,请登录

社区洞察