Why we built Maze Discovery: A look at our recent product launch

May 21, 2020

Building the right product starts with a deep understanding of the problem. If you go into the design and delivery process without validating the solution, it will most certainly backfire.

Great solutions make the user central to the experience. If your product doesn't address people's needs, likely, it won't succeed. Similarly, if you don't test your design with real users, underlying issues will hinder their experience.

"We must learn what customers really want, not what they say they want or what we think they should want."
Eric Ries, The Lean Startup

Learning from and about users is the key goal of research in the product development process. Making informed product decisions starts with insight into the people you're building for and a deep, comprehensive grasp of the problem.

That's what our latest solution—Maze Discovery—is all about. Testing and validating product ideas is no longer optional—the costs of building the wrong products is simply too high. The faster teams can validate their ideas, the quicker they can go into creating the right solutions, the less time and resources are wasted on the wrong things.

In this article, I want to go behind-the-scenes in our decision to build Maze Discovery, the choices that influenced the final solution, and the lessons we learned along the way. The road to building products is never straightforward, so here's ours.

Same vision, complementary solutions

At Maze, our vision has always been to remove the guesswork from building digital products. Maze Discovery has its roots in this same vision, but the solution only started to take shape after a couple of iterations and customer requests.

In the beginning, one question formed the basis of our thinking: "How do we provide our existing customers with a way to test their ideas even earlier in the process?" For us, this is essential. When a design team goes into the prototyping stage, they should already have validated their solution with real users.

Posing this question meant rethinking our product from start to end. With Maze user testing, our customers' first interaction with the product is importing their prototype. That's also been the main call-to-action on our website since we first launched. If we wanted to allow customers to do research at the discovery phase before they even have a prototype—that interaction was no longer going to be first.

Creating a Maze project: Before and Now

After receiving requests from users and speaking to some of them one-on-one, the ability to create Maze projects without a prototype seemed paramount. It was the key decision that shaped Maze Discovery at the very start.

Another similar choice we had to make concerned the concept of mission, which is an essential element of prototype testing with Maze. With discovery projects, missions are no longer there. Instead, you're able to create and run research surveys and do product explorations—without being constrained to a prototype.

It soon became clear we had to rethink a lot of what Maze was. From product interactions to messaging—and the way we think about Maze generally—we had to go looking for new answers.

Building the missing layer

At Maze, our entire team involves users throughout the production process. The more we talked with our customers, the more we learned that different research activities took place in separate tools, depending on the type of research they needed.

With every step of the product development process requiring various types of research, a lot of it happens in siloed tools (e.g., surveys before designing or usability tests once the design is finished).

Our design team looked at potential features that would consolidate our customers' activities, allowing them to run comprehensive research in one place. With the validation of the requests received, we settled on three new blocks.

We worked on 5-Second Tests, Card Sorting, and Tree Tests as the first steps toward unifying our customers' research. We went through a few design iterations when testing these three new Maze features, and arrived at solutions both our team and our customers were satisfied with.

Design iterations for the blocks menu

One crucial principle underpinning our design team's work was making the data collected by users accessible across the board. For example, for the Card Sort block's results, we made a conscious choice to emphasize the agreement rate. There are several ways you can represent card sorting results in a research tool, but our goal was to make the data readable by non-researchers.

With Maze Discovery, we wanted to focus on simplicity and give the user the most important information at a glance.

This focus data comprehensibility is at the core of our mission, as we've aimed to make the data in features like Smart Heatmaps, the Maze Report, and Rich Testing as readable as possible.

Learning through the process

As a small team with limited resources, there are lots of things we didn't get right at first and are still working our way through.

During the process of building Maze Discovery, we learned some valuable lessons, and we wanted to share these with our community. Hopefully, other teams going through a similar process can find these useful.

1. Decoupling the release from the launch

One important choice we made during the process of building Maze Discovery was decoupling the release from the actual launch. We introduced a one-week buffer time between release and launch, which allowed the product team to monitor the features' performance in real-time, without the pressure of a marketing launch.

This decision came after many previous attempts at delivering a feature on the exact day we announced it. Ultimately, this led to a smaller backlog of fixes and reported bugs, and we went into the launch more confident than ever before. It seems like a no-brainer now, and something we should have done much earlier.

2. Naming research, like all research, has to occur early

Before landing on the name Maze Discovery, we went through several naming iterations internally. The major mistake we made at the start is basing the name on gut instinct and enthusiastically adopting it in all our internal documentation, code, and conversations.

Once we realized the name didn't fit with what we were building—and after researching potential replacements—we had to change everything from code to marketing plans to internal documents to the new name. For a company that advocates research early in the process, we had to learn this lesson ourselves.

3. A product launch doesn't end with the announcement

Throughout the process, our entire team focused on providing value and delivering the solution to our customers. Now that the launch is behind us, a lot of work remains.

As mentioned above, Maze Discovery brought on a new stage in our startup journey. We're now focusing on updating our website and communications to reflect these new changes. We'll also be working on improving the solution and ensuring our customers have the best possible experience.

What's next?

Our goal at Maze is to provide an end-to-end research platform that gives product teams the tools to test ideas at each step of their process.

From validating an initial product idea to testing a high-fidelity prototype—and anything in between—each of these activities involves a continuous learning process from customers.

We plan to introduce new and improved methods to acquire insights from your results, compile and highlight the findings you made, and empower you to find and build your database of participants. With feedback loops enabled every step of the way, product teams can deliver great products customers will love and use.


We're excited for you to try out these new features. As with any beta release, this is just the beginning of Maze Discovery. With that in mind, leave a comment on our feedback board if you have any feature requests. And let us know what you’re building—we’d love to hear from you on Twitter!