Are you solving the right problem?

Lessons learned from redesign projects

Photo by Olav Ahrens Røtne on Unsplash

I want to share a little story about a recent redesign project.

A longstanding client of mine struggled with their online sales: they saw a constant decline over a year. They updated and tweaked the website, but it didn’t change much.

They set up a roadmap and collected a bunch of ideas on what to change over the next 12 months. Because they had so many initiatives, they were looking for external help — and reached out to me.

I was asked to help with the redesign of their mobile app, which was another sales channel. I got excited, pulled my sleeves up and started to dig into it.

Initial Investigation

Before I dive into a design project, I start with some basic investigation. That includes:

  • reviewing data-analytics
  • go through my briefing questions with the PM
  • review existing research and project documentation

I learned that the app contributed just a small fraction of the overall revenue. My client had a well-working-responsive website and the app didn’t offer much additional value in sales.

Going through previous research documentation gave me more insights into customer pain points. A lot of them didn’t actually involve the design of the website or the app:

  • customers were frustrated about shipping (intransparency about the duration, products being damaged during shipping)
  • they were confused about product cycles (certain products would only be available in a certain season, and some products would disappear completely)
  • and they also had more and more alternatives they could turn to (lack of loyalty)

Problem Definition & Opportunities

Looking at these pain points, there were a bunch of ideas for improvement that came to mind:

  • Update shipping information on the website/ don’t make false promises
  • Improve the system for tracking your shipment
  • Provide better product descriptions
  • Inform customers about product cycles in newsletters
  • Create a loyalty program

Instead of starting a complete redesign of a mobile application (that even from a business perspective wouldn’t move the needle by much), we could start with smaller projects, make quick changes, test them and get feedback and iterate.

But this is not what happened.

My client was so fixated on the roadmap (the C-Suite had approved it), that they didn’t want to reconsider.

So we went on and redesigned the mobile app. We worked on this project for 6 months. Shortly after launch, the business got into bigger financial turmoil and the app disappeared completely.


How can we make it better

Some lessons to take away from this story are:

Be clear about your customer problem AND business problem

This is one of the most common mistakes I see in product design. Most projects are driven by a business pain point. And I get it, these are urgent and also the most relevant ones for the executive league. But in order to solve a business problem, you need to connect it to your customer problems: you need to get down to the WHY.

? Steps you can do in your next project:

  • Before you start a project, note down any customer pain points.
  • See how they relate to your business needs (what customer pain points might cause your business pain point).
  • Prioritize your pain points and choose one pain point you want to solve in your project.

Look at the big picture: your customer journey is more than a website

A website, a mobile application, or any tool is just ONE touchpoint for your customers. But there are many more who make up for the overall experience. Your marketing messages, your brand perception, your customer service, your products and product information — all of these aspects are having an impact on your customer experience.

? Steps you can do in your next project:

  • Take the time to look at the bigger picture. Do a customer journey map exercise to identify the key pain points.
  • Identify the opportunities for improvement and prioritize them with an effort & impact matrix.

Use experiments: your roadmap is just a guide

We need plans to structure our resources, communicate goals and organize collaboration with other teams. But plans can and should be allowed to change. We don’t know what the future holds and we continuously learn and grow.

If you do build a roadmap, build it around the problems you want to solve, not just around a fancy feature list.

? Steps you can do in your next project:

  • List and prioritize the problems you want to solve.
  • List and prioritize ideas for improvements.
  • Define KIPs to measure impact.
  • Create a timeline for your ideas.
  • Plan for regular review sessions to be able to pivot when needed.

Define measurable criteria

It’s exciting to come up with new ideas. And we have the tendency to jump straight into solutions. There is a risk though to fall in love with an idea and keeping track of the impact we want to achieve.

Before you start to work on your solution, be clear about your objective and how to measure success.

Reviewing and measuring your progress regularly will also help you to stay more open to new ideas.

Start small: Break ideas into steps to test them

When you do have a list of ideas or see opportunities for improvements, change your big-picture lense to a narrow focus. Investigate each idea and see if you can break them down into smaller steps: what are some steps you can take that take less time but will take you in the right direction that you can experiment with?

If we take the example story I have shared: rather than starting a redesign project for a complete app or website, start by making some copy changes on specific sections of your website.

? Steps you can do in your next project:

  • Start to think like a detective: what are my hypotheses for a specific problem I identified?
  • Collect ideas, don’t feel restrained
  • Break your ideas into small steps
  • Make small updates, get feedback and iterate​​

Data-Driven Product Design Course

Want to learn more about how to improve your product design process? Take a look at my online course for Data-Driven Product Design.