Rationalize design through numbers, not analogy

How many times have you sat in a design review and had seemingly unjustifiable opinions thrown your way?

I’ve lost count. You probably have, too.

I’ve proposed a numbers-driven adaptation of Intercom’s Design Review Template as part of the solution. Check out a worked example of this template below. 

Then there’s the economics of design. This is something that’s been written about right here on the InVision Blog.

So what’s left? Where’s this article going? Why more about numbers and design?

This article is actually about arguments. Specifically, the arguments between you and your colleagues. You know, the ones where you need to rationalize your design output? Yeah, those.

Related: Design debt

This article is about giving you a framework to support these situations. It’s not about right or wrong. It’s certainly not about stroking your design ego. It’s about producing designs that make their way into the hearts, minds, and wallets of your customers.

To achieve that, you need to rationalize design through numbers, not analogy. And the easiest way to do that is with a framework—something you can consistently rely on to support you in achieving your objectives.

The framework

This framework is easy to adopt. It’s easy because it’s not about introducing new research or design activities. It’s about how you synthesize and communicate your existing process. It’s about systematically supporting your process and building appreciation for that process across the business.

By doing this, the “seemingly unjustified opinions” we’re all familiar with with remain just that—unjustified. The design process and validated output will win.

Let’s break this down into 3 easy steps.

Step 1: Metrics that matter

 

The people I work with must think I sound like a broken record. I constantly harp on about the metrics that matter. But that’s because they really do matter. 

Step 1 is all about where you start. It’s your frame of reference. Here you define the metrics that matter most to your given design problem.

These metrics might relate to the value, meaning, and engagement of your user’s experience. They may relate to the business value solving the design problem could generate. They might even relate to how this piece of work will help unblock others. 

When defining these metrics, use a model you’re comfortable with. Use a model that’s contextual—something the business can comprehend and accept.

I’ve found spreadsheets helpful. I’ve found Aha! and JIRA to be useful. I’ve also found sections of the design review template referenced above to be extremely useful.

Regardless of how you document this, document it. Make sure it’s clear. Make sure it’s accessible. Then actually use it as your frame of reference.

Ultimately these metrics will determine if the design solution is deemed successful. 

Step 2: The process

Design is a process-oriented discipline. This process should be widely understood across key stakeholder groups within your organization.

I’m not saying they have to “get” the nitty-gritty detail. But knowing what you do and why you do it helps build empathy. This is a 2-way thing. Understanding why other business units do what they do, and why they do it, will make you a better designer.

Rather than the flexible approach to step 1, I’ve found a fairly specific approach works best when it comes to process. It has 3 stages.

Stage 1: Define and document the process

At >X, our process or “methodology” drives how our services interoperate.

It starts on our website. It factors into discussions with prospective clients. It helps with planning, prioritization, and focus. And it gives our clients a clear understanding of what we do, why we do it, and how it’s going to impact our work with them. 

But this is just the start.

Stage 2: Contextualize the process

You now need to bring a focus to your process. This is where you get to show how the process will impact this specific design project.

You could document this simply. You could use a tool to do this. We’ve found a visual map works best.

For us, it ends up looking something like this:

Once you have this view, you can work on buy in. From there you can execute quickly and with clarity. 

Stage 3: Showcase visibility of tangible progress

And here I’m going to commit a cardinal sin. I’m going to propose you use a spreadsheet…

I’m proposing a spreadsheet because it’s easy. It’s even better if it’s something that can be shared and viewed by multiple stakeholders at once. The barrier to adoption is also really low, so I’m hoping this is something you try.

A >X, this takes its simplest form in a Google Sheet.

Looks kind of like a project plan, doesn’t it? In reality, it is. It’s a simple, visual view of the “approach hypotheses” you have. These hypotheses relate to how you think you’ll get from where you are now to where you’ve defined you want to be. But most importantly, they give all relevant team members and stakeholders clear visibility of the tangible progress you’re making.

Depending on your style and approach, these could provide the view of a week, a fortnight, or a quarter. The further out you look, the less certainty. So take anything other than a few weeks out with a grain of salt.

The rule of thumb: Focus on minimum valuable documentation. A little forward planning always helps, but don’t plan for the sake of planning. Always keep it appropriate to the context.

There are a heap of tools out there that can help make this easier. My advice: Either use what you’re already using, or take the path of least resistance. This path is often a spreadsheet. It’ll help you progress towards rationalising design through numbers.

Now it’s time to move from hypotheses to validated output.

Step 3: Validation

Every design team has a slightly different process for this. Some ship new designs early and often. Others develop proxy validation measures through qualitative research. This will depend on your context. Regardless of how you validate, your approach should be clear and repeatable.

We use a printed version of the Experiment Card below to do this. We then attach the designs we’re testing to the card and make it visible for all to see.

This gives us clarity for why we’re testing, what we’re testing, and what success looks like. It also gives key stakeholders the visibility they need.

Most importantly though, we can back up design iterations with hard numbers and real insights. 

So where do we get to with all this?

It comes down to 3 things:

1. The metrics that matter become your shared language
2. Documenting the design process and showcasing visibility of tangible progress builds empathy
3. Validating design output gives you the numbers you need

The combination of these 3 things shifts the nature of the conversation. Stakeholder preference becomes a lower priority. Designs supported with real, meaningful customer and business metrics become the focus.

If you apply this framework, internal dynamics will shift. Your meetings will focus on what actually matters: creating customer value.

And those highly subjective discussions will become a thing of the past.

Read more by Nathan Kinch

• How to turn an error state into a conversation starter
• What’s your value proposition?
• Design for the 5 senses