Design Framework: manage complex design problems & scope

Millions of customers from over 120 countries use Headout every month to book experiences like guided tours, attractions, and activities.

We have over 5,000 listed products; each may have several partners fulfilling the experience. For these products, we generate more than 5,000 types of tickets on our platform.

This is how most of these tickets looked like:

Customers were missing out on their experiences because of bad ticket design! The most critical of these issues were:

1. For print tickets, customers were missing out that they had to print it
2. When the customers received a mobile ticket they would reach the location only to find out their network/internet does not work
3. Customers were missing out on the location they’re supposed to reach
4. Customers were not able to locate the Bar Code, QR Code, or the partner ticket ID required to access the experience

The content & marketing team did an audit & redesigned the ticket:

There were some improvements. However, the problems wouldn’t go away.

At first glance, we see several issues like:

1. That QR Code looks like a way to access the 5% discount; it’s not — the on-ground staff scans it to validate the ticket
2. Most people will skip the text (it’s critical to read it)
3. Maps look better, but there is visual noise and the contrast ratio doesn’t survive a black & white printing

With an ever-growing number of listings, tickets, and use-cases we needed something more robust.

Let’s take a look at the information we are communicating. Here’s a list (most of) the variables that go into a ticket.

Most of these variables have at least two states (Present & Absent); some have 4+ states & several ways to represent the data.

That’s 30+ variables with at least 27x2 = 54 states.

Our simplest ticket uses 7 variables (7x~2 states = ~14 states) from the list. That’s ~3,432 combinations. [ C(n,r) => 14!/(7!(14–7)!]

With the remaining 20+ variables — There are at least ~1,84,756 combinations that exist!

Of course, not all these combinations would be realistic, but even if we were to take a conservative estimate, only 10% are realistic; that leaves us with at least 1,800 additional combinations to design for.

We need a better way than iterating each possible combination. Or checking if it’s realistic.

Building the Framework

We create design frameworks to manage complex problems like these. What’s a framework, and how do you create one? Let’s learn by building one!

We are in the process of building our Design System. The goal of the building this system is to aid designers in:

1. Understanding the problems: For this, we use design frameworks
2. Iterate solutions: For this, we make component libraries and style guides like — UI Kit, Print style-guide, Ad style-guide — which are all documentation of constraints & decisions

We start with problems. When in doubt, focus on understanding the problem better.

Some context can help us tame the ticket madness. This is where stories of our customers, who used these tickets, came in handy. We didn’t have to look too far — the customer ops. team had detailed stories of these customers, and we had NPS comments & support tickets raised by the customers.

These stories & narratives can help reveal insights, and validate our hypothesis.

At this point, we have a fair amount of data, stories, and evidence for the next step:

Our old friend — mapping. Here are 3 example maps we could draw:

1. Customer who bought the ticket over ~24 hours before the experience
2. Customer who purchased the ticket within less than ~24 hours before the experience
3. Customer who purchased a combo which may generate a single, two or more tickets ( this leads us back to #1 & #2 as sub-journey maps)

Let’s see what use-cases emerge, as we try to map our customers’ journey:

As we draw our timelines, we get a better view of what happened before & after the problem(s), and how these events relate to each other.

Designing for the happy path may seem like an obvious step, but what happens on the unhappy paths are constraints for the happy path.

This exercise gives us:

1. Use-cases: that we’ll design for, including the problem statements we started with. We use the information/variables and their various states & representations to solve these problems
2. User Concerns: that allow us to make “groups” of these use-cases, which, further, allows us to:

• Control & document side-effects (shared use-cases and/or information)
• Allow us to prevent the problem; rather than “fixing” it with reactive support
• Prioritize which user-concerns should we iterate, test, or deliver first (based on frequency, cost, urgency, etc.)

The First part of our Ticket Design Framework is the definition of the problem landscape.

Now, we can ask useful questions to our teams (data, tech, category, support), like:

1. How often does this happen?
2. How many tickets do we generate every day with these vs these iterations?
3. What’s the typical count of people per booking?

Or to our customers (not verbatim):

1. What happened after you got your tickets?
2. How did you make sure you’re at the right spot?

This helps us prioritize and tame the scope of work.

Now we start to study how these variables relate to each other, and we can make guidelines around how to best design for them.

Let’s take the example of these variables & the states they may exist in:

Let’s say we have to add another variable to this structure:

Well, that was easy! Also, at this point, we can check for all side-effects.

Let’s go one step further — what’s the best way to communicate Validity?

Not only the were we able to understand the problem, the solution (communicate information), and architect the information, but this also allowed us to think harder about the small details.

This makes iterations more meaningful, and you can quickly check them against your problem statement.

The Solution

Our guides were hard to spot — another problem highlighted by the NPS comments. So we designed T-shirts for our guides:

Here’s what the final tickets look like:

The Mobile Tickets

The Print Tickets

Why use Design Frameworks?

1. Document problems & nuances
2. Understand, tame & prioritize the vast scope
3. Separate the problem from the solution: We can keep trying different solutions & ideas, without losing sight of the problems. We can test & measure our iterations against these problem statements & use cases.
4. This also helps inform Product KPIs and Non-Functional Requirements (for ya’ll PM’s out there).
5. Document & understand feedback: Did we get the problem wrong or the solution doesn’t work? Or some other solution is better because of x?
6. Help us solve better, by allowing us to isolate the relevant parts and dig deeper

Here’s (almost) the entire process visualized:

Do you see the value of using Design Frameworks at your organization? Does your Design System document problems? What are the parts you find useful or unusable?

Originally published on my blog:

PS: This article is a result of the conversation on twitter, followed by a video: