We outgrew the MVP

We’ve been building lean and mean since our inception, and we’ve come to a point where a different solution was needed.

Our UI needed a major redesign. Yes, we still wanted a nimble approach and fast feedback. But we’d seen that early over-reliance on MVP (ship fast now, break things later) can cause downstream problems that compound with time.

What we needed was a thoughtful and intentional architectural overhaul alongside our new look.

Part I: Introducing the WAFL 🎉

I want to share here the thinking behind a new method (WAFL) we’ve created to solve this problem, and how to execute one on your team.

What is a WAFL?

WAFL stands for “Well Architected, Functionally Limited.”

The idea behind a WAFL is to create (or recreate) the basic functionality of a project in a codebase that can scale.

You architect your new front-end codebase with the robust framing, pervasive testing, accessibility, and responsiveness to service the world.

However, you only add back in one functionality at a time.

Are there other, more precise, acronyms we could have come up with? Possibly, but it makes our team smile to talk about WAFLs (Pronounced ‘waffles’) all day, and more smiling at work is a net positive in and of itself.

When are WAFLs healthy?

If you are at the very beginning stages of product existence and you have not yet found product-market fit, WAFLs are not for you. Your team survives by staying as lean as possible.

The WAFL approach is right when:

  • You have found product-market fit.
  • You’ve accumulated enough technical debt that iterating on new ideas quickly is a challenge.
  • Your app is feature-rich, and you want to validate your assumptions about what’s really important.

The recipe for a WAFL

Please follow this step-by-step process for authentic and delightful WAFL creation.

1.) Bake from scratch with design-thinking practices

Go back to your users. Obsessively ask the ‘why’ behind their behaviors. Get to their core motivations.

You may be surprised at what you discover.

2.) Feed the RATs with your WAFLs

RAT stands for Riskiest Assumptions Testing. It’s a philosophy that to launch a product to the market we must identify our riskiest hypothesis and test it beforehand. In this way, one knows the model’s viability without necessarily putting all the resources into developing it.

Are there any critical assumptions you are making in your new WAFL? Perhaps whether a new product concept will be understandable, whether a selection tool will be usable, or whether API data will be available? Prioritize that work first.

3.) Don’t add too many toppings

A lot can accumulate over the years at a company. This is your chance to start fresh.

Launch with only the most limited functionality you can to satisfy ONE or TWO motivations you found in your design-thinking exercise.

4.) Serve it up half-baked

No matter what users tell you in UX sessions, no matter how brilliant your Product Managers are, no matter how precise your designs, you will be wrong about some things. If Marty Cagan’s iconic book on product management Inspired is to be believed, you’ll be wrong at least 50% of the time.

So serve up your WAFL just barely done to start gathering real user data as soon as possible.

5.) Savor the feedback

The more you seek out and express appreciation for feedback, the more you’ll get, and the better your WAFL recipe will become upon iteration.

Part II: Our internal WAFL

Now I want to walk you through the situation that made us realize a new solution was needed, and share our progress toward our new UI WAFLs.

How we got hungry

Our frontend originated in a time when our product was far different than it is now. As our users’ needs evolved and grew, we simply added information on top of the old design. Over the years, our users’ needs eclipsed our UI, so we’re now embarking on rebuilding it.

As we remodel, we’re seeking answers to the following questions:

  1. How might we increase clarity for new users who are trying to discern what details to pay attention to?
  2. How can we help users navigate faster between levels of information like jobs and workflows?
  3. How can we better serve DevOps and CI Engineers who need visibility into how all their workflows tie together?
  4. How can we speed up the UI’s load time?
  5. How might we feel more comfortable as a company with iterating on our own frontend codebase, trusting its robustness to change?

Questions 1-3 are validating whole new concepts and whether they add value to our users. That would normally suggest a Lean or MVP approach.

But 4 and 5 are issues that directly arose from a prior MVP approach. While MVP is great for teams just getting started, we have a healthy user base and activity on our UI, and needed an approach that would be able to scale over time.

How does one go about entirely overhauling the face of a fast-growing app that thousands of people are already using?

You guessed it, a WAFL.

Batter the second time around

While our current UI remains live, we are allowing users a sneak preview of the new UI as an opt-in experience while we continue to improve it.

We started by launching our Job Details page WAFL internally at CircleCI. We set up a specific Slack channel to solicit feedback. Then we set up a Trello board to collect up-votes on individual requests. We’re asking our internal team to try and exclusively use the WAFL to solve build errors, and if they have to return to the old UI, tell us why.

Now, as we launch to public beta users, we also have an in-browser poll asking users what functionality they miss and need back. We’ll also continue extensive UX testing for more qualitative behavioral feedback.

Don’t end up with WAFL burns

In high school, I worked at an ice-cream parlor where we made our own waffle cones. To this day, I bear a scar on my arm from underestimating the hot iron. It turns out this would not be the only waffle/WAFL burn I carry. Here are a few lessons learned from our first WAFL experience.

First, in our design-thinking UX sessions, we found our old UI had many features that users never look at, while others had developed extensive workarounds to surface information we didn’t know they needed.

The “ideal end-goal” designs we had inherited were beautiful and well-researched themselves but did not take this ruthless prioritization of features into account.

We had already spent time developing a functionality that we no longer believed was critical to the needs of our users. We pulled it. If it’s important, that will become quickly apparent when we UX test the new page with users and we’ll add it back.

Second, don’t rely on design feedback if you can get behavioral feedback. Our designer had spent days of work and multiple group reviews iterating on a selection tool to switch between parallel runs of jobs. We thought we nailed it. But then we launched, and no one could figure out how to use it in practice. We’ll now have to iterate again.

Third, do not underestimate how difficult it will be to narrow down your WAFL to just a few features. While everyone will agree that this is a good idea in theory, in practice there are limitless opinions on what bare-necessity functionality means. You’ll have to be extremely familiar with your users and have many examples to back up your reasoning.

Fourth, be ready for some backlash. When we launched the preview page with just a little bit on it, our first round of comments in our in-app survey included choice quotes such as, “omg are you guys nuts lol”. Lol indeed. But the bright side is that by going to such an extreme on eliminating functionality, we got really clear and valuable feedback on what people needed back most. The ultimate win!

Last but not least, build a positive and experiment-minded team culture.

My high-school ice-cream parlor job was one of the most stressful I’ve ever had because everyone there was miserable. What we’re doing with our WAFL approach would not work if we had a team that couldn’t handle failure, negative feedback, or bad pun jokes. Building a team where we ask about and honor each other’s feelings and approach everything we do as a fun experiment is more than just syrup on top, it’s what’s holding us together.

What’s next?

Our first WAFL, a new Job Details page, is being beta tested on an opt-in basis for limited numbers of users now. If you’re interested in seeing it, mark yourself as a beta tester in your CircleCI settings.

Next, we’ll ship our WAFL as the new mobile default for our Job Details view before moving on to a Workflows view revamp.

Want to do a UX test with us? You can sign up here!

Do you have thoughts or feedback about the WAFL? I’d love to hear them. Tweet at me here.