Welcome to part 2 of the Typeform v2 rollout story. In this three-part series, we peel back the curtain on the revamp and release of the new Typeform.
Part 1: Inside Typeform version 2
Part 2: The new Typeform—what took so long?
Part 3: Rallying the entire company to launch the new Typeform
Remember when we sent you that Part 1 article? Probably not, because it was over a year ago.
Since then, we’ve miscalculated a few ingredients and thrown some half-baked pies at generous test users. But we’re pretty sure that what’s about to come out of the oven—Typeform v2—will be worth the wait.
There were things we didn’t anticipate, wish we had figured out faster, or flat out wished we hadn’t done. Maja says it best:
And now we want to share all those takeaways with you.
Way back in 2012, an Alpha version of Typeform set sail. Two years later, we officially launched Typeform (version 1)—and that’s what millions of people have been using ever since.
This means that the Typeform you’re used to is based on UI/UX designs that are five years old. It’s still the easiest form-survey-quiz builder out there, but let’s be honest:
These details matter, a lot. You should be focused on the people you want to reach, the information you want to collect, and the impression you want to leave on the people you’re taking to. The building part should be effortless.
So we kept asking ourselves, what would a better Typeform experience feel like? Our idea was this:
The problem was, we never validated that people wanted to create forms this way, or that it would significantly improve their experience. We had no data to justify the investment.
Eventually, people around the company started asking why. Is this even going to change anything?
But we were so far in, there was no going back.
So we started testing our intuitions: Would removing friction from the building process help people create faster? Would it encourage them to build more typeforms?
Yes and yes. Our head-to-head tests showed that people were 2x faster creating with the new Typeform. And time to activation—how long it takes a new signup to create a typeform and start collecting results—was significantly lower with the v2 builder. Whew. We were on the right track.
Before committing to a big project, ask yourself why. What problem are you solving? Is it something your customers want, or something you want?
Somebody should have said that. But for so long we didn’t have this sense of urgency. Things were going well, we were growing, and we were having lots of fun experimenting.
So for a good six months, we had no firm timeline, no metrics, and no real roadmap. Just ideas and a small team of developers.
Like when we built a mobile LITE prototype to test whether our v2 document-writing idea could work. This gave us proof-of-concept, but we had no real success criteria. It was more like, “Let’s build an mobile app because that’s what startups do.”
Finally, people started questioning our scope: what we planned to deliver, when we hoped to deliver it, and how we were going to make it all happen.
Our first answers were off—we underestimated the complexity of the project. But it prompted us to outline a roadmap to keep us on track.
Projects start with scope. Have a plan, map your milestones, and try to stay on track. You may not hit every deadline, but at least you’ll have a target.
We spent months building for ourselves. Sure, our motivations were 100% aimed at our customers. But we worked in a instinct-driven bubble, instead of checking in with the people we aimed to please.
Then came the moment of truth: what do our customers think about all this work we’ve been doing? Here’s where we looked for validation:
Internal release. Show it to non-product people in the company and see what they think. Keep it anonymous, so people stay honest. But give the option to leave a name, so you can follow up with those who want to chat.
UX testing. Ask people familiar and unfamiliar with your product to give it a whirl. Get their qualitative input while measuring product usage: Where do they look and click? How do they navigate? How long do they take to complete a task?
Key customer feedback. Talk with the people who actually pay for the product or are highly active. These are your best friends—keep them happy.
A/B testing. Conduct a head-to-head test with two different product versions. Have one main goal and a clear metric. This is how we confirmed that version 2 is 2x faster than the old Typeform. 🙂
Release and learn. Test new updates and feature releases on small user groups. Get their feedback, iterate, repeat.
It took us a while to turn this feedback buffet into nourishment. But once we did, we based everything on product usage and customer voice. And the benefits were clear:
“Having a specific goal and delivering something that people could touch was a big victory for the team. We saw that our work mattered.” – v2 product engineer
“Product developers now had the mindset that they were doing something because it was the right thing to do, not just because someone was telling them to do it.” – v2 product manager
“Rolling out new updates helps us learn. No more guesswork. Release, listen, iterate, repeat.” – v2 agile coach
Don’t build in a bubble. Talk to your users and listen to what they have to say. And be ready for those things you don’t want to hear.
Did you know that Typeform’s cofounders are both designers by trade? That’s a big reason why design thinking—tapping into empathy to create the ultimate user experience—has always led our product decisions.
Well, it also turned out to be a blocker.
At the start, our designers came up with all the solutions, and then handed over the blueprints to developers. You can imagine how thrilled our engineers were with this. You want me to build what?!
Since then, we’ve learned to blend design-driven and data-informed decision making. And we’ve opened up key conversations earlier in the process.
Balance autonomy and teamwork. Give everyone a voice from the start, so that people are motivated, aligned, and heading in the same direction.
From the earliest ideas of v2 ‘till now, Typeform received Series A and Series B funding rounds. That led to a couple periods of hyper-growth, exploding our headcount from around 30 to nearly 200 people.
That means more people to get things done, right?
Sure, kind of. But it’s not just about sticking new bodies in existing teams. For us, it meant rethinking our entire organizational structure.
Since we started v2, our engineering teams alone have undergone two major re-orgs. And these changes don’t come cheap. More from Tom on this one:
Big changes bring switch costs. People need time to adjust to new teams. Communication gets trickier. New hires need time to get up to speed. And management has to adapt too.
More people don’t automatically equal higher productivity. Keep experimenting to find the structure that works best for your teams.
This whole thing started as a UX/UI issue: we wanted to improve the building experience for Typeform users.
But it got wrapped up in a technical issue: our underlying architecture needed an overhaul to scale with our vision.
So along with revamping the Typeform builder, we had to migrate our entire infrastructure to microservices. Translation: everything works better now.
Redesigning your entire front- and back-end at the same time is like going in for a nose job and hair implants, and getting a heart and brain transplant all in one go.
But if what comes out holds together, what you get is more beautiful and robust.
Putting lipstick on a frog might hook a few interested customers. But sometimes the changes you need are more fundamental.
The initial “plan” was to build v2 entirely in isolation of v1. And when the magic day came, we’d flip the switch and—voilà! Confetti streams down, corks fly through the air, and sirens sing a sweet song.
But to be honest, we never really had a clear migration plan when we started out. (Well, we knew we wanted corks flying through the air, but the whole flip-the-switch thing needed some clarification.)
And then those familiar voices appeared: “How will we migrate from v1 to v2?” and “How will we make sure typeforms work across the old and new platforms?” Hmm, good questions.
There’s no right or wrong answer here. Basecamp swaps versions, introducing a brand new code base with each new release. Facebook has hundreds, if not thousands, of different versions running at a time.
And Typeform? We finally decided to go with a hybrid plan.
So 10% of active users got an early invitation to v2. We made sure the platform could handle the traffic, fixed reported bugs, and then released to more people. Gradually.
The downside: there’s been a period of time where we’ve had to maintain two different versions. That takes tons of extra resources.
The upside: we kept things under control, so there was never that day when the engineering manager mumbled, “Shit, everything just broke.”
We’re happy to announce that just before Christmas, we opened the v2 Beta version to 100% of our user base. And nothing broke (yet).
P.S. Remember that people prefer the status quo. So work out how you’re going to break the news to your biggest fans: what changes to expect, where the buttons have moved, and how to report any bugs that they (hopefully don’t) find.
Flip-a-switch or hybrid? Even the best changes receive pushback. What matters is that you think about how to introduce updates before launch day.
Last summer we had a company meeting. The message was this:
The whole company rallied, every nook and cranny of the project became transparent, every voice was encouraged to speak up.
After internalizing the takeaways above, we were ready to kick v2 from the nest.
So how did pull together to get this out of the door? Head over to part 3: Rallying the entire company to launch the new Typeform.