David Hoang, Director of Product Design at Webflow, talks to Maze about Webflow’s design process, why perfection is overrated, and why design is not ‘magic.’
The Optimal Path is a podcast about product decision-making from the team at Maze. Each episode brings in a product expert and looks at the stories, ideas, and frameworks they use to achieve better product decision-making—and how you can do the same.
Liked what you heard in this episode? Read David’s full article over on our blog, In The Loop.
You can follow David on Twitter (@davidhoang), and check out Webflow too (@webflow).
Follow Maze on social media:
To get notified when new episodes come out, subscribe at maze.co/podcast. See you next time!
Ash Oliver:
Welcome to The Optimal Path, a podcast about product decision-making brought to you by Maze. I'm your host, Ash Oliver, UX designer and design advocate.
Ash Oliver:
Great products are the result of great decisions, decisions that deliver value for customers and the organization. In this podcast, you'll hear from designers, product managers, and researchers about the ideas informing decision-making across all aspects of product development.
Ash Oliver:
Today I'm joined by David Hoang. David is a design leader with a passion for creative, product and technology. He leads the product design team at Webflow as the director of product design and contributes greatly to the wider design community through writing, speaking, and advising. David, thanks so much for being here.
David Hoang:
Hey, thanks so much for having me. I really appreciate being on.
Ash Oliver:
I want to start by looking at one of your personal principles on design, and you've said that design is not magic; it's a method, a rigorous process of exploration, iteration, and validation until you reach your outcome, a process that makes the end user feel like it's magic. So I'd love to have you start by telling us more about how you founded this principle and how you actually structure this design process from this point of view.
David Hoang:
Yeah, it's been my entire career developing this principle and it probably started back when I was in art school. So before I became a designer, I studied drawing and painting. And I think artists, designers can often feel like being perfectionist and making sure that everything has to be perfect. And then, you have this really elegant outcome that you get in the end. And I always felt, at least for me, that was a little misleading because even in art school or in design, everything takes a lot of iterations and it takes a lot of screwing things up, and it kind of built this culture.... Or I've seen this culture established for designers not wanting to show stuff early or not even wanting to show stuff at all. And I think that is the beauty of design itself, is the iteration feedback that you get.
David Hoang:
So I remember I really had a visceral reaction to when people used the term "magic". So I remember talking to a colleague and I said verbatim what you just read off. I was just like, "Hey, design is not magic. It's something that requires a lot of work." For me personally and I try to instill this with people I work with, that's don't be a perfectionist. Get things out, refine it, and then make it something that you felt you would've been proud of. But along the way, you're iterating. So, that's the origin of that principle.
Ash Oliver:
And knowing that designers that you've worked with, or even in yourself have suffered from that kind of perfectionism, how do you try to live out this principle and stifle any of that perfectionism that might come through?
David Hoang:
Yeah, it's hard, right? It's hard because I think designers take a lot of pride in a high quality outcome, whether it's form, in the visual aesthetics, but also function as well too. We want things to be a positive and delightful experience for our customers.
David Hoang:
I think a lot of times, especially for product designers, we fall in this world of how people might feel about agile development. Things are going to get shipped so you want to get it right the first time, but you really have to instill this culture, not only in design, but together with the teams you work with, that's we're going to keep improving on this and just really have lean iterations. So the way I try to counterbalance that is to show my low-fidelity work as much as possible to get feedback, even as a leader, even like, "Hey, this is the first pass at what you think design's going to work on for H2," the second half of the year and show that early. So it's not just people doing the work as individual contributors, but also for managers too, because you want to give people the opportunity to give input when you can incorporate it substantially, because if it's too much later in the process, there's only so much you can tweak based on feedback.
David Hoang:
The way I mitigate this is just show everything as early as possible and just frame it, that's like, "Hey, this is early thinking. What do you think?" Low-fidelity work often merits results in high-fidelity feedback.
Ash Oliver:
That's excellent. Yeah, and thinking about this low-fidelity thinking that you're sharing, I'm interested in what does that look like? Is it always just low-fidelity wire frames or are there other kind of activities or outputs that encapsulate that?
David Hoang:
It's funny, just us being remote and digital all the time, I still do a lot of any wire framing or any sort of concepting on paper. And sometimes it's so low-fidelity that I just hold it up in the camera, just like, "What if we did something like this?" Because you want reactions. You want reactions and thoughts in that way. So, that's a lot of how it shows up. And then I think because of so much remote work is written and asynchronous, I think that shows up in the form of really bullet point one-pagers. I try not to get too extensive on overwriting, but be able to cover like, "Hey, these are the high level things I want to cover for planning for next quarter. What does everyone think?"
Ash Oliver:
It brings me to something that you said. You've said that you've taken the concept of learning how to learn from art school. So how have you instilled this practice on the teams that you've led and grown over the years?
David Hoang:
I get asked a lot by designers, "What's the one skill a product designer needs to have?" And I think it really is being autodidactic, being able to have that curiosity, and explore, and learn either independently or as a group, because I feel like design is one of those fields we're always going to have job stability, because everything has to be designed. However, the things around us is probably going to change or the surface areas we work on. So being able to learn things pretty quickly and independently is really crucial, I think, because new technologies might change how we think about interaction design. So with AI nowadays, it's just a different thing that designers need to learn about, not only how it's applied, but also the implications of it. And I think that's the key thing, just learning implications of what new technologies can do for better or for worse with customers and human beings too.
David Hoang:
So yeah, I've always adopted that learn to learn. I'm an avid learner. I was one of those people I felt like I could have stayed in school forever and just kept learning. That's something I try to encourage people on the team. So we try to do a lot of different... Like co-learning sessions or bring guest speakers in to talk about things such as accessibility and other things. So, the other thing I often say a lot too is I always use the analogy, when you're doing a design project, if you're a musician, you don't practice your chords during the concert. You have your own time to do that, deliver and practice. And being able to make that time to be like, "Okay, I'm going to experiment, try new things and have that space to fail and fail thoughtfully," is so important in the learning process. So that's why I am a big fan of blocking out time for that deliberate practice and learning.
Ash Oliver:
Absolutely. Well, I mean that leads beautifully into one of the things that I wanted to ask, because we know it's a really unfortunate commonality in the product industry is that most of the time you get that first feedback once you've shipped. So in this analogy, you'd get that feedback at the concert and it really should be much earlier on in the process. So thinking about either your time across all of those teams or more specifically at Webflow now, how have you constructed a process of that feedback and insight collection before shipping?
David Hoang:
Yeah, I think Webflow and One Medical had something pretty common in particular, and it's interesting to think that because it's drastically different companies and products. But I think one thing is the idea of customer behavior. So how someone's used to using a product. So at One Medical, the same way at Webflow, we have the power users, the tenure people who've used the product for a long time. And if you make any tiny little change, whether that flow was ideal or not, people are used to it and it disrupts a workflow, right? So you might, whether it's a clinician at One Medical who's been there for nine years or one of the original Webflow power users, they're like, "I know how to do these eight clicks to do this one thing right away. And it's not ideal, but I learned it over the years of doing it." Then all of a sudden this workflow changed.
David Hoang:
And then on the flip side, you have people who are new, people who've learned about Webflow and just getting started in their journey, or people just joining One Medical, they have different expectations and they have different mental models of how to use the product too. And they might find new ways to subvert it, or they may be starting where there were new features. This is why we do a lot of testing before we start building out some of the products or improving it, because we know there's such a variety in customer behavior that we always need to check for.
David Hoang:
So we always think about asking what would the power users think, what would the new person think, and how do they learn, and try to test rigorously. It's hard because, this is one of the things we love about Maze, so it gives us time to be able to get those insights without taking time away from the team, because it's hard for me to tell a designer or ask them like, "Hey, we should really be testing a lot of these things," when they have so many other things they need to work on as well too. So leveraging the system to get that learning and testing is the most important thing more than the number of time in hours that individuals are doing it.
Ash Oliver:
Your role at Webflow specifically covers brand design, growth design, product design and user research. So maybe in a more traditional model that testing and learning is kind of segregated to user research. When you're talking about whether it's Maze or other kind of products that you use, I'm assuming that testing and research happens across your entire team, not just user research or is it relegated specifically to that segment?
David Hoang:
Yeah, these days I'm more focused on product design and research, but I do know the brand design team, they do a lot of research too. So Camille, one of our brand designers, really does a lot of usability when one of her first projects was the redesign of our blog. So bringing people early in to get feedback.
David Hoang:
So, I think the way I envision user research is more of the generative research and help prioritize other things on the roadmap. But when it comes to evaluative research, yeah, everyone on the team is expected to participate in that and help drive that on the work they're doing. So user research provides great resources and toolkits for us to enable the product designers to be like, "Okay," because there's various levels of experience in what people have in user research. So we want just to equalize that as much as possible for everyone. So it's like, "Okay, here's some toolkits on how to moderate a session or if you don't, here's the different tools that we can offer for you to get some research insight and also know which methods to pick." So, that's the role of user research, is being that center of excellence for us.
Ash Oliver:
And as far as the types of things when you're thinking about testing in either a generative or evaluative state, what would be some of the things that you've seen the team either test and be surprised by, or just start to test and maybe not formally have tested before?
David Hoang:
Yeah, I think there's some new paradigms we're exploring, and being able to prototype and test the results we've gotten back have been pretty shocking. So it's very shocking in a positive way as well, and there are things that we're really trying to figure out how to add simplicity to some of the areas that's complex, because Webflow can be complex for people who don't have a web designer, or a front-end web development background in some places. So we're asking ourselves, how do we make it easier to use without reducing that power for people who need it as well?
David Hoang:
So we've done some usability sessions with power users where they're like, "This is great," and we were so scared because we're like, "How are the power users going to feel like? Are they going to have enough customization here?" Sometimes you need to challenge yourselves too through research. And I think we feel like we know these customer behaviors pretty well and had that concern. And then as we were continuing to do more research, we really learned that this isn't a concern. Maybe it was at some point, who knows, but it was just something we had to challenge our own assumptions as well.
David Hoang:
I feel a little bit spoiled at Webflow because I feel generative research is so easy, because a lot of our customers are designers too. So they have a lot of amazing ideas. I always say, "Our customers are the greatest innovators." So a lot of my role and I think as well in the product design team is curating and synthesizing all that. But when we do these sessions, we ask some ideas they have and they have full-on sketches of things that could improve the product. So when you're working on a design tool for designers, it gets a little meta, right?
Ash Oliver:
Yeah, absolutely. The challenging assumptions thing, I'm wondering what other kinds of assumptions might be challenged, or if you have a story about a challenged assumption that took place that prototyping or testing answered?
David Hoang:
Yeah. I guess I'd say even stuff outside of our designer experience, like how people might perceive our brand or some of the more administrative workflows, there are things where we feel this is really confusing and hard to do. And we might learn in testing that, okay, it may not be the easiest to do or the most intuitive, but it doesn't cause a lot of customer pain. People are like, "I can live with this." It's more of a nuance, right? And then there are things that we figured were a little bit easier, a little bit more intuitive that did cause a lot of customer pain. So I think we have a lot of examples of that just because something, I think, is not 100% intuitive or in 100% doesn't mean it's painful for customers. And I think that's why it's so important to do research and talk to customers too, to be like, "Okay, how painful is this?"
David Hoang:
And now's it's the same with One Medical too where they're like, "This is annoying, but I can live with it." But then there are other things that are like, if you are doing a site for a client and there's a lot of business implications there, those are high stakes and it can induce a lot of pain. So things like that we find a lot in research, is just identifying what level of pain and how soon does it need to be addressed; that's the key, 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 all these things. So I think that's the big learning, is some of these things we know might be janky or annoying, but some are less painful than others.
Ash Oliver:
Yeah, and does that start to inform the product roadmap and the prioritization in testing some of these things and deciphering what really is the biggest pain? How do you balance all this? Because I've heard you have the power users and their needs, some of the newer users and theirs, and then ultimately the business is their proxy. So how do you balance that when you're looking at steering the direction of the product roadmap?
David Hoang:
Yeah, I think what we kind of instill on the design team and also product in general is how do we look at systems of things that we can improve as opposed to things one off, right? Because there could be this thing one-off that is painful or annoying, but it's an isolation, or the stem of it could be something more systemic. And I think what we're working towards is trying to make sure we learn as much as possible, those end-to-end user flows to identify, okay, what if we improved this entire system? Or what if we made these improvements together in order to fix the problem, versus looking at with just one thing. I think with Webflow, everything's so interconnected. So if people are familiar with the game Whac-A-Mole, you knock the thing down and then it shows up somewhere else.
David Hoang:
So just really getting to the root cause of what the problem actually is. And sometimes when we do... Evaluate the research, we get a sense of it and we ask ourselves, what are the other areas that might be impacting this? What's the root cause of this problem itself so then we can try to fix these things together? And sometimes there's one isolated thing. However, I think the majority of the time is really identifying those things together, and that's how we want it to show up on the roadmap is let's fix, or let's improve or add these collection of things that makes sense for what the customer is trying to do, versus trying to optimize for one specific area. So a lot of the work we're doing nowadays, it may be... Some are things we can address today, others are more let's really make sure it shows up on the roadmap as we plan for subsequent quarters and years.
Ash Oliver:
Yeah, well you have a Now, Next, Future kind of model for your product roadmap. Can you explain that a little bit more?
David Hoang:
Yeah. I think one of the challenges for designers is we work in so many different time dimensions.
Ash Oliver:
Literally and metaphysically.
David Hoang:
Yeah, totally. And it's hard when you're showing your design work, so aligning with people on, "This is something we're thinking many iterations from now," because you might have a product manager or an engineer who's thinking about the next sprint and they're like, "Oh my goodness, we can't do this. This is so much work." And it's not a criticism of them because they're being very pragmatic and realistic, "This isn't viable and this doesn't connect to what we have in our ecosystem of our product." And then, you might show stakeholders something and they're like, "Hey, we want something more vision oriented," and think about that.
David Hoang:
So, I think just something... I learned this at One Medical, we really applied to this kind of Kaizen framework. That's the Japanese word for, "to change for better," and our meetings were pretty simple because it was just like, okay, what's the problem that we're trying to solve? What's the current state? What's the future state? And then, what are the things in between? And it's just so simple. So, I use Now, Next, Future in that sort of framework, where it's just, okay, is now what we're trying to get done in this sprint or this quarter... People are working on it right now. Next is that next horizon, then future is that end state where we even want to be. Because I think you need to know that North Star state, as a lot of people say, so you can fill in where to navigate. And you're iterating along the entire time.
David Hoang:
It's not like this monolithic roadmap that we need to build all these things and then we're going to get to that future state. It's more of like, these are the ideal outcomes we want or the results we want, and then through each now iteration, you're adjusting the next and the future based on that.
Ash Oliver:
Right. But assuming if you've done a fairly good job of that, while it might take some winds and turns, ultimately that future state is somewhat... And you can see how that is built upon in the now to getting there, even if it does ultimately change.
David Hoang:
And Wes, who's one of my managers at One Medical, he was our VP of product and he often said this, is how do we take the future state and start working on some of these things now? I don't want it to just stay in the future, in this dream that we never do. We could get a slither of some of these things, some of these automations we want to do, or some of these other things that we keep saying, "Oh, it's in the future." That's the value doing future state mapping too, is you can start thinking about what things do we need to start incorporating now to get there as well. So I thought that was really profound. I think I've learned a lot about product from him and that was one of the things that really stood out, is okay, we've identified this future state, so what are those things we need to incorporate now?
Ash Oliver:
Yeah. I want to talk about prototyping because you have a very long history of even leading a prototyping team at Black Pixel, which is I've not come across a team that specifically specializes in prototyping. So, do you see working in the now and the future and prototyping being a vehicle to showcase that? How do you see prototyping fitting into the now and the future?
David Hoang:
Yeah, I think prototyping, whether it's a team or a capability, is that connective tissue between all those three time dimensions. And I think the thing that's really powerful about prototyping is you can prototype on look and feel, function and customer behaviors. There's many different sides of what you can prototype along the way. There's this paper I still refer to every day. I think it was written in the '90s by two Apple engineers. It's called What the Prototypes Prototype.
Ash Oliver:
Oh, I've not come across that.
David Hoang:
Oh yeah, I highly recommend reading it. It's a pretty short one, but it's just talking about the purpose and use cases of that. I don't think every company or team needs a prototyping team per se, but I think you need it as a capability, whether it's spread across all of your teams or all of your individuals are really good at it. The way I view prototyping is it helps you be that connective tissue between now, next and future, because there's so many different ways you can prototype, right? You can spin a branch off of production, what you have now, try to hack a new workflow. We did that at One Medical a lot, not on production, but we did... We staged the site and we said, okay, this is the current clinical workflow. What are new ways we can test and have people run through those real simulations?
David Hoang:
Because sometimes you show them a paper prototype in that regard and they're like, "Yeah, that looks great." Yeah, but you don't get to try it out in practice. So there's so many different ways, layers that you can apply prototyping. And if you can validate it, if you can get through and get a signal that's like, "Wait, we could maybe build some of this scaffolding to help take us to that next iteration," versus it trying to be a really expensive thing. I love working with engineering and I always say, "Try to come up with the cheapest solution possible first," because if you get a prototype and then you spend all this time trying to build and engineer something, that's a high cost too.
Ash Oliver:
Absolutely. And you've said that prototyping cycle is the shortest iteration, that I think it goes back to everything that we've been talking about, like prototyping inherently so that you're not stuck in this perfectionist's state of mind. But in more of that low-fidelity thinking that can be expressed, especially given that you were so focused on that across many of your roles, do you see prototyping branching off from things that maybe most people wouldn't think of prototyping? Is there anything unique that you've prototyped before that isn't your traditional kind of design mock-up, so to speak?
David Hoang:
Yeah, that's a good question. I think for me, quite frankly, I feel for any product development team, you want to reduce that iteration cycle, right? One of my really good friends that I worked with at Black Pixel, I learned this from him. He said, the number one way you can increase productivity is reducing the iteration cycle. And I think that's so true because you get more attempts at it. That's really all it is. There's more iterations, there's more attempts and you get to learn each and every way. And I think the same way you want different user research methods, you want different prototyping methods because sometimes you may not need a high-fidelity prototype for certain things. You may not need to build something in code because you can create something in a Figma prototype and put it in Maze to get feedback.
David Hoang:
But then there's some things where, let's say at Webflow, a lot of the experience when you're designing a website, it's not a linear journey. It's a whole matrix of different things you can do. So it's hard to learn that through static screens. So you have to actually build something functional. So for us, I'm kind of bullish on try to subvert any tool you can to use it as a prototype tool. So we have a designer who prototypes in Webflow quite a bit. So it's using Webflow and then extending it with the JavaScript he knows to be able to do that. So yeah, a lot of it shows up in many different ways. And I think that's important, is to know what your prototyping toolkit is and when should you use which one?
Ash Oliver:
Yeah, absolutely. It's that more shots on net sports analogy.
David Hoang:
Totally, yeah.
Ash Oliver:
Yeah, I'm interested to know a little bit more about maybe a framework or a system that you've implemented at Webflow specifically, perhaps, that really drives customer-centricity, because what we're talking about here is ultimately so that we can provide a better user experience and achieve something that's successful in the hands of our users. So prototyping seems very much like a conduit in order to build that customer-centricity. Can you talk about the connection there?
David Hoang:
Yeah, I try to keep things pretty simple. So, we run in one week sprints for the prototyping work that we've been doing for this particular case. We tried to fail as fast as possible. So when we first kicked off this work and started initiating it, we probably had a handful of different directions that we were thinking and going, and then we've let it... Hey, let them go off to the races to see what you uncover. So you want to get feedback from both customers and stakeholders pretty early on to get that insight and then be able to eliminate what we know doesn't work. Or at least, and when I say it doesn't work, it's for now, right? So it's not like this will never work, but given what we're trying to achieve, this is unlikely. Really uncover why and from that, I think we really want to take the learnings and you almost treat your prototyping projects as a portfolio of different opportunities.
David Hoang:
If we have portfolio A through F, it's not like we have to pick one of those, right. It's just as they go in parallel, are there behaviors or mental models that work from concept B and D? Do we devise something new from that? So I think the customer interest here, I think shows up there. We often try to get feedback both on how it works in the product today and also how we're trying to achieve it in the prototype. So making sure there's a feedback loop there.
David Hoang:
The other thing we do across teams, now with our user research team, we do what's called rolling research, which I think is a pretty common practice, where it's 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. There's two reasons I think in every product team lies certain individuals or teams might not do research. The first is probably they don't have the time. And then the second is they probably aren't comfortable doing it on their own yet. That's okay. 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 having that responsibility like, "Go moderate this, right?" And they're like, "Oh my goodness, this is super scary."
David Hoang:
I think those are the two problems that show up and I think rolling research is a great way to do that, where it's like, "Hey, you can come and simply show up to this and see other people do it. And as you get more comfortable, you can take the reins and drive the moderated session," and then they can take it back to their team. So, I think it's really just some of those things. How do you incorporate customer-centricity in the iteration cycle in everything you do? Can we do this on a weekly basis, can we do this on a daily basis, and just challenge ourselves to see how much can we put customer voice in what we're doing every day?
Ash Oliver:
Absolutely. Yeah, one of the last questions I want to ask you is in regards to that. As far as being able to incorporate users or source users, do you have any tips for people? I'm thinking about teams that maybe don't have a user group that's opinionated and vocal and communicative about their use of Webflow, for teams that maybe have users that are a little bit harder to reach, how would you advise going around getting that customer-centric mindset established?
David Hoang:
The one thing I try to do, and this is going to show up different for various companies, because you might work in a highly regulated place where you don't have access to users. So, is this going to vary? I think if you frame it in the way that you're doing this research to improve the product and the experience, people are going to be very generous with their time in that way. So I think when we talk about trust and the trust that people have in data and research, just being clear with what the intention is. So when I advise with the few startups and they're in their early days, and they don't have their tool suite set up, and they're like, "What can we do?" And then said, "Well, what if you just added a link to an Airtable forum or something that people can sign up, or a type of forum to sign up and opt into the research, and just have it in the dashboard or some other place where... And make that call to action to be like, "Your feedback is going to help us improve the product."
David Hoang:
If they're a paying customer, they're going to want to see that get better. So, I think that's the one thing I would encourage people is that build those channels for people to be able to opt in, to give that feedback, because sometimes when you do outreach, it can be a hit or miss. And I know, sometimes people are... They're looking for a gift card to participate, and it's not to say you shouldn't do that. It's just to know what sort of things you need. So those are a couple different ways; focusing on the outbound, ways you can optimize that. So it's effective to have the audience reach out and then giving people ways to be able to opt in while they're using the product that isn't disruptive.
David Hoang:
And I think the last thing I want to maybe share on this is to think so much of product development now is community-based too. So some of the best companies... I think Webflow has such an amazing community and it's so easy for us to get people to get feedback. So tap into the community to be able to get feedback and do some of these sessions. I think when we're ready to start testing some of these things at a larger scale, we're thinking about let's give it to the community early. Let them alpha and beta test some of these things, instead of waiting because they've thought about the product for so long as well too. So I think that's probably the newest thing I see now that I'm so excited about, it's community-based product input as well too. And there's so much good insights you can get from customers in the community.
Ash Oliver:
You're absolutely right. The whole vision of Maze is to be able to build experiences that are informed by the actual people that are part of the experience. And I think a lot of teams try to get at that and the closer you can come to that community, the more knowledge you can garner from that. But one follow on question to that: Once you've done all that and you have all of this extrapolation of information and insights, how do you synthesize that information, especially across various channels and teams? How have you seen that done really well?
David Hoang:
Yeah, there's so much opportunity for research tools in the next decade. I think the 2020s is going to be when we had this data-driven era and I often ask myself, "Who's going to be the Tableau of customer insights?" Right? Customer intelligence. So all to be said, I don't think there's a great way to do it yet. And I'm hoping people figure out. I think some of the things that are effective, it's more how you operate and how you communicate. I've seen people do share outs really well, where we use Loom a lot at Webflow, and people record a Loom to synthesize all of the findings from the session and maybe offer live sessions and documents as well. We also use Dovetail, which we really like to build that research repository. But it's funny; I feel like if you talk to any researcher and you ask what's that source of truth there? And everyone's like, "It's homegrown, it's custom made." And a lot of it I think is because of how does the organization work and how does the organization distill and share information?
David Hoang:
So many times you do research and then you find out someone's already done research on it already. How do you surface all that information? So actually I feel the most underrated type of research is desk research, where you're just at your computer reading other people's research and figuring that out. So the more you can surface that, I think it's going to be helpful because you and another team might be doing research on things that could be informed by one another. So how do you connect those dots?
Ash Oliver:
Yeah, totally. I want to finish up by asking you my final five questions. You can answer this in as much detail as you want. They're a little bit more personal and distill things from your experience and ultimately just your time on Earth. The first thing I want to ask is what's one thing that you've done in your career or job that has helped you succeed that you think very few people do.
David Hoang:
I'd say the thing that comes to mind with this question is spending the time to know how other teams will work. And what I mean by that is one of the reasons I was interested about Webflow with brand design being part of the team is there was one point in my career where I did a year... I worked at HTC in global marketing and brand, and I got to see how those teams worked. And then when I was at One Medical, I got to work a lot with people in operations. So I really understood how offices are structured, and how do centralized companies work with the local markets? So I think that's one thing, especially as a designer, really understand how each team works, because then you know how to navigate those conversations and help them solve their problems as well.
Ash Oliver:
What's a system or process or habit that you've created for yourself to help accelerate your work, your career, your personal goals, or all three?
David Hoang:
From a career perspective, it's similar to that Now, Next, Future as well. I asked this a lot in my coaching sessions with people. It's just like, where do you want to be in your career as far as you can see right now? And I don't mean what role do you want at what company, but really what are you doing, and how do you start doing that today? And I think that was how I got into angel investing and advising. I thought it was a much further thing. And then I was like, "Okay, how do I do a small slither right now, because there's a lot of other things I want to be focused on right now and still do it for a very long time?" But again, just start pulling things, start in that North Star so you can start learning now. So Now, Next, Future Framework I think works for individual humans in how they think about their career as well.
Ash Oliver:
What is the industry-related book that you've either given by gift or recommended the most and why?
David Hoang:
Humane Interface by Jef Raskin. It's a pretty rare book to find, so I don't know if it's out of print. But I think Jef being a person who worked on the Mac and probably was one of the influences that defined why Apple calls it a Human Interface, is really thinking about that user-centric mentality. I'm going to cheat and add one more. Another one I like is more around decision making is this book called Thinking in Bets by Annie Duke. And she is a former professional poker player where it's really about how do you make informed decisions when you don't have all the facts? And I feel like that is the epitome of a manager, is just how do you make the best call based on what you know and be able to move things along? So those are top two I gift and recommend to people.
Ash Oliver:
What is an unusual habit or an absurd thing that you absolutely love?
David Hoang:
I don't think it's just me, but I love watching movies that are so bad, they're good. I mean everyone's going to say The Room, right? But I think there's one called Miami Connection. The reason I like it is I get so tired from work every Friday, given everything that's going on right now. I just want to unwind, kind of put my brain on pause-
Ash Oliver:
Turn the brain off.
David Hoang:
Yeah. And then I just realized too that it's just hard to make stuff. It's hard to ship bad products, let alone really great ones. And it's probably the same with movies. So, I've always just enjoyed that, plus reading the behind the making of those movies just to see what happened, or what kind of disaster was it? And then yeah, something like The Room is just how did this become an unexpected success in that regard? I do this every Friday night, so that's how I unwind.
Ash Oliver:
Well, David, I have one last final question for you and that is what are you known for?
David Hoang:
Oh man. I'd say curiosity, because I love to learn. I love to see what people are doing. I think everything that I do in my life professionally and personally just stems from being curious, like why does something work this way? Or how did this become a certain thing? And again, even as a design director, I'm not touching the work at all on a day to day basis; thank goodness for my team. But I still like to tinker. I still like to make sure that I'm playing around with new things just to keep relevant. So I would say if I was known for something, I think it's just being a generally curious person.
Ash Oliver:
Absolutely. Thank you so very much for being with us here today.
David Hoang:
Yeah, thank you so much for having me. It's such a joy.
Ash Oliver:
The Optimal Path is hosted by myself, Ash Oliver, and brought to you by Maze, a rapid user testing platform designed for product teams. If you enjoyed this episode, you can find resources linked in the show notes. If you want to hear more, you can subscribe to The Optimal Path by visiting maze.co/podcast. Thanks for listening and until next time.