Season 4

|

Episode 8

How design works at Webflow

Kevin Wong

Head of Design @ Webflow

Feb 8, 2024

Feb 8, 2024

|

41 min

41 min

music by Dennis

About this Episode

Webflow has had as big an impact on design as any company over the last decade. So this episode is an inside look at their design culture, rituals, and key insights from their Head of Design, Kevin Wong. Here’s a preview of some of the ideas we cover:

  • How Webflow executed a massive rebrand leading up to their conference

  • The different types of prototypes for driving alignment

  • The role of design systems in their latest visual refresh

  • How designers can handle situations where stakeholders disagree

  • Ways to improve the way you share your work via Loom

  • The rituals and processes used by designers at Webflow

  • How design casts vision with “north stars”

Share on Twitter
Share on Twitter
Share on LinkedIn
Share on LinkedIn

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers 👇

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

Deep Dives

Get our weekly breakdowns

Free lessons from 👇

Lauren LoPrete

Lead designer @ Netflix

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers 👇

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

Transcript chapters

[00:00:00] Backstory leading up to WebflowConf

Kevin: I think that was one of the, the goals, going into wetflowconf and, and making sure when we were going to announce. , the rebrand and the, uh, new product UI. we wanted to make sure none of it leaked, even though we were engaging with members of the community to help give us feedback along the way.

but the backstory and, and just like kind of taking a step back, thinking about the context and, and want to lay sort of like the, the background here. you know, Webflow as a, as a product and a company has been around for over 10 years, or leading up to 10 years, this year. And the product has just been built, by so many great people and teams over the course of many, many years and many iterations.

but there hasn't been one big step back to look at how, you know, has the company evolved? Where are we going? and what kind of positioning we wanted to make in the market. and you know, when you look at even the specifics of the product experience and the features, you'll notice like some inconsistencies in ways that, you know, certain patterns, whether they were like the way menus were handled or navigation were not quite, systematized in any way.

that can also be, you know, a little bit frustrating or, questionable from the product experience. And we wanted to clean some of that up and, and really simplify, how people were using the product. and I think the other thing that, in many conversations over many years, it's more and more no-code tools that help people build their websites and, and build their presence online and help their mission-critical sites there are a lot of options out there. Webflow had such a great, Beginning, how do we continue to have a clear value proposition, and a clear way to help people make decisions about like, what's the right choice for me? and so it was about the right time for us to say, all right, what do we want people to understand about Webflow as a company and a product?

who do we want to make sure we're solving problems for? and then how do we make sure that whole story from the brand to the product experience, cohesively came together? and that's what really kickstarted this conversation about, well, how do we get there? and I think the first step was really to define this North Star.

with the support of our leadership team, both exec and also founders, we, had a small team. You know, we try to keep it pretty, pretty lean, to really dive deeply into. exploring that space. and this was really key to helping us understand what is it that we want? once we were able to identify that, then we can start to think about, well, how much of this can we start to build?

because it's, a process that will take quite a bit of time to, you know, roll out and, make sure that we're not only building something great, but we're also building with our customers and our community along the way, because they play such an instrumental role in making sure that, this kind of change would be successful.

[00:00:00] Backstory leading up to WebflowConf

Kevin: I think that was one of the, the goals, going into wetflowconf and, and making sure when we were going to announce. , the rebrand and the, uh, new product UI. we wanted to make sure none of it leaked, even though we were engaging with members of the community to help give us feedback along the way.

but the backstory and, and just like kind of taking a step back, thinking about the context and, and want to lay sort of like the, the background here. you know, Webflow as a, as a product and a company has been around for over 10 years, or leading up to 10 years, this year. And the product has just been built, by so many great people and teams over the course of many, many years and many iterations.

but there hasn't been one big step back to look at how, you know, has the company evolved? Where are we going? and what kind of positioning we wanted to make in the market. and you know, when you look at even the specifics of the product experience and the features, you'll notice like some inconsistencies in ways that, you know, certain patterns, whether they were like the way menus were handled or navigation were not quite, systematized in any way.

that can also be, you know, a little bit frustrating or, questionable from the product experience. And we wanted to clean some of that up and, and really simplify, how people were using the product. and I think the other thing that, in many conversations over many years, it's more and more no-code tools that help people build their websites and, and build their presence online and help their mission-critical sites there are a lot of options out there. Webflow had such a great, Beginning, how do we continue to have a clear value proposition, and a clear way to help people make decisions about like, what's the right choice for me? and so it was about the right time for us to say, all right, what do we want people to understand about Webflow as a company and a product?

who do we want to make sure we're solving problems for? and then how do we make sure that whole story from the brand to the product experience, cohesively came together? and that's what really kickstarted this conversation about, well, how do we get there? and I think the first step was really to define this North Star.

with the support of our leadership team, both exec and also founders, we, had a small team. You know, we try to keep it pretty, pretty lean, to really dive deeply into. exploring that space. and this was really key to helping us understand what is it that we want? once we were able to identify that, then we can start to think about, well, how much of this can we start to build?

because it's, a process that will take quite a bit of time to, you know, roll out and, make sure that we're not only building something great, but we're also building with our customers and our community along the way, because they play such an instrumental role in making sure that, this kind of change would be successful.

[00:02:33] How Webflow approached the user research process

Ridd: Can you talk a little bit more about how you involved the community in this process? Like you were making some pretty big changes Man, if there's anything that I know about like the Webflow user base is, there are a lot of very passionate power users who care deeply about the product and the way that it's set up and, and even just like the brand.

So what did that process look like?

Kevin: I think there's a couple different things that we did in order to bring, the community closer to the process. and I'll speak both in terms of the refresh itself as well as just like how we normally build products. in this case, we, definitely did some user research, early in the, process of, you know, updating the product UI.

And we wanted to really understand, were people understanding this, you know, what's the comprehension? were there. Questions about, the design decisions we were making. some of it related to, abstractions. meaning, how do we help people, who are familiar or unfamiliar with Webflow, understand like this dial or this button does this kind of transformation, to the CSS and ultimately to the style or the layout of their page.

we wanted to get that early feedback to make sure we were directionally heading in the right direction. we also had a small group of, trusted community members who had been with Webflow for and using Webflow for quite a long time. and we wanted to make sure that they were included in the process to help us get regular feedback as we were making these iterations.

you know, once you said a North Star, there's also like. Getting the details just right, from, the color choices that we're making, the type scale, spacing, like lots of, ergonomic related details, that we wanted to get, right? Because when you're using this product for eight hours or however long a day, it has to feel right.

and we don't want people to experience any kind of discomfort. You know, it should feel like you're in this creative flow and you shouldn't think about the product at all. and so they were involved. We, we would regularly share updates with them. They'd be in a Slack channel with us, and we'd constantly get their input and then iterate along the way.

We're really fortunate that we have such a wonderful, design systems team, on design and engineering, who really care about sweating the details too. So they will be involved with a lot of the conversations, really understanding more deeply, what was that feedback about? how do we think about this from a systems level, and start to, you know, make those iterations along the way.

I'm really fortunate to say A lot of the feedback, early on was really positive. I think a lot of folks saw the intention, behind what we were trying to do, and wanted to help us along the way. and I think the process itself, not just the end result, was also something really special to us.

because it, it means that, you know, we're all building this product together because we're all trying to serve, a shared purpose, which is to really make great visual development tools, for people who want to, to make a living and rely on our, our products to make a living.

[00:02:33] How Webflow approached the user research process

Ridd: Can you talk a little bit more about how you involved the community in this process? Like you were making some pretty big changes Man, if there's anything that I know about like the Webflow user base is, there are a lot of very passionate power users who care deeply about the product and the way that it's set up and, and even just like the brand.

So what did that process look like?

Kevin: I think there's a couple different things that we did in order to bring, the community closer to the process. and I'll speak both in terms of the refresh itself as well as just like how we normally build products. in this case, we, definitely did some user research, early in the, process of, you know, updating the product UI.

And we wanted to really understand, were people understanding this, you know, what's the comprehension? were there. Questions about, the design decisions we were making. some of it related to, abstractions. meaning, how do we help people, who are familiar or unfamiliar with Webflow, understand like this dial or this button does this kind of transformation, to the CSS and ultimately to the style or the layout of their page.

we wanted to get that early feedback to make sure we were directionally heading in the right direction. we also had a small group of, trusted community members who had been with Webflow for and using Webflow for quite a long time. and we wanted to make sure that they were included in the process to help us get regular feedback as we were making these iterations.

you know, once you said a North Star, there's also like. Getting the details just right, from, the color choices that we're making, the type scale, spacing, like lots of, ergonomic related details, that we wanted to get, right? Because when you're using this product for eight hours or however long a day, it has to feel right.

and we don't want people to experience any kind of discomfort. You know, it should feel like you're in this creative flow and you shouldn't think about the product at all. and so they were involved. We, we would regularly share updates with them. They'd be in a Slack channel with us, and we'd constantly get their input and then iterate along the way.

We're really fortunate that we have such a wonderful, design systems team, on design and engineering, who really care about sweating the details too. So they will be involved with a lot of the conversations, really understanding more deeply, what was that feedback about? how do we think about this from a systems level, and start to, you know, make those iterations along the way.

I'm really fortunate to say A lot of the feedback, early on was really positive. I think a lot of folks saw the intention, behind what we were trying to do, and wanted to help us along the way. and I think the process itself, not just the end result, was also something really special to us.

because it, it means that, you know, we're all building this product together because we're all trying to serve, a shared purpose, which is to really make great visual development tools, for people who want to, to make a living and rely on our, our products to make a living.

[00:05:10] How Webflow uses a "North Star"

Ridd: You said the phrase North Star twice now. Can you explain what you mean by that?

Kevin: Yeah. North Star. it's a, it's a great term. Basically, we, we wanted to have a design, something that looked and felt real, that allowed us to internally align on what it is that we wanted. when we think about like building products, there's like kind of two conversations you can have.

There's what you can do and there's what you want to do. and, and the North Star helps articulate what it is that we want to do. it's a end future state that is, uh, more idealistic. it, does try to, say, yes, we understand there are constraints, but for one second, if you could suspend disbelief, what is it that we are trying to achieve and strive for?

and it can be aspirational, it can be, it should be ambitious and it should be a little bit uncomfortable. and the whole point of it is to serve as a point of reference to anchor ourselves, you know, not just as a design team, but as a company, so that we know, where we're going and that we can always revisit this over time to help us guide and steer, many, you know, conversations and decisions that we try to make on a daily basis.

Ridd: What kind of artifacts go into that? Like is there, is it like a written document? Is it a series of statements, questions? Are there mock-ups brand guidelines? Like does that actually look like at Webflow?

Kevin: from a product, UI and, and product, design standpoint.

We had built, basically re we redesigned the entire designer and dashboard. so taking a lot of the key screens. And say here, how do we break down every single pattern from the navigation to the buttons, to the menus, and then rebuild a designer as it is today. and then, have basically like a working prototype of experience in Figma.

it was a labor of love, because there's just so much functionality in Webflow. Just imagine like all the states and all the different features and, combinations of how different panels would appear. So really trying to be selective about like what's representative of these key screens, so that we could really explore the boundaries of, how, how we're thinking about the design system.

we, had a series of, Figma design mocks that, really try to break down all of the key, product areas. So think about the designer and its canvas to the CMS data manager tool, interactions, panel asset manager, you name it. and then finding all of the key states that would say, okay, this is like a good screen to help us really stress the typography, the spacing, the colors, the iconography, and really just like flushing that out.

So that kind of represents like the key screens and some of the key workflows. then there's also an artifact of, the system. so how do we take some of the like, you know, complex or, you know, hard to communicate type icons, and explore a range of, different styles and treatments, that allowed us to not only, you know, strike the right balance of usability, but also.

Aesthetically was in line with, the direction that we were going, the work that helped inform, you know, sort of building out the product UI, and these, different like patterns that we were trying to, really standardize, was more of a, like philosophical exercise. and an exercise of principles and values.

and, and this is really where the team started first, was, really asking ourselves what is it that we wanted to communicate, as a company? what values did we hold and, and how do we even articulate those principles? you know, and, and the ones that emerged from many conversations internally that the team came up with, was this idea of, you know, going pro and, and really emphasizing the, the pro positioning that Webflow and its customers represented.

and we can definitely talk more about that. Others, uh, were around this idea of like cinematic, you know, we wanted the experience to really, carry some qualities of, like emphasis and how lighting and treatment would, both strike the brand, but also the product UI. also sort of a, a lean and a nod to like really compelling storytelling, which, you know, you can kind of see a lot of those examples in the way our education and our brand marketing, shows up.

and, and a couple other principles. And, and so what we try to do is, you know, taking these values and these principles. We, we also looked around and, wanted to see like how other pro tools were designing their products for. Their users. and, and we looked beyond just the adjacent competitors that, or other like sort of no-code options out there to Webflow.

we also wanted to see, you know, how industrial design or how, sound engineering and graphic design and 3D modeling, like how do these tools, you know, handle complex workflows and how do they provide a lot of the functionality while still balancing ease of use for the users that they're serving. so we took a lot of inspiration too from, looking at those product experiences and a lot of the folks too that were sitting on the team, exploring these concepts, also had experience on things like Cinema four D and Blender.

and, and so that also helped influence a lot of the thinking and, sort of the, the taste making that we were trying to bring, to the work. and so that I think was sort of a. cornerstone of how we would think about the design. And then through many rounds of, you know, reviews and iterations, really was an exercise of just calibrating, you know, are we more this, less that?

and then finding ourselves to, you know, where we are today.

[00:05:10] How Webflow uses a "North Star"

Ridd: You said the phrase North Star twice now. Can you explain what you mean by that?

Kevin: Yeah. North Star. it's a, it's a great term. Basically, we, we wanted to have a design, something that looked and felt real, that allowed us to internally align on what it is that we wanted. when we think about like building products, there's like kind of two conversations you can have.

There's what you can do and there's what you want to do. and, and the North Star helps articulate what it is that we want to do. it's a end future state that is, uh, more idealistic. it, does try to, say, yes, we understand there are constraints, but for one second, if you could suspend disbelief, what is it that we are trying to achieve and strive for?

and it can be aspirational, it can be, it should be ambitious and it should be a little bit uncomfortable. and the whole point of it is to serve as a point of reference to anchor ourselves, you know, not just as a design team, but as a company, so that we know, where we're going and that we can always revisit this over time to help us guide and steer, many, you know, conversations and decisions that we try to make on a daily basis.

Ridd: What kind of artifacts go into that? Like is there, is it like a written document? Is it a series of statements, questions? Are there mock-ups brand guidelines? Like does that actually look like at Webflow?

Kevin: from a product, UI and, and product, design standpoint.

We had built, basically re we redesigned the entire designer and dashboard. so taking a lot of the key screens. And say here, how do we break down every single pattern from the navigation to the buttons, to the menus, and then rebuild a designer as it is today. and then, have basically like a working prototype of experience in Figma.

it was a labor of love, because there's just so much functionality in Webflow. Just imagine like all the states and all the different features and, combinations of how different panels would appear. So really trying to be selective about like what's representative of these key screens, so that we could really explore the boundaries of, how, how we're thinking about the design system.

we, had a series of, Figma design mocks that, really try to break down all of the key, product areas. So think about the designer and its canvas to the CMS data manager tool, interactions, panel asset manager, you name it. and then finding all of the key states that would say, okay, this is like a good screen to help us really stress the typography, the spacing, the colors, the iconography, and really just like flushing that out.

So that kind of represents like the key screens and some of the key workflows. then there's also an artifact of, the system. so how do we take some of the like, you know, complex or, you know, hard to communicate type icons, and explore a range of, different styles and treatments, that allowed us to not only, you know, strike the right balance of usability, but also.

Aesthetically was in line with, the direction that we were going, the work that helped inform, you know, sort of building out the product UI, and these, different like patterns that we were trying to, really standardize, was more of a, like philosophical exercise. and an exercise of principles and values.

and, and this is really where the team started first, was, really asking ourselves what is it that we wanted to communicate, as a company? what values did we hold and, and how do we even articulate those principles? you know, and, and the ones that emerged from many conversations internally that the team came up with, was this idea of, you know, going pro and, and really emphasizing the, the pro positioning that Webflow and its customers represented.

and we can definitely talk more about that. Others, uh, were around this idea of like cinematic, you know, we wanted the experience to really, carry some qualities of, like emphasis and how lighting and treatment would, both strike the brand, but also the product UI. also sort of a, a lean and a nod to like really compelling storytelling, which, you know, you can kind of see a lot of those examples in the way our education and our brand marketing, shows up.

and, and a couple other principles. And, and so what we try to do is, you know, taking these values and these principles. We, we also looked around and, wanted to see like how other pro tools were designing their products for. Their users. and, and we looked beyond just the adjacent competitors that, or other like sort of no-code options out there to Webflow.

we also wanted to see, you know, how industrial design or how, sound engineering and graphic design and 3D modeling, like how do these tools, you know, handle complex workflows and how do they provide a lot of the functionality while still balancing ease of use for the users that they're serving. so we took a lot of inspiration too from, looking at those product experiences and a lot of the folks too that were sitting on the team, exploring these concepts, also had experience on things like Cinema four D and Blender.

and, and so that also helped influence a lot of the thinking and, sort of the, the taste making that we were trying to bring, to the work. and so that I think was sort of a. cornerstone of how we would think about the design. And then through many rounds of, you know, reviews and iterations, really was an exercise of just calibrating, you know, are we more this, less that?

and then finding ourselves to, you know, where we are today.

[00:10:15] How Webflow cast vision for what the product UI could become

Ridd: I wanna zoom in on the designer panel UI, really just as a way to go deeper on some of the things that you're saying, we've talked about this North Star and this series of. Mock-ups and visual explorations for what Webflow could become. I'm pretty interested in like how much of that was just vision casting versus actually laying , the real groundwork in Figma for what the panel did become.

So like what kind of gap existed there?

Kevin: I think that it would be more on the vision casting side, but not totally to the point where, there wasn't a, sort of a line of sight about, you know, what the implementation approach might be.

I think some people have an idea of, how we might get there. and you know, we definitely work with our engineering team to have those conversations. I say that it's vision casting because there does, there's a lot of work under the hood, than just like moving components and pixels around.

I think there are some questions about, how do we start to converge on, patterns like the way we do binding. right now binding, can be done to elements that are powered by our dynamic content through our CMS. You can also, you know, bind, things like swatches and, and color values. and we most recently with our variables launch can now bind variables to, you know, specific elements.

So how do we start to think about that UI, more as like one central concept. and then look at all examples of where quote unquote binding experiences happen, and then try to like, bring all of the ways that we would implement it into this singular pattern. and, and that takes time. and, and we would have to, you know, cost it and figure out like, you know, how do we, you know, implement it, uh, the right way.

But I think that becomes really more of the question. And, Also, some additional things we would wanna do is validate some of these experiences too. so, so there is two steps here. now that we have this like vision, that's, a point of view is continuing to validate some of these ideas around comprehension, usability, and interoperability, with the rest of, you know, features that may share similar patterns.

and then looking at the actual engineering work and saying, okay, how deep, of an implementation, effort is this, what are we not seeing? Um, you know, sometimes there are unknown unknowns. and so those are a little bit harder to predict. you know, that, that was the current state, of how we would, you know, think about the North Star and, and what it represented.

There was another artifact, which was taking the North Star work and saying, you know, we wanted to, you know, as a first step, take a lot of the existing functionality of Webflow and then update the, the components, and really treat it more of a stylistic, refresh. and so not changing too much of the core user experience and the patterns just yet, and really focusing on the treatment of, you know, things like type color spacing, buttons and, and things like that.

and, and trying to do some cleanup of our components along the way. we have a notes feature or notes, component, which, you know, is used to inform give notifications kind of in line with the UI. and, you know, that had been implemented in, many different ways. Uh, it may look the same or similar, but, they're all kind of like.

You know, bespoke created. and, and so we wanna just like clean that up and say, let's, let's just have one version, that has different variants, and then be done with it. and there's a few examples of like that which will ultimately help our own like developer productivity and our designer productivity.

so that we were spending less time thinking about special cases and really more about, you know, bigger like end-to-end user experience.

One of the other reasons why we focused on, our initial scope to update. The product UI was because we had product launches that were planned for WebflowConf and in order to land those changes, in addition to changes to the, brand and the, visual UI itself, we needed to make sure we were not introducing too much change at the same time.

Which can, you know, software will break a lot of the end user experience. You know, there, there's a lot of different dependencies and can add extra overhead, even building, you know, simple features. so we wanted to also manage, you know, how we were coordinating a lot of our team's work. and so.

part of, the change that we were also making, not just with, the design system work, but also, uh, introducing new powerful features at the same time, which in conjunction would be part of a broader narrative of, you know, pro capabilities that we were bringing to the market.

[00:10:15] How Webflow cast vision for what the product UI could become

Ridd: I wanna zoom in on the designer panel UI, really just as a way to go deeper on some of the things that you're saying, we've talked about this North Star and this series of. Mock-ups and visual explorations for what Webflow could become. I'm pretty interested in like how much of that was just vision casting versus actually laying , the real groundwork in Figma for what the panel did become.

So like what kind of gap existed there?

Kevin: I think that it would be more on the vision casting side, but not totally to the point where, there wasn't a, sort of a line of sight about, you know, what the implementation approach might be.

I think some people have an idea of, how we might get there. and you know, we definitely work with our engineering team to have those conversations. I say that it's vision casting because there does, there's a lot of work under the hood, than just like moving components and pixels around.

I think there are some questions about, how do we start to converge on, patterns like the way we do binding. right now binding, can be done to elements that are powered by our dynamic content through our CMS. You can also, you know, bind, things like swatches and, and color values. and we most recently with our variables launch can now bind variables to, you know, specific elements.

So how do we start to think about that UI, more as like one central concept. and then look at all examples of where quote unquote binding experiences happen, and then try to like, bring all of the ways that we would implement it into this singular pattern. and, and that takes time. and, and we would have to, you know, cost it and figure out like, you know, how do we, you know, implement it, uh, the right way.

But I think that becomes really more of the question. And, Also, some additional things we would wanna do is validate some of these experiences too. so, so there is two steps here. now that we have this like vision, that's, a point of view is continuing to validate some of these ideas around comprehension, usability, and interoperability, with the rest of, you know, features that may share similar patterns.

and then looking at the actual engineering work and saying, okay, how deep, of an implementation, effort is this, what are we not seeing? Um, you know, sometimes there are unknown unknowns. and so those are a little bit harder to predict. you know, that, that was the current state, of how we would, you know, think about the North Star and, and what it represented.

There was another artifact, which was taking the North Star work and saying, you know, we wanted to, you know, as a first step, take a lot of the existing functionality of Webflow and then update the, the components, and really treat it more of a stylistic, refresh. and so not changing too much of the core user experience and the patterns just yet, and really focusing on the treatment of, you know, things like type color spacing, buttons and, and things like that.

and, and trying to do some cleanup of our components along the way. we have a notes feature or notes, component, which, you know, is used to inform give notifications kind of in line with the UI. and, you know, that had been implemented in, many different ways. Uh, it may look the same or similar, but, they're all kind of like.

You know, bespoke created. and, and so we wanna just like clean that up and say, let's, let's just have one version, that has different variants, and then be done with it. and there's a few examples of like that which will ultimately help our own like developer productivity and our designer productivity.

so that we were spending less time thinking about special cases and really more about, you know, bigger like end-to-end user experience.

One of the other reasons why we focused on, our initial scope to update. The product UI was because we had product launches that were planned for WebflowConf and in order to land those changes, in addition to changes to the, brand and the, visual UI itself, we needed to make sure we were not introducing too much change at the same time.

Which can, you know, software will break a lot of the end user experience. You know, there, there's a lot of different dependencies and can add extra overhead, even building, you know, simple features. so we wanted to also manage, you know, how we were coordinating a lot of our team's work. and so.

part of, the change that we were also making, not just with, the design system work, but also, uh, introducing new powerful features at the same time, which in conjunction would be part of a broader narrative of, you know, pro capabilities that we were bringing to the market.

[00:14:20] Creating a "Pro" visual language

Ridd: How do you take these like overarching ideas around, we wanna be a pro tool and boil that down into practical visual design, either principles or tactics or like, you know, how do you, how do you bridge that gap ?

Kevin: We talked a little bit about like mood boards and looking at competitors to, really draw inspiration. I think that, you know, there was definitely an artifact which is like, here's a statement of these principles.

as a way to like help guide conversations and just align on some of the words and characteristics that we wanted to use in order to have conversations about, the designs and design interviews. I think the other aspect of it, is. Really an iterative process of let's take these principles and these attributes, let's apply them to the product UI, and then let's talk about how, you know, how it actually looks and how does it feel and where it is working and where is it not working.

when we think about the functionality and, and the user experience, because I think product UI, you know, that there's all this conversation on like threads and Twitter or whatnot about like visual then UX and whatever. I think for the reality is that our product is really a way to help people who may or may not have familiarity with web concepts like HTML and CSS.

Understand what they're controlling visually. On the canvas. so it's really important that we think about affordances and feedback systems, the controls that help people manipulate CSS in a way that helps them achieve what is really a fuzzy concept in their mind. and so it is really important for us to think about, we say abstractions, because it is like a translation layer between, you know, the machine and humans.

Uh, and, and our job is to say, here are, you know, conventional ways that we would approach it because they're commonly understood or they're familiar, or Here's something we're trying to do that's a little bit more novel, that still is understandable. and allows people to, you know. Reach and achieve their goals.

You know, something new and novel at the time was like interactions. introducing really a timeline-based way to, control dynamic interactions on your screen, whether you're scrolling or clicking on an element. then you have things like, updating, typography or a corner radii or shadows, like very well-established patterns.

We should, you know, use those, those norms. and that will also help people quickly understand, what it is that they're, they're controlling. but yes, it was a very iterative process I think once we started to. Feel internally we were on the right track, we would then start to, bring in, users, you know, our trusted circle of folks, to help us make sure that we, were checking our biases and we were also, understanding what was resonating or what was not.

and, and as that started to become more concrete, you know, they start to like graduate into the design system and we would say, this is the button, , these are headers, these are, the panels and the treatment. this is how we handle rows. and you know, you start to see overall as the system, how does this all cohesively make sense?

There's a lot of cross-checking, like, okay, well if we change the background color, the base background color. to a certain gray level. And then you're, we're working with Elevation to say there's menus that appear over it, you know, what's the, value of the menu that's supposed to be above the background, and then are there other, elevations above that?

And so then you have to do these stress tests. and, and so that I think is just part of the design process is, checking those cases and making sure that, you know, we're not just isolating our design decisions to just one screen, but also every other parts of the product that may be impacted by that decision.

[00:14:20] Creating a "Pro" visual language

Ridd: How do you take these like overarching ideas around, we wanna be a pro tool and boil that down into practical visual design, either principles or tactics or like, you know, how do you, how do you bridge that gap ?

Kevin: We talked a little bit about like mood boards and looking at competitors to, really draw inspiration. I think that, you know, there was definitely an artifact which is like, here's a statement of these principles.

as a way to like help guide conversations and just align on some of the words and characteristics that we wanted to use in order to have conversations about, the designs and design interviews. I think the other aspect of it, is. Really an iterative process of let's take these principles and these attributes, let's apply them to the product UI, and then let's talk about how, you know, how it actually looks and how does it feel and where it is working and where is it not working.

when we think about the functionality and, and the user experience, because I think product UI, you know, that there's all this conversation on like threads and Twitter or whatnot about like visual then UX and whatever. I think for the reality is that our product is really a way to help people who may or may not have familiarity with web concepts like HTML and CSS.

Understand what they're controlling visually. On the canvas. so it's really important that we think about affordances and feedback systems, the controls that help people manipulate CSS in a way that helps them achieve what is really a fuzzy concept in their mind. and so it is really important for us to think about, we say abstractions, because it is like a translation layer between, you know, the machine and humans.

Uh, and, and our job is to say, here are, you know, conventional ways that we would approach it because they're commonly understood or they're familiar, or Here's something we're trying to do that's a little bit more novel, that still is understandable. and allows people to, you know. Reach and achieve their goals.

You know, something new and novel at the time was like interactions. introducing really a timeline-based way to, control dynamic interactions on your screen, whether you're scrolling or clicking on an element. then you have things like, updating, typography or a corner radii or shadows, like very well-established patterns.

We should, you know, use those, those norms. and that will also help people quickly understand, what it is that they're, they're controlling. but yes, it was a very iterative process I think once we started to. Feel internally we were on the right track, we would then start to, bring in, users, you know, our trusted circle of folks, to help us make sure that we, were checking our biases and we were also, understanding what was resonating or what was not.

and, and as that started to become more concrete, you know, they start to like graduate into the design system and we would say, this is the button, , these are headers, these are, the panels and the treatment. this is how we handle rows. and you know, you start to see overall as the system, how does this all cohesively make sense?

There's a lot of cross-checking, like, okay, well if we change the background color, the base background color. to a certain gray level. And then you're, we're working with Elevation to say there's menus that appear over it, you know, what's the, value of the menu that's supposed to be above the background, and then are there other, elevations above that?

And so then you have to do these stress tests. and, and so that I think is just part of the design process is, checking those cases and making sure that, you know, we're not just isolating our design decisions to just one screen, but also every other parts of the product that may be impacted by that decision.

[00:17:43] Overview of how design works at Webflow

Ridd: There's a lot that I wanna go deeper on in terms of like the design process at Webflow. Maybe really quickly, first, can you give us a bit of context by , just painting the picture for how design is structured at Webflow, how the org operates, how different teams are assigned, especially when you have so many moving pieces all kind of marching ahead towards this big conference date.

Anything that you could do to make it a little bit more clear in terms of what the breakdown looks like behind the scenes at Webflow? That would be awesome.

Kevin: I'm happy to, and it's funny because I think, how we work, as a company and the conference, I think the conference is a very special time because I, it really does bring a lot of different pieces together simultaneously. but typically. design is very embedded with our engineering and product teams.

we, we internally, we say EPD, so engineering, product design, at all levels we try to have some, pairing or partnership, in order to have that, they say like three-legged stool or, you know, trio, different companies will have different ways of referencing it. and, and so that partnership is really key.

And, and every time we've done retros looking at how successful teams work, it's, it's always when we have, an EPD serve at the leadership level and also at the team level. so every designer is embedded with their team. we have, pillars that focus on different aspects of the entire user experience, of Webflow.

So one pillar may be focused on some of the core products, like designer and our CMS. data manager. We have another team that is focused on our ecosystem and our marketplace. Another pillar focused on, how teams collaborate, and work closer together or establish like their roles within the system administratively.

and so each pillar has, you know, an EP and d lead. and then within those pillars, there are multiple teams, that have their different areas of functionality that they're responsible for. when we think about our org design, we very much care about creating as much autonomy as possible. And the way we would do that is by having, as clear of, differentiation of what problems and which, users, each of these teams and pillars are trying to solve for.

More ownership, can move with more velocity, more decision-making power as as much as possible, of course. hopefully we, we try to minimize the amount of dependencies that may happen, between teams because, you know, when you have to talk to other teams, it, it can always take extra steps to make sure, you know, no collisions are happening.

I think some, some teams are naturally going to be more horizontal. So for example, a team that's focused on like growth will look at the entire sort of like journey of, you know, how one discovers Webflow, how they sign up, how they onboard, and, and how do they become more proficient and advance with their use of Webflow.

And that's gonna be kind of cross-cutting across many, many teams. And I think for them, they're, they're gonna have slightly different processes to help them, move quickly, to make sure that they're thinking end-to-end in that way. We have rituals internally, uh, which I think are, are hopefully fairly common for other teams. some of the rituals that we have are things like design, crits, ways for teams to share their work, to help problem solve together. We have our bi-weekly stand-up as a design team. And this is like my favorite meeting, of all because it's the one time that every designer, at Webflow gets together in the room.

Everyone presents a slide that shows like, what are they working on? and as a remote first company, you start to see regularly like what are all of the things that people are building and designing at the company. and it provides so much great visibility, not just like me as a part of the leadership team, but also to other designers and also product and engineering partners who are saying, Hey, we've been thinking about a similar problem, or we're working on a, a similar surface.

maybe we should talk now, so that we don't get surprised by each other's work, you know, later on. and then that, you know, can cause all kinds of. Swirl. and so that's been really powerful as a way to just, help the team and the company feel more like one team, despite, you know, time zone differences and geographical distances.

we have design reviews both, you know, within the design team, and with our, cross-functional team. and then, things that we're also iterating on, like how do we do release planning? So, how do we graduate, you know, ideas from an alpha stage to a beta to, to GA, but that's more or less of, of how we work. Every designer is going to be, involved end to end in the experience. So we, we tend to, work in a very generalist way. so designers are comfortable, supporting or even doing some of the research, whether it's like customer interviews or just observing ways users are using the product to prototyping ideas, doing some of the vision work, running some workshops to the detailed design work, and working with our design systems team to make sure that we have a good understanding of the components and whether they're working for the problem that we're trying to solve, or that we need to maybe take another step back and say we should rethink, uh, and reconsider.

This component, and try to break it so that it can work for not only new use cases, but also the pre previous use cases that it was intentionally designed for.

Ridd: I super appreciate that lens. It helps a lot. I wanna now drill into one piece of the process because after listening to you talk about everything that was going on at the company, it's like quite clear there are a lot of decisions being made pretty much constantly at many different levels to and so. I want to double click on that because like one of the most interesting things I think to hear about in terms of like how teams operate is like, how do they deal with these really meaty problem spaces and get aligned and make decisions?

[00:17:43] Overview of how design works at Webflow

Ridd: There's a lot that I wanna go deeper on in terms of like the design process at Webflow. Maybe really quickly, first, can you give us a bit of context by , just painting the picture for how design is structured at Webflow, how the org operates, how different teams are assigned, especially when you have so many moving pieces all kind of marching ahead towards this big conference date.

Anything that you could do to make it a little bit more clear in terms of what the breakdown looks like behind the scenes at Webflow? That would be awesome.

Kevin: I'm happy to, and it's funny because I think, how we work, as a company and the conference, I think the conference is a very special time because I, it really does bring a lot of different pieces together simultaneously. but typically. design is very embedded with our engineering and product teams.

we, we internally, we say EPD, so engineering, product design, at all levels we try to have some, pairing or partnership, in order to have that, they say like three-legged stool or, you know, trio, different companies will have different ways of referencing it. and, and so that partnership is really key.

And, and every time we've done retros looking at how successful teams work, it's, it's always when we have, an EPD serve at the leadership level and also at the team level. so every designer is embedded with their team. we have, pillars that focus on different aspects of the entire user experience, of Webflow.

So one pillar may be focused on some of the core products, like designer and our CMS. data manager. We have another team that is focused on our ecosystem and our marketplace. Another pillar focused on, how teams collaborate, and work closer together or establish like their roles within the system administratively.

and so each pillar has, you know, an EP and d lead. and then within those pillars, there are multiple teams, that have their different areas of functionality that they're responsible for. when we think about our org design, we very much care about creating as much autonomy as possible. And the way we would do that is by having, as clear of, differentiation of what problems and which, users, each of these teams and pillars are trying to solve for.

More ownership, can move with more velocity, more decision-making power as as much as possible, of course. hopefully we, we try to minimize the amount of dependencies that may happen, between teams because, you know, when you have to talk to other teams, it, it can always take extra steps to make sure, you know, no collisions are happening.

I think some, some teams are naturally going to be more horizontal. So for example, a team that's focused on like growth will look at the entire sort of like journey of, you know, how one discovers Webflow, how they sign up, how they onboard, and, and how do they become more proficient and advance with their use of Webflow.

And that's gonna be kind of cross-cutting across many, many teams. And I think for them, they're, they're gonna have slightly different processes to help them, move quickly, to make sure that they're thinking end-to-end in that way. We have rituals internally, uh, which I think are, are hopefully fairly common for other teams. some of the rituals that we have are things like design, crits, ways for teams to share their work, to help problem solve together. We have our bi-weekly stand-up as a design team. And this is like my favorite meeting, of all because it's the one time that every designer, at Webflow gets together in the room.

Everyone presents a slide that shows like, what are they working on? and as a remote first company, you start to see regularly like what are all of the things that people are building and designing at the company. and it provides so much great visibility, not just like me as a part of the leadership team, but also to other designers and also product and engineering partners who are saying, Hey, we've been thinking about a similar problem, or we're working on a, a similar surface.

maybe we should talk now, so that we don't get surprised by each other's work, you know, later on. and then that, you know, can cause all kinds of. Swirl. and so that's been really powerful as a way to just, help the team and the company feel more like one team, despite, you know, time zone differences and geographical distances.

we have design reviews both, you know, within the design team, and with our, cross-functional team. and then, things that we're also iterating on, like how do we do release planning? So, how do we graduate, you know, ideas from an alpha stage to a beta to, to GA, but that's more or less of, of how we work. Every designer is going to be, involved end to end in the experience. So we, we tend to, work in a very generalist way. so designers are comfortable, supporting or even doing some of the research, whether it's like customer interviews or just observing ways users are using the product to prototyping ideas, doing some of the vision work, running some workshops to the detailed design work, and working with our design systems team to make sure that we have a good understanding of the components and whether they're working for the problem that we're trying to solve, or that we need to maybe take another step back and say we should rethink, uh, and reconsider.

This component, and try to break it so that it can work for not only new use cases, but also the pre previous use cases that it was intentionally designed for.

Ridd: I super appreciate that lens. It helps a lot. I wanna now drill into one piece of the process because after listening to you talk about everything that was going on at the company, it's like quite clear there are a lot of decisions being made pretty much constantly at many different levels to and so. I want to double click on that because like one of the most interesting things I think to hear about in terms of like how teams operate is like, how do they deal with these really meaty problem spaces and get aligned and make decisions?

[00:23:08] How design drives alignment at Webflow

Ridd: And so can you talk a little bit about how design drives alignment internally at Webflow?

Kevin: yeah. I think one of the superpowers of being a designer is that we have a lot of different tools, that help facilitate decision making. and, and we do that through both the work that we can produce and, and create to drive those conversations.

and also through the facilitation, like setting the stage and the, and the, and the environment to even have those conversations in the first place. so let's, let's talk about like, how do you set the stage? you know, there are a couple projects, that we worked on, early around, you know, how do we think about design systems and thinking about, componentry and reusability.

We got together with, you know, engineers, founders, and, uh, some key stakeholders to. Really run a workshop. and this workshop was meant to answer a few questions. One is, how do we align on the problems that we are trying to solve? who is this for? And what ideas do you have in your mind that we should just put on the table now so that when we start as, as a design team to do more in-depth explorations, we're taking everyone's input into consideration.

And I think the part of the, like, misalignment is people may have ideas or, or may have, a sense of the problem that they're trying to solve for the customers, but they just don't know how to articulate that. So our job is to help provide that space and provide, know, the tools to, to bring that out.

so we, we ran these workshops, through a series of discussions, whiteboarding, sketching and, and.voting. and I think that process itself was, was really helpful, to again, like, get all of these ideas and thoughts out of people's brains into, something external that we can all work with.

And I think the process itself too, where you have all these different members of, the EPD org working together, in this workshop, Also a unifying moment to say, we're all in this together. We have the same information. we understand everyone's perspectives and you know, here here's our current state of thinking.

and, and from that point, we were able to then say, let's go explore some of these designs, build some prototypes, to articulate, you know, the problem and the, and the key experiences that we're trying to design. and then play that back out to everyone. Say, do we have alignment? Do we feel like this is the direction that we want to go in?

and, and if that's true, then you know, let's start to figure out like, where do we, where do we start? What's the first version of this? and, and start to pair that back so that we have now sort of a, a sequence of steps to get to, you know, again, sort of that North star, sounds very idealistic.

There's a lot of messiness in the middle. But that's more or less the, the process in which how design can help drive those conversations. and, and I kind of alluded to it, so what artifacts can we make and, and what can design create to drive a lot of that conversation? It is through a lot of prototyping, and

[00:23:08] How design drives alignment at Webflow

Ridd: And so can you talk a little bit about how design drives alignment internally at Webflow?

Kevin: yeah. I think one of the superpowers of being a designer is that we have a lot of different tools, that help facilitate decision making. and, and we do that through both the work that we can produce and, and create to drive those conversations.

and also through the facilitation, like setting the stage and the, and the, and the environment to even have those conversations in the first place. so let's, let's talk about like, how do you set the stage? you know, there are a couple projects, that we worked on, early around, you know, how do we think about design systems and thinking about, componentry and reusability.

We got together with, you know, engineers, founders, and, uh, some key stakeholders to. Really run a workshop. and this workshop was meant to answer a few questions. One is, how do we align on the problems that we are trying to solve? who is this for? And what ideas do you have in your mind that we should just put on the table now so that when we start as, as a design team to do more in-depth explorations, we're taking everyone's input into consideration.

And I think the part of the, like, misalignment is people may have ideas or, or may have, a sense of the problem that they're trying to solve for the customers, but they just don't know how to articulate that. So our job is to help provide that space and provide, know, the tools to, to bring that out.

so we, we ran these workshops, through a series of discussions, whiteboarding, sketching and, and.voting. and I think that process itself was, was really helpful, to again, like, get all of these ideas and thoughts out of people's brains into, something external that we can all work with.

And I think the process itself too, where you have all these different members of, the EPD org working together, in this workshop, Also a unifying moment to say, we're all in this together. We have the same information. we understand everyone's perspectives and you know, here here's our current state of thinking.

and, and from that point, we were able to then say, let's go explore some of these designs, build some prototypes, to articulate, you know, the problem and the, and the key experiences that we're trying to design. and then play that back out to everyone. Say, do we have alignment? Do we feel like this is the direction that we want to go in?

and, and if that's true, then you know, let's start to figure out like, where do we, where do we start? What's the first version of this? and, and start to pair that back so that we have now sort of a, a sequence of steps to get to, you know, again, sort of that North star, sounds very idealistic.

There's a lot of messiness in the middle. But that's more or less the, the process in which how design can help drive those conversations. and, and I kind of alluded to it, so what artifacts can we make and, and what can design create to drive a lot of that conversation? It is through a lot of prototyping, and

[00:25:51] Kevin's strategies for prototyping

Kevin: I think prototyping is a really powerful method, to help take a lot of ideas and assumptions and you know, truths and then say, how do we represent this and express this in a way that's very tangible to what the user is going to experience?

You know, one of the company behaviors that we have is obsess about the customer. And I think one way we do that is by trying to, you know, mimic a lot of what their situation is going to be. And I think that is through the use of making the experience as real as possible so that we can get. A, uh, an intellectual and a and a more tactile sense of the experience that we're trying to build.

prototypes are really powerful because it's something that's easily understood by everyone. You know, you see it, you can kind of like feel it. You can kind of tell like it's yes or no, like at least directionally hot or cold. And that's great for leadership. It's great for engineers, it's great for other designers.

And so one way we can help share these prototypes internally and, something that I think is really great from a, from a remote first company perspective is, you know, we use a lot of these asynchronous communication tools.

Like Loom has been really great for us. And so you'll see designers constantly building prototypes, walking through the experience, recorded over a loom, doing the voiceover, and then you'll see just a flood of feedback coming in. And it's been really great to help, you know, provide visibility as well as get people to think about, different questions about the technical implementation or the business case, or the pattern use, uh, all within the same thread.

and then that can help us. Have more follow-ups and say, you know, this sounds like something we should talk about synchronously in person because it's really complex and there's a lot of nuance, or we're actually quite more aligned, than we all anticipated. and we can actually move on. And, and teams are, you know, then empowered to start, you know, building and, developing the idea, sort of the next phase of work.

One other technique that we, we do internally is something called like a noodle session. we have a lot of like, food named, processes or rituals. and so this was something that came out of one of our, localization teams noodle sessions were basically like noodling over ideas and, and noodling, you know, your thoughts.

and really it was about getting, EP and D members together to. Really ask like what are these hard questions that we need to unpack about the technology, about, the design of the experience and if there are any tradeoffs that need to be made. And it was intentionally outlined as a time together synchronously to handle these like very ambiguous and complex questions.

and I think, you know, calling it Noodle is really great because it kind of helps depressurize, the situation and say, you know, we're, we don't know the answers, but we're here to work together to at least pick at it and, and see if we can get somewhere with it. and also I think it helped set the expectation that, it is a group effort where you do need, all functions present in the room to understand both the problem and the solution.

Uh, and what would be the best option, to go forward. and sometimes a lot of the output of the Noodle will be. A review, with other stakeholders to say, Hey, we, we noodled on this. There are, two or maybe three options. Uh, we consider here's our recommendation. does make sense with the group here?

Do we have alignment? what other considerations should we be making from maybe a go-to market standpoint or customer insight standpoint? And how do we just harden or strengthen this proposal? and, and I think that's been really effective, uh, at a team level, where I think there's a lot of now empowerment for them to drive the decision making from, their vantage point, while bringing the rest of the company along.

And I think design here, kind of bringing this back, brings to the table a lot of the thinking, whether it's diagramming and working through what the user flow would look like. helping map sort of the concepts and, and nomenclature through like, mind mapping kind of exercises or through prototypes.

[00:25:51] Kevin's strategies for prototyping

Kevin: I think prototyping is a really powerful method, to help take a lot of ideas and assumptions and you know, truths and then say, how do we represent this and express this in a way that's very tangible to what the user is going to experience?

You know, one of the company behaviors that we have is obsess about the customer. And I think one way we do that is by trying to, you know, mimic a lot of what their situation is going to be. And I think that is through the use of making the experience as real as possible so that we can get. A, uh, an intellectual and a and a more tactile sense of the experience that we're trying to build.

prototypes are really powerful because it's something that's easily understood by everyone. You know, you see it, you can kind of like feel it. You can kind of tell like it's yes or no, like at least directionally hot or cold. And that's great for leadership. It's great for engineers, it's great for other designers.

And so one way we can help share these prototypes internally and, something that I think is really great from a, from a remote first company perspective is, you know, we use a lot of these asynchronous communication tools.

Like Loom has been really great for us. And so you'll see designers constantly building prototypes, walking through the experience, recorded over a loom, doing the voiceover, and then you'll see just a flood of feedback coming in. And it's been really great to help, you know, provide visibility as well as get people to think about, different questions about the technical implementation or the business case, or the pattern use, uh, all within the same thread.

and then that can help us. Have more follow-ups and say, you know, this sounds like something we should talk about synchronously in person because it's really complex and there's a lot of nuance, or we're actually quite more aligned, than we all anticipated. and we can actually move on. And, and teams are, you know, then empowered to start, you know, building and, developing the idea, sort of the next phase of work.

One other technique that we, we do internally is something called like a noodle session. we have a lot of like, food named, processes or rituals. and so this was something that came out of one of our, localization teams noodle sessions were basically like noodling over ideas and, and noodling, you know, your thoughts.

and really it was about getting, EP and D members together to. Really ask like what are these hard questions that we need to unpack about the technology, about, the design of the experience and if there are any tradeoffs that need to be made. And it was intentionally outlined as a time together synchronously to handle these like very ambiguous and complex questions.

and I think, you know, calling it Noodle is really great because it kind of helps depressurize, the situation and say, you know, we're, we don't know the answers, but we're here to work together to at least pick at it and, and see if we can get somewhere with it. and also I think it helped set the expectation that, it is a group effort where you do need, all functions present in the room to understand both the problem and the solution.

Uh, and what would be the best option, to go forward. and sometimes a lot of the output of the Noodle will be. A review, with other stakeholders to say, Hey, we, we noodled on this. There are, two or maybe three options. Uh, we consider here's our recommendation. does make sense with the group here?

Do we have alignment? what other considerations should we be making from maybe a go-to market standpoint or customer insight standpoint? And how do we just harden or strengthen this proposal? and, and I think that's been really effective, uh, at a team level, where I think there's a lot of now empowerment for them to drive the decision making from, their vantage point, while bringing the rest of the company along.

And I think design here, kind of bringing this back, brings to the table a lot of the thinking, whether it's diagramming and working through what the user flow would look like. helping map sort of the concepts and, and nomenclature through like, mind mapping kind of exercises or through prototypes.

[00:29:41] Prototypes as lighthouses or lasers

Kevin: When you build a prototype and you think about visioning, I think it's important to ask yourself what is the goal?

Is this meant to be a lighthouse or is this meant to be a laser? When you have something that's a lighthouse, I think the, the intent of, what you're trying to do is really cast a wide net and really shine a light on all possibilities, so that nothing is left off the table.

And it really helps stretch people's imagination and thinking about how a problem might be solved. As opposed to a laser where you want to go very focused, and it's intended to help bring a lot of attention into one direction and to go, as far and as deep as possible so that, you're able to move quickly, not get distracted by, you know, other maybe enticing alternatives or options.

And so I think you, you also kinda have to read the room and say, what does the team need here? Do we need something that helps provide a lighthouse for the team, because we think there's something else here, but we're just not quite sure what it is. or do we need a laser in, on a solution? make some decisions and then make sure what we do to facilitate that conversation, serves that purpose.

and so that may mean like. Instead of having too many different prototypes and designs for one solution, it's, it's really going, down one path and going much deeper to say, here are the implications about our data model. Here are the implications about user permissions.

going into sort of those type of questions, I think are also valid concerns that people may have. And, and also add to the maybe idea of scope and effort that would be required in order to deliver on that experience to the customer.

[00:29:41] Prototypes as lighthouses or lasers

Kevin: When you build a prototype and you think about visioning, I think it's important to ask yourself what is the goal?

Is this meant to be a lighthouse or is this meant to be a laser? When you have something that's a lighthouse, I think the, the intent of, what you're trying to do is really cast a wide net and really shine a light on all possibilities, so that nothing is left off the table.

And it really helps stretch people's imagination and thinking about how a problem might be solved. As opposed to a laser where you want to go very focused, and it's intended to help bring a lot of attention into one direction and to go, as far and as deep as possible so that, you're able to move quickly, not get distracted by, you know, other maybe enticing alternatives or options.

And so I think you, you also kinda have to read the room and say, what does the team need here? Do we need something that helps provide a lighthouse for the team, because we think there's something else here, but we're just not quite sure what it is. or do we need a laser in, on a solution? make some decisions and then make sure what we do to facilitate that conversation, serves that purpose.

and so that may mean like. Instead of having too many different prototypes and designs for one solution, it's, it's really going, down one path and going much deeper to say, here are the implications about our data model. Here are the implications about user permissions.

going into sort of those type of questions, I think are also valid concerns that people may have. And, and also add to the maybe idea of scope and effort that would be required in order to deliver on that experience to the customer.

[00:31:19] Strategies for sharing your work asynchronously

Ridd: I love that distinction between the types of prototypes. I also think it's really interesting to hear you talk about, not only like the prototyping culture, but how much of that is happening async at Webflow. I wanna talk about that really quickly because it's kind of an interesting thing.

This idea of creating a prototype that you share with a loom and you kind of put it in slack. That is a very specific skill set that has become really, really important for designers over the last few years that no one ever really taught me that. It's certainly not in a boot camp, you know?

So. Could you talk a little bit about that tactic, even like in your mind, what makes for a good async prototype and maybe any tactics that that you have that you think designers who are listening could use to improve the way that they share their work? Asynchronously, see.

Kevin: when you think about asynchronous communication and a loom, how do you understand who is the audience or the person that I'm communicating to? , and if it's many people you're communicating to , who's the most important person I'm trying to communicate to?

, and then how do I tailor the format of the walkthrough , for that purpose. I think it's important that you set the right context.

, so you know, what is the problem that you're trying to solve. What insight do we have about it? What's the goal we're trying to achieve? , and then what feedback am I looking for by presenting this prototype or this design? I think those are really important details to , get right and to be very clear and upfront about at the beginning, just so that expectations, once you start to go through the prototype and, and the walkthrough and voiceover, , people who are watching have a sense of how they can contribute and, , and add value.

yeah, It's a combination of like context setting, go through screen by screen almost like storytelling in the shoes of the user.

Say, I am this customer. I work at this company. I'm trying to build this, , component that would be reused by the team. So here's how I'm gonna do that. I'm going to like, click here, click there, , and this is what happens. And then what I found really valuable and important is, , if there's a key question, , or something that, as a designer , or a product person, you know, is going to be a important point of discussion, say, , and here's where, we would need to talk more about, , again, like permissions or data models or what pattern is right.

Like this part feels a little fuzzy. So I think admitting that this is not meant to be perfect. , this is all like wet clay. We're all trying to shape this together. And to just call that out so that as a viewer, you're like, oh, okay, cool. Yeah, I also have questions about that. Or maybe I have an idea too that I can contribute to the thinking.

I think what also helps is sharing any links as background. So if there is a product brief or link to past research, , and the prototype itself, , those would also be a part of the description within the loom so that people who want to spend more time, , with the prototype or want to get more background and context around the business case, , they're free to do that.

And, and I think that will help enrich the conversation. things that we're trying , to get right is, when is it too long? How do you break things down into the right, like size, is there a difference between like, setting a vision, , and going really, , broad and like, you know, far out, , versus something a little more tactical.

, so , I think there's some nuance there as well, , to how you would, , try to make it as like consumable and actionable as possible that , we're constantly iterating with. I think there's a lot of like maybe concerns about, you know, sharing too soon or getting people's eyes on this, you know, that are, maybe not the intended audience, but I, I think that that's not really too much of a concern because one, I think when it comes to, you know, building, we, we wanna make sure we're bringing people along and I think that transparency is really important because.

We all want to, you know, be involved at the right time. and so there hasn't been any major problems where a link would get shared and, you know, someone's chiming in when they shouldn't be. I, I think we, we want to build a culture that welcomes opinions and welcomes point of view, because I think everyone has a point of view for some reason.

We just need to understand, like, what is the question for the question. and I think, I, I think one of the other hard skills for a designer is like, how do you weigh the feedback of different people? sometimes a founder or someone who's been with the company for a long time may have really strong opinions, and how do you weigh that against others and , we'll have to handle those sort of case by case and say, let's, let's follow up with, one of these, leaders or the stakeholder, find out what, what point of view where they're coming from.

and then we do have a, weekly sort of review ritual, which does bring a lot of stakeholders together. they're really sign up based, but the intent is this forum specifically is intended to, create a lot of alignment where we feel like there is a lot of, point of views that maybe in conflict with each other.

and it's a way to just cut through that, noise a little bit, and say, Hey, this is the decision that we want to make and we're just, you know, making sure that you have visibility into it or, we want alignment and, and here's like the two options and we want to, uh, tell you what a recommendation is.

[00:31:19] Strategies for sharing your work asynchronously

Ridd: I love that distinction between the types of prototypes. I also think it's really interesting to hear you talk about, not only like the prototyping culture, but how much of that is happening async at Webflow. I wanna talk about that really quickly because it's kind of an interesting thing.

This idea of creating a prototype that you share with a loom and you kind of put it in slack. That is a very specific skill set that has become really, really important for designers over the last few years that no one ever really taught me that. It's certainly not in a boot camp, you know?

So. Could you talk a little bit about that tactic, even like in your mind, what makes for a good async prototype and maybe any tactics that that you have that you think designers who are listening could use to improve the way that they share their work? Asynchronously, see.

Kevin: when you think about asynchronous communication and a loom, how do you understand who is the audience or the person that I'm communicating to? , and if it's many people you're communicating to , who's the most important person I'm trying to communicate to?

, and then how do I tailor the format of the walkthrough , for that purpose. I think it's important that you set the right context.

, so you know, what is the problem that you're trying to solve. What insight do we have about it? What's the goal we're trying to achieve? , and then what feedback am I looking for by presenting this prototype or this design? I think those are really important details to , get right and to be very clear and upfront about at the beginning, just so that expectations, once you start to go through the prototype and, and the walkthrough and voiceover, , people who are watching have a sense of how they can contribute and, , and add value.

yeah, It's a combination of like context setting, go through screen by screen almost like storytelling in the shoes of the user.

Say, I am this customer. I work at this company. I'm trying to build this, , component that would be reused by the team. So here's how I'm gonna do that. I'm going to like, click here, click there, , and this is what happens. And then what I found really valuable and important is, , if there's a key question, , or something that, as a designer , or a product person, you know, is going to be a important point of discussion, say, , and here's where, we would need to talk more about, , again, like permissions or data models or what pattern is right.

Like this part feels a little fuzzy. So I think admitting that this is not meant to be perfect. , this is all like wet clay. We're all trying to shape this together. And to just call that out so that as a viewer, you're like, oh, okay, cool. Yeah, I also have questions about that. Or maybe I have an idea too that I can contribute to the thinking.

I think what also helps is sharing any links as background. So if there is a product brief or link to past research, , and the prototype itself, , those would also be a part of the description within the loom so that people who want to spend more time, , with the prototype or want to get more background and context around the business case, , they're free to do that.

And, and I think that will help enrich the conversation. things that we're trying , to get right is, when is it too long? How do you break things down into the right, like size, is there a difference between like, setting a vision, , and going really, , broad and like, you know, far out, , versus something a little more tactical.

, so , I think there's some nuance there as well, , to how you would, , try to make it as like consumable and actionable as possible that , we're constantly iterating with. I think there's a lot of like maybe concerns about, you know, sharing too soon or getting people's eyes on this, you know, that are, maybe not the intended audience, but I, I think that that's not really too much of a concern because one, I think when it comes to, you know, building, we, we wanna make sure we're bringing people along and I think that transparency is really important because.

We all want to, you know, be involved at the right time. and so there hasn't been any major problems where a link would get shared and, you know, someone's chiming in when they shouldn't be. I, I think we, we want to build a culture that welcomes opinions and welcomes point of view, because I think everyone has a point of view for some reason.

We just need to understand, like, what is the question for the question. and I think, I, I think one of the other hard skills for a designer is like, how do you weigh the feedback of different people? sometimes a founder or someone who's been with the company for a long time may have really strong opinions, and how do you weigh that against others and , we'll have to handle those sort of case by case and say, let's, let's follow up with, one of these, leaders or the stakeholder, find out what, what point of view where they're coming from.

and then we do have a, weekly sort of review ritual, which does bring a lot of stakeholders together. they're really sign up based, but the intent is this forum specifically is intended to, create a lot of alignment where we feel like there is a lot of, point of views that maybe in conflict with each other.

and it's a way to just cut through that, noise a little bit, and say, Hey, this is the decision that we want to make and we're just, you know, making sure that you have visibility into it or, we want alignment and, and here's like the two options and we want to, uh, tell you what a recommendation is.

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers 👇

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watch”

Eugene Fedorenko

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watch”

Eugene Fedorenko

hello@dive.club

Ⓒ Dive 2024