On failing and learning: Inside Webflow's design process with David Hoang

When it comes to choosing career paths, David Hoang couldn’t have picked a better one to keep his passion for product, design, and continuous learning burning bright.

Before leading Product Design and Research at One Medical, a health tech company focused on changing primary care, David worked as Director of Mobile Design at Black Pixel with a lot of work specializing in prototyping.

Today, he’s Design Partner at On Deck and the current Director of Product Design at Webflow—a company helping designers and non-designers alike build professional, custom websites, all with no-code.

At the core of David’s professional journey, curiosity and learning have always been a driving force: “I just love to learn and see what people are doing. Everything that I do in life stems from being curious and asking questions, like: ‘How did this become a thing?’”

But how do you instil a culture of curiosity across product and design teams? And what benefits can early prototyping and testing bring to your own organization? We spoke with David to find out more about the power of testing early in the game, an inside look at Webflow’s design process, and why you should dedicate space to fail thoughtfully—and often.

“I think much like artists, designers can feel like perfectionists and will make sure that everything’s perfect,” says David. “They take a lot of pride in their work and want a really high-quality outcome.”

Taking pride in your work is great, but a laser focus on perfection can be detrimental to the process. So, how do you combat a perfectionist state of mind while still delivering a positive end result? To help answer this question, David shares an important personal principle that has guided him through his own career in design:

On that note, here’s a high-level look inside the Webflow’s design process, and the frameworks, ideas, and processes they employ to prioritize and manage work.

Webflow believes strongly in user feedback and prototyping products—early and consistently across the entire development process. “We do a lot of testing before we even start building products or improving them, because we know there's such a variety in customer behavior that we always need to check for. We always have to think: ‘What would the power users think?’ while also being aware of ‘How would the new person think?’ It's hard, but this is one of the things we love about Maze—it gives us time to be able to get those insights without taking time away from the team,” says David.

Speaking of new versus power users, David mentions this distinction is a key part of their prioritization methods.

When you work on a product as well-known as Webflow, you occupy a rather unique position. When it comes to feature prioritization and customer pain points to be solved, Webflow informs their product roadmap with feedback from two distinct customer groups. “We have the power users,” David explains, “these are the 10+ years people who've used our product for a very long time. If you make any tiny little change, whether the flow was ideal for them or not, people are still used to it and it disrupts their workflow.”

On the other side of the customer equation, David and his team need to consider new users and ensure their Webflow experience holds just as much power as that of the previous group. “We’re really trying to figure out how to add simplicity to Webflow. Because it can be complex for people who don't have a web designer or front-end web development background, so we're asking ourselves how do we make it easier to use, without reducing that power for people [with those backgrounds] who need it as well.”

“Sometimes, we need to challenge ourselves and our assumptions through research,” David notes. Even if you think you have a strong idea of the core problems your users are facing, you can still be surprised to learn through research what actually affects their day-to-day workflows.

When it comes to conducting research, David makes an important point about the ‘fear’ that can take hold of individuals.“Research is very high stakes because you want to be the voice of the customer in an accurate way and not be biased, so I understand why people are nervous about having that responsibility,” he notes. “When people say, ‘Go moderate this [interview],’ it can be super scary.” Without context or experience of how to successfully conduct user research, many individuals and teams find themselves a little lost in the process. But it doesn’t have to be that way.

Whether you’re completely new to the game, or want to brush up some research skills, here are some areas you can focus on with your own teams:

Join rolling research activities

“Something we do across teams and with our user research team is ‘rolling research’,” says David. “It’s a pretty common practice where our Research Ops person will make sure there's always a customer available every other week or every month so someone has access to talk to them.”

Assigning somebody the role of seeking out customers takes some pressure off individuals who may find the process overwhelming at first. With frequent sessions and an open environment, rolling research is a perfect way to dip your toes into the research pool. “You can simply show up to see other people do it. Then as you get more comfortable, you can take the reins and drive your own moderated session,” David advises.

Review desk research

“Do you know what I feel the most underrated type of research is?” David asks. “Reading other people’s research,” is the answer he quickly follows up with. Recalling his university days, David remembers flicking through research papers written by others to gather a clearer view of the subject of study from all sides.

Yet, it’s very common to find that research is siloed in many businesses, with different teams and individuals building learnings entirely from scratch. Not only is this a waste of resources but it also prevents teams from finding patterns and connecting ideas about the same customer group.

Setting some time aside in your calendar to review existing research and see what other teams in your organization are finding… Well, it can’t do any harm, right?

“The key is not trying to fix everything. Not because we don't want to, but because there's only a certain amount of time to be able to do everything,” says David.

Some issues may not be the easiest to fix or the most intuitive, but if they don't cause a lot of customer pain, David recommends seeking out other issues that do. “If you're working with patients, that's high stakes. Or if you're doing a site for a client and there's a lot of business implications there, those are high stakes for customers,” he notes.

Prioritizing which features to work on across your next product cycle is a tricky decision for any team to make. With limited resources and time constraints, improving all areas of concern is an impossible feat. Instead, the Webflow team categorizes the issues that matter into three core stages: now, next, and future.

Referencing these stages, David reflects on his time spent at One Medical, where the team followed the Kaizen framework: “Kaizen is a Japanese word for continuous improvement. Our meetings were pretty simple, because we just focused on the problem we were trying to solve. Then we broke it down to three stages. What's the current state, what's the future state, and what are the things in-between?”

Similarly to One Medical, this framework is applied at Webflow to help shape the product roadmap into more manageable and realistic stages. “I think it’s important to know your North Star so you can fill in where to navigate, but it shouldn’t be a monolithic process,” advises David. “That's the value of future state mapping—you can start thinking about what you need to start incorporating now to get there later.” Just as products can (and should) be consistently iterated, so can plans for the ideal future state.

While it’s important to have a strong end goal in mind, the key is to thoughtfully adjust each stage based on the customer feedback you receive as you move through.

As previously mentioned, Webflow groups their ideas for new features and improvements and research into the now, next, and future stages. But how does that prioritization work? “One thing we instill on the design team is: ‘How do we look at the systems of things we can improve, as opposed to things that would be a one-off?’” David remarks.

Like many UX/UI design tools, Webflow is incredibly interconnected—meaning if there’s a problem in one area, other critical areas are likely to be impacted. “It’s a bit like that game ‘whack-a-mole’. You knock one thing down, and then it shows up again somewhere else,” David jokes. Rather than stretching valuable resources and wasting energy, the team at Webflow groups issues into ‘collections’ that can be researched more thoroughly for future developments on their product roadmap.

It’s unsurprising that as designers, we want to find the perfect solution and get things right the first time. We tend to focus on the end result we’re proud to attach our name to, rather than the messy beginning where we let our curiosity run wild. But this focus on perfectionism is detrimental to high-quality work. “It’s built this culture of designers not wanting to show stuff early on—or just not wanting to show stuff at all,” David admits. But as he points out, the end process is supposed to feel like magic to the customer, not to the creator. “Everything takes a lot of iterations and screwing things up at first,” he notes.

At Webflow, the Product Design team prefers to test fast and fail faster, dedicating space for deliberate practice and learning through early prototyping. David believes in sharing prototypes as early as possible—not only to gather honest feedback, but to promote a culture of experimentation and having space to fail thoughtfully. Whether it’s a low-fidelity wireframe or a rough sketch on a napkin, the true power of prototyping lies in those early stages to help shape the learning process. After all, there’s only so much you can tweak based on feedback if it comes much later on in the process. And if failing early still doesn’t sound like a great idea, David has a key analogy he likes to remind his team: