Measure twice, cut once

How does an ancient carpentry expression apply to digital product design?

Consider this expression, well known in carpentry:

Measure twice, cut once.

We’re talking about wood, of course. Now, carpentry is a lot like any kind of design: We’re talking about designing and making something for a client here. The client has very specific needs — a specific room that the furniture needs to work in, for instance. Here’s a scenario:

Ola has a new loft conversion. She hires a carpenter, Julia, to make a staircase so she can access it. Julia starts cutting wood, to see if it will fit in the spaces required.

This is obviously ridiculous. No carpenter would ever do this. Imagine how long it would take Julia if she cut the wood first, then measured to see if it fitted! Imagine the waste of time and materials involved!

But amazingly, many teams creating software do exactly this. They ‘cut the software’ — a process that can take weeks, months, or even years — THEN they measure the results.

You can imagine what happens — people can’t use the software. It doesn’t work as intended, they don’t understand it, and it doesn’t meet their needs. In short, it’s a waste of time, and the team will have to go back, try to measure what’s needed, cut again, and eventually measure again. The vicious cycle continues.

How does this apply to software?

OK Bill — you’re talking about carpentry, this is all very well but how does this apply to digital product design?

First: Design is an old and noble tradition. Older even than carpentry! The lessons we’ve learnt over the millenia about designing and building things apply perfectly well today.

As a design instructor and mentor, I encourage designers to help their teams “measure before they cut” — saving them the time and expense of building the wrong thing. With just a little upfront effort, we can save product teams from ‘building blind’ and making expensive mistakes. By measuring ‘up front’, we lower risk, and speed up the process of ‘getting to good’ — building products that provide value by solving real user problems. Here’s how we do this:

  1. We measure what users want — through interviews, surveys, and by prioritising feature requests.
  2. We measure the appetite of our stakeholders for the feature — how much effort do we want to put into building it? Do we want something basic in two weeks, or do we want the deluxe version in six?
  3. We measure how effective our ideas are, by designing and testing mockups and prototypes. This helps us build confidence in our solutions, till we get to the point where it makes sense to commit an engineering team to building something — ‘cutting the wood’.
  4. Once a feature is released, we measure how well it fits the needs of our users. How could we improve it? What’s missing? Bigger feature requests will have to be prioritised for the next cycle, but sometimes we can quickly fix small details that make a big difference to the product experience.

The confidence to cost dynamic

“Measuring twice” is relatively cheap — the cost mounts as you move upwards in fidelity. If you’ve done your job well at the ‘measurement’ stage, you can be confident that building your design will add value for your users and the business.

Cost <> Confidence relationship chart.

When collaborating with product teams of researchers, designers, and engineers I advocate for a structured design process:from early sketches to mockups, to a Figma (or similar) prototype, to a code prototype, and finally to the working product. At every stage we gather feedback from our users (“measuring”) to make sure we’re on track. At every stage, we lower the risk that our investment (of time, and people, and ultimately, money) will fail.

Without clear measurement criteria in place, the first instance where you find out that the ‘successfully’ released project isn’t so successful is usually when the complaints come rolling in — or revenue starts to take a hit.

Rob W, HSBC

What about when the software is ‘cut’?

Obviously, once ‘cut’ the design is not set in stone. Working in software means we have a malleable material — there is no need for a design to remain static once built. However, the problem with changing software is that it’s expensive in two main ways:

  1. The costs in time, people, and money for your company
  2. The costs to customers as they have to re-learn your software

For this reason, it’s always worth testing ideas quickly and cheaply before you invest in building them. Get things right, or as close to right as you can the first time and your customers will love you. Sketching, prototyping, and testing your designs is the way you measure first.

Many in the incubator community will argue you only need a minimum viable product. I obviously take issue. Building something doesn’t make you a business!

Shaun Illingworth

In summary

It might feel quicker just to ‘build something’ in code, but in practice this tends to be a slow and risky process. So — when planning your next product or feature, remember the carpenter: Measure twice (or perhaps, several times!), and cut once.

Images by yours truly (you’re welcome)

How do I get started?

There are so many resources available, but if you get one book on testing designs make it Sprint by Jake Knapp. So many great techniques in this book that you can apply in many situations, not just short sprints.

Another book well worth looking into is Lean UX by Jeff Gothelf. Everything you ever wanted to know about building a successful product, fast.

Finally if you’re new to UX in general, check out my guide here: How to Get Started with UX.

Design principles in practice

Designing complex products isn’t easy.

As a junior designer, I made the mistake more than once of jumping straight into a design app and pushing pixels, without first considering the bigger picture.

As I learned my craft working with large tech companies and small startups, I discovered six principles that now inform the work that I do—and which guide the efforts of the broader Hopin Design team.

In this article, we explain these product design principles and and illustrate how they show up in the work we do at Hopin—specifically, through a redesign of our event setup dashboard that we completed in early 2021.

Design for our event setup dashboard beta in January 2021

6 Design Principles at Hopin

  1. Solve a real problem
  2. Consider the structure
  3. Collaborate for strength
  4. Design just enough
  5. Test your solutions
  6. Design is never done

As the market leader in virtual and hybrid events, Hopin has built its reputation on stellar user experience.

Our event product has two sides—one for event organizers, the other for attendees.

Since releasing the first version of our event platform in 2019, we have listened to our customers and evolved our products to ensure that they meet the specific and changing needs of our audience.

Here’s how:

1. Solve a real problem

As digital product designers, job is to solve real business and user problems through design.

In practice

When we began thinking about doing a major overhaul of our event setup interface in early 2021, we knew we’d have to get tactical about which problems we would try to solve. So we began by identifying the key problems our users reported. We spoke to:

  1. Event organizers—both those who ran events every day, as well as those who were new to our platform
  2. Our Customer Success team
  3. Our Support team

We also dug into our chat help system to identify the kinds of problems that kept recurring. We categorized and filtered the feedback, to identify three key problems with our event product:

Key problems
  1. “It’s hard to know where to start when setting up an event.”
  2. “How do I know when I’m done?”
  3. “I can’t find [that thing] that I need!”

Having identified the problems, we were now able to begin considering and developing solutions. We worked in two main teams — my team concentrated on the third problem, while an “onboarding” team focused on the first two.

2. Consider the structure

Design goes deep. When solving any complex problem, Jessie James Garrett’s Elements of User Experience is a useful touchstone. I consider what level I’m working on — and if it’s the right level to tackle the challenge I face.

5 planes of UX from Jesse James Garrett’s “Elements of User Experience”

In Practice

As we listened to our event organizers and observed newcomers setting up events, it became obvious that we needed to dig deep into the structure to fix the fundamental problems.

For business reasons, we had to move quick.

Given a limited timeframe, we couldn’t reconsider the entire event creation strategy or scope—but by working our way up the stack, we determined we could rethink the structure of the navigation (i.e., the “information architecture”).

Starting at this deeper, more fundamental level was a guarantee that our work would have more leverage and make more of a difference to the resulting user experience. 

One key piece of feedback we received was that pages were hard to find in our current menu. While the menu was divided into sections, it looked like a flat hierarchy. 

So our first task was to create a better way to categorize menu items and consider better ways we could lay these out.

We began this process with a series of short sessions with the Design team, Customer Success, and Support — to make sure that we had a logical and consistent structure for our navigation. 

Working at an abstract level, we were able to iterate fast and build detail in our designs—without getting bogged down by layout ideas.

Navigation hierarchy iterations

Once we had a structure in place, we then reviewed the skeletonHow could we create a more consistent and clear experience at this level? 

We looked at competitors and comparators, including some niche products that only a few of us knew. Drawing on a wide range of influences gave us a competitive advantage, because we needed a diversity of ideas for inspiration.

An early sketch from an ideation workshop with the Product team

Finally, we looked at what many people think of when they hear “design” — the surface level of the interface

We finessed details of typography and iconography, gave everything a visual polish, made sure our components were consistent with our wider design system, and checked color accessibility across all areas.

3. Collaborate for strength

Design is seductive. It’s easy to get distracted by the surface layer of shiny interfaces, smooth animations, light, and color. 

Indeed, as a designer working on digital products, it’s easy to silo yourself in an ivory tower. However, it is essential to remember that your work is part of something larger.

Your design always exists as part of a larger ecosystem—and your designs can always be improved.

As much as I may think my design solutions are great, I know from many years of experience that running them by other designers will always make them stronger. 

Moreover, this process of collaboration, and the learning that emerges, makes a design team stronger — producing better results throughout an entire product.

4. Design just enough

It’s essential to keep in mind that the designs you work on every day are essentially just digital trash. They will be discarded once the real thing — the actual product—is in use. The designs are mere blueprints.

In the end, the product is what counts

In practice

While designing solutions for the navigation and structure, we designed just enough to test the idea. 

After our pivot to an accordion layout, we built a prototype of just the first few dashboard areas to get a feel for the interaction. Did it make sense with the first few areas? Was this enough to indicate it would work elsewhere? 

With these basic requirements satisfied, we were able to comfortably discard our prototype and start building the real thing.

5. Test your solutions

A key principle in software development: Success is what happens when you’ve failed every other way. 

You will always fail the first few times you make anything new — so choose where, and make it quick. 

Learn fast, fix the problems, and move on. (One example from real-world products: WD-40 was the 40th attempt at making a water displacer.)

In Practice

We needed to learn quickly what worked and what didn’t. 

Working with our researcher, we created a quick information architecture test . How would our current flat hierarchy perform against one that was divided into structured areas? 

The results were surprising and amusing. While “time on task” was roughly the same, 48% of our participants completed the test of the current flat hierarchy format, compared to 86% of those asked to find items in our new, structured list format.

Flat hierarchy vs. structured test. In the flat hierarchy test, 52% of users dropped out due to frustration.

This gave us confidence that we were on the right track. So we built out a detailed prototype of the entire dashboard, so we could test the interaction model and layout. Would it make sense in practice?

Iterations on navigation. Working in Figma, we were able to rapidly prototype and test these ideas before development

The feedback was fantastic . Users loved the look and feel of the prototype. Everything felt fast and better structured. 

However, in practice we soon ran into the key problem mentioned in part 2: Your designs are not the product. 

Our prototype whipped through pages at speed, delivering an instant response as users navigated. Unfortunately, in practice, we were unable to deliver the same speed in the actual product.

When we put a coded prototype out as a beta for testing, we added a feedback form. A common theme quickly emerged : It felt too slow, as the navigation model required a page refresh each time the user went “back” to home.

We needed a quick pivot to solve this problem — and, fortunately, through our collaborative process and exposure to many ideas, we had one ready. Which brings me to the 6th principle.

6. Design is never done

To paraphrase Paul Valéry: “Design is never finished, only abandoned”.

In Practice

Once we had our new layout available in the actual working product — we really started to learn how effective our solution was. Did it solve our user problems? How could we improve it?

Figma prototype used to fine-tune the accordion menu interaction

Our quick pivot to an accordion model solved the problem of speed. A page refresh was now only required when selecting a menu item. Our users loved the new layout, the clarity of the tables, and the overall structure. 

As we add new features to the product, and learn more about how users are interacting with it, we’ll need to iterate again.

Design is really never done, but this constant process of improvement is what makes good products great.

Average scores from 0-10 collected via our feedback form

By applying these design principles to our work, we are able to work methodically and maintain a consistent level of quality at scale.

As a diverse and global team, through close collaboration, we are able to create designs that are better than any one of us could create alone.

Ultimately, the test of our work is whether it delivers real value to our customers. Design does not exist in a vacuum. Its efficacy and quality is only discernible when it is out in world and our users begin interacting with it.