Design as a tradeoff

Tradeoffs in product design.

A product is a system that consists of many parts. Once launched, each of the parts goes through multiple iterations. This can lead to a feeling that the design is never final. I experienced this exact feeling while leading, launching and iterating the product design for Fairy.

In the beginning, while going through these cycles at Fairy, I felt that some things we did were never finalized. Things changed very fast — the design and solution were never final. We constantly learned from our users and changed. As I was going through this I understood the value of tradeoffs as part of the process of finding the right solution. This article is a reflection of my 2.5-year experience leading product design for Fairy.

Fairy was a marketplace that connected customers and housekeepers for a single or recurring cleaning. In our 2.5 year history, we completed over 200,000 cleanings until our acquisition in early 2019.

Here are my key lessons regarding trade-offs in a quickly-changing product.

“We will fix it all now”

There is a common misconception that once you find the core issue of the problem, you need to fix everything all at once. Customer research, design sprints, and user testing may further support this thinking. Alas, it’s more likely that a fully thought out solution does not fix the problem. In reality, it’s always a small set of iterations that can solve the problem. Large redesigns are almost never the right answer.

Design practices cherish the idea that we should spend a lot of time building a full end-to-end solution that touches all aspects of a problem. While researching the problem, you inevitably encounter other use cases and corner cases. This can lead to prototypes/diagrams that have dozens of additional screens, complicated logic, use cases and even more important, lots of required product changes to supposedly solve the problem. Such a solution may require weeks or months of development, which is time that is very scarce at a startup.

The reality is that you will usually face one or all four limitations:

1.      Time;

2.      Resources;

3.      Technical limitations;

4.      Current mechanics (state of the system).

So how should we approach the problem when faced with these limitations? Here’s a framework.

We had three approaches when facing a problem at Fairy:

      Test interest;

      Build a feasible v1 solution;

      Improve the existing solution.

Depending on the goal we could reasonably debate on tradeoffs we were willing to make.

A useful thing to do when you work on a problem/solution is to take a step back and describe a North Star experience. This that should not be a detailed prototype, it should be a reference, something like a simple, described flow, no UI at all, touching the physical experience customer can have outside the platform.

Testing Interest

When there isn’t enough data or the hypothesis is based on a gut feeling, “fake it till you make it” is an effective approach. The main goal of testing interest is to collect evidence that the solution being proposed, is the correct one.

At Fairy, we had a hypothesis that switching from monthly plans to on-demand cleanings with a small membership fee, will increase customer retention.

Instead of building the whole membership UX, we decided to test interest by suggesting a yearly membership to customers when they booked their next cleaning. We offered free cancellations and removed the booking fee if the customer applied for a membership. We waived the first month’s charge of $9.99/mo to decrease the time to design and implementation. The goal was to see how many customers would opt-in *thinking* their card could be charged such that we can see the impact on retention.

As a result, we only added one new screen where we ask to apply for membership + updated checkout screen.

Tradeoffs when testing interest

Functionality tradeoffs. Build the minimum functionality required to test user interest.

Use cases. Avoid corner cases and trim use cases. It’s better to build for one use case that would provide the highest signal on whether it’s a promising solution.

Fake it till you make it. If there’s no interest, this would minimize your design and development cycles.

TIP. At this point communication is crucial. Dedicate efforts into copy that is clear and understandable.