Loading summary
A
What's the special sauce that designers bring to the table when everybody can execute?
B
I can pull things back, I can make it simpler, I can make it more understandable for the user. And yes, I care about making sure that button works exactly right or whatever. And I could have went in there and fixed it. But if I keep staying like on this end of the equation where I'm thinking in this realm, I'm more novel over there than I am in the execution realm because everyone can kind of execute right now.
A
How do you create these little moments that separate good products from great ones?
B
Impulsiveness in decisions can be problematic in the way that you can make bad decisions. But impulsiveness in your design is actually something I think you should facilitate all the time. Because trying out like one random thought pops into your head, go down that path, try it out, see what happens. If you're not playing or you're not like messing around, you won't come to those moments.
A
Welcome to Dive Club. My name is rid and this is where designers never stop learning. This week's episode is with Charlie Dietz, who's a designer at the browser company where he's working on dia. So he's going to give us a little tour of some of the finer craft details. But we're also going to do a deep dive into Charlie's personal design principles and all of the ways that they shape his practice. But before we get into all of that, this episode actually starts at Apple because before Charlie was designing ARC or dia, he was one of the designers working on Safari. And it's a fascinating to hear him talk about the differences between the two companies.
B
I was part of the human interfaces design team at Apple and it was kind of in a slightly transitional period where, you know, at least for me, I was like working on a bunch of projects across various teams. And my manager kind of came to me one day and was like, it's probably time to focus and like go deep on something. Kind of told me some of the options that were out there. And one of them was Safari. And I've always been in love with just pure utility driven apps and things that aren't necessarily flashy but work really well. That's, I think, my comfort zone. And Safari couldn't be more like that. In a lot of ways. It's like most people that use Safari literally don't know they're using Safari. It's kind of like that type of an invisible surface. And I was like, I wonder what that's like. So I met the team and started working with them and it was just awesome. Like I loved, like it was technically extremely deep. Like the things that they're dealing with were always rich. It was like multi platform, you know, like all the different platforms have Safari on it and it's like extremely highly used. I was like, this is a perfect scenario. So. And I just clicked with the people that were on that team and then ended up just doing that for like the entirety of my time at that company.
A
You say like the invisible interface in many ways and you don't even know you're using Safari. What were some of the kinds of things, things that you even work on as somebody who's designing a browser? Like, can we go a little bit deeper into what makes designing this type of product unique? Because the vast majority of people listening, myself included, probably won't actually get that experience.
B
It's interesting, like the positioning of something like Safari, which is like meant to be ubiquitous, versus something like DIA or arc, which are more crafted to be an experience. This is the same realm I've been working in, but like from totally different perspectives. Like with Safari doing something that like disrupts prior existing workflows or, you know, like Safari has been around for decades. People rely on their bookmarks bar in a very particular way. Taking risks there comes with like huge consequences. And also with such like an incredibly wide user base, you can't design for any one particular type of user. You have to always be designing for all users. Your decisions are this matrix of complexity. You, you can't just say like, this is the better experience. We're rolling with that a hundred percent. Because there's always downsides, it's always a gradient of usage. Like for example, let's just think about tabs. Like some people use like one tab at a time. Some people use like 4 to 5, some people use a bunch more. Some people are doing multiple windows, some people are using profiles. They want to have a bunch of windows open because they know that window, that space is where they like want to go. Exactly. Like, you can't make a decision for tabs without considering literally every possible use case. And that is always a very interesting way for me to think because it takes me out of myself. Like I could say like, this is how I want to use it. But then I basically have to immediately dismiss that as that's just one tiny speck in the spectrum of like different ways it's going to be used. And that's always challenging.
A
Real quick message and then we can jump back into it. So I got a Sneak peek of Desen's new private beta release. And let me tell you, they are taking the infinite Canvas to a whole other level. It's not just random mockups or one off prototypes. You can run real product pages directly on a canvas. I mean, just think about what that unlocks for parallel exploration. You can branch as much as you want, get the agent to explore multiple ideas side by side, which is perfect for aligning the team because you have one space to review prototypes, leave comments, and even get the agent to act on the feedback you receive. It's a big deal. But here's the thing. Desen is only onboarding a few teams every week, but if you go to Dive Club Slash Desen, you can book a chat with their co founder Gab and tell them Rid sent you to jump the queue. So head to Dive Club Slash desen. That's dessn. If you still haven't tried Paper, even though it kind of feels like everybody on this podcast is talking about it lately, they just made it way easier to get started. Because you can now copy and paste from Figma directly into Paper's canvas. All of the layers and their properties, including images and SVGs, are imported in an instant. It's pretty big deal and you can try it out today. Just head to Dive Club Slash Paper to get started. Now onto the episode. When you're designing for a gradient of use cases like that, does that mean that you just have to be more data driven and everything? Because you have to see all the different perspectives, like, talk to me about how you even figure out what those use cases are. When you're designing for a billion people using a product a million different ways,
B
you would think data driven would be a way to do it, and it probably is. But in my experience, it's mostly feedback, right? Like, people will be like, that's not working for me. You hear it. You hear it quickly too. Because another element of browsers is that people rely on them so much. Like if their workflows are interrupted in any way, like they are extremely quick to be vocal about how it interrupts them because they really rely on it as a tool, but at the same time they're mostly not thinking about it. So it's like you don't find out until you kind of make the change and start testing it. So at the browser company, our entire method of doing this is as soon as we have an idea, we put it in an internal build and everybody's using it immediately. Because you don't know. You just have no idea what's going to work or not until you just have it in people's hands. So this extremely quick iteration, extremely quick, that's failing. Let's stop right away, start again. And like, that's the way we work. And the company has always worked that way. And it is, like, I think, an extremely effective way of doing it because I think we're like, pretty public company in the way that we, like, express the work that we're doing. But the amount of things that we do fail and just drop and start over, like, it's a lot more than what we ever express in the world. So, like, the decisions that end up making it to the app in public, they've always been, like, through a process. It's a very different process than, like, the very deliberate nature of Apple's design. It's really spontaneous and, like, driven around, like, feelings. That's something that is, like, extremely important in the way that we just think about it. Like, did it make you say, like, this is better? You know, is it a feeling? For example, we've been thinking a lot about clarity, like a breath of fresh air lately. So we have something called the morning brief at the beginning of your day. India. Like, it'll like, kind of go out there and see what's going on in your world and then deliver you this brief about the things that are most important to you. But the way it's designed is like, when you open it, it's like the first thing you see is a painting and it gives you like a little sub headline, kind of just like describing your day. But it's always like, I'd say on the optimistic side of things. Like, it's like, you know, your morning's busy, but your afternoon, you have time to work kind of things, and then you have to engage with it. There's open space to it, right? So it's like I'm, when I scroll up, I'm going to see, like my first two tasks, maybe the three. But I'm not going to, like, overwhelm you, right? If I open another type of tool, I might see like, oh, God, I've got like 12 things to do right now. But this is like, hey, like, let's like, just give you a little bit at a time to make you feel comfortable the whole time. So that, that, that design for feeling thing is really important.
A
Let's go a little bit deeper there. Like, are there other mental shifts that you've had to make as a designer, moving from a world where even though you're designing the same Surface area. Technically, it's no longer just pure utility. You are creating what you call, like, an experience. Because everything you're describing with DIA here is. It's so many levels past the raw invisibility of something like Safari.
B
You're supposed to know you're using DIA to some degree. Like, it's. It's definitely, like, toned down in its overall presence from arc. When I started using arc, you could feel it. Like, it was just like, these people are having fun. End of story, right?
A
Like, I had a denim grain on my sidebar. You know, like, art was there, right?
B
Especially for that moment, I was just like, wow, they are having so much fun making this thing. And it resonated with people because, like, if you care about product development, with each little update, you could kind of be part of it and be like, wow, that was fun for me. Like, I can't believe you thought that. There's the downside of what happened with ark, which is that it didn't have a totally defined. Like, it was a huge experiment. A huge experiment that ended up working in a lot of ways, but, like, it was overflowing with ideas. And at some point you had to question, like, well, what is it? And I think, like, DIA starts from that point, which is. I think we actually defined what we were trying to create here from the very beginning. It's just we wanted to have an easier on ramp. When you first got into arc, the thing was like, oh, my God, there's so much new here. Which is great if you're willing, willing to explore it and look through it. But for someone who, like, switched from Chrome that morning, that they'd be like, I don't know if I got all this in me today to learn this whole new system. Whereas with dia, you could keep using it exactly like you were using Chrome 30 minutes earlier and just go with it and then introduce the complexity over time. Maybe like, oh, there's a sidebar. Like, there's a little popup that fires off once you start using enough tabs. It's like, did you know you can use the sidebar? Oh, that might be a good time to start to use it. Or, you know, like, introduce the complexity that existed in arc, but over the course of time in a way that's, like, meaningful to the way that you're interacting with it. So if you're the person who uses four tabs all the time, you're never going to see that, and it's probably not really relevant too. So, like, making a lot of decisions like that from Day one has been, I think, a success in dia.
A
There's a ton to talk about around this topic. So what I kind of want to do is use your personal design principles as a launching point because you've written about these and pieces on your website, and I'm wondering if you can kind of just give us the rundown and then we can use those as a lens through which to view some of your work and talk about some of the design process and things you're wrestling with.
B
With dia, this is an evolving type of thought. But, like, where I'm currently at is I think there's like, three values that work for me that have. They interplay together in a way that creates like, a little thing that I believe in, which is like. I think that the concept of, like, simple design is always attractive to me. It comes with downsides. I think that aiming for practical decisions ends up being really valuable in a lot of, like, you can be extremely whimsical. There's all sorts of different types of design that you can do that are beneficial for various situations. But when working on utility style apps especially, sometimes the practical decisions end up being the most valuable and cause the least interruption of, like, user experiences if they're coming from something else. And then finally, it's just doing these things at like, an extremely high level of quality, like a craft bar that's really high, so you can add back the personality through that step a lot of the time. But really what it does is if you have these simple, practical decisions that are executed at a really high level, I think it gives you a feeling of confidence often with like, the experience you're interacting with. And it's like the type of apps that I'm drawn to. Like, you know, things three or something like that is like a. It's like, whoa. It's a to do list you gold standard. Yeah. But at the same time, it really works like, it's been thought through all the way through, and it. It just works. What's interesting about these things at this point in time is like, I think it's really important that people have like, a framework of thinking for themselves, defining what they want to be doing with design. Because, like, as you know, tools are changing rapidly around us and it's very easy to get pulled into the tool and the tool guides your path of, like, what you're doing more. But if you constantly have like, this framework of how to think behind it, then the tools you'll use in the way that you're like, trying to execute that framework. Of thinking rather than being potentially more affected by a tool and executing things that don't exactly match what you probably want because, you know, like, well, if I can do this quick and it's awesome, that might create an output that doesn't exactly match, like, my goals. So I think it's like more important than ever right now to basically have these, like, systems. Whenever I bring up, like, values or principles, like, everyone like, is like, nah. Like, I see it in everybody's eyes. They're like, nah. No one really wants to like, think or talk about those things. But I do really think over the course of a lot of different work that you make, if you really have something like that, it starts to be thematic through your work and then, like, people know what you want to do and you'll get the type of work that you want to be doing. So I think it, it ends up benefiting you a lot in the long run.
A
I'm going to put a pin in simplicity because I want to come right back to it. But let's add a bit of clarity because I think you were talking about being pulled by the tools in an interesting way. Is there like a hypothetical or an example of that failure state that you can share? Like, what does it look like to not be rooted in values and let the tools pull you toward a place where you probably shouldn't have ended up going?
B
I can write code and I can write production code now in a way that I couldn't before. It seems very intriguing sometimes for me to just be like, you know, I can just go make those changes. What I find a lot of the time is the scale that I work at the browser company. It is more impactful to kind to keep creating designs and sharing those with engineers rather than going too much into the work. Specifically, if I am distributing more designs, I am distributing the problems that come along with those designs, whereas if I try to do it all myself and fix the problem, sometimes I will just not. I will be wasting time where I could be like, executing other designs which are helpful on other ways. And I'm just trying to think about, like, what my special sauce is in the equation. And I think what I, because of these values or whatever, it's like, I tend to like, reduce things back. I can pull things back, I can make it simpler, I can make it more understandable for the user. And yes, I care about making sure that button works exactly right or whatever. And I could have went in there and fixed it. But if I keep staying like, on this end of the equation, Where I'm thinking, in this realm, I'm more novel over there than I am in the execution realm because everyone can kind of execute right now.
A
Yeah, that's a good. You're totally right. Everybody can execute. Even yesterday I had this idea where, you know, we're like spinning up local preview builds in this Mac app that we're kind of playing with. And I had this idea for this loading state inside of the tab. I actually worked on something that felt similar to DIA tabs. In one of my explorations, I ended up going a different direction. I was like, oh, I'll just bring that in here and it'll allow me to delete this entire other primitive. Like, wow, that's such a good idea. I still think it's a good idea, but. But I started building it and as I started building it, I started realizing we're not handling this type of air case as well. And then I'm like, all of a sudden I'm looking at all of the different air cases in the arenas and all of these different failure states and I had this moment of like, oh, this is a trap. Like, I have went too far. I'm now 90 minutes into designing for air states that frankly, I have no business thinking about. It's not my special sauce. My special sauce was the idea, like the system level idea for what this component could be. And if I would have stopped there, I probably would already be working on something el where I could deploy my special sauce and I wouldn't be lost in these air states. That trap exists every single day for me now and figure out where that line is. It's like kind of the new challenge for a designer. Like when you said where everybody can execute now, are you really differentiating on the execution level? Maybe, but maybe not.
B
I feel embarrassed saying this, but it's like almost in my personal life, like I write more code than ever. Like I'm in cloud code. Kind of like every night is like my downtime or something, like just working on my website or whatever. But in work I've actually like probably shifted more towards Figma. And when I say that, I mean I'm shifting even more away from prototyping, which sounds insane because, like, I've always considered myself to be a prototyper, but it's like I actually am like, hey, this is it, let's get it going. And then we'll like figure it out down the road. Here's the visual, here's how it basically works. Let's get it going. And then like, we come back to it and, like, add in the magic slowly over time. But what I find is, like, yeah, it's like. It's actually kind of almost novel feeling right now. And not everyone works this way. This is like, you know, I'm. I think I'm, like, nervous about it because it's like, it sounds so radical for this moment, but it's been effective because, like, people are just cooking up code so much faster that it's like, well, they can actually handle more designs. Maybe that's what I should be doing because, like, I do know how to do that part for sure. And not everyone has that particular skill set.
A
So it's funny that we live in a day and age where this is, like, an incredibly novel take.
B
Yeah, it feels backwards because it's like, well, yeah, of course I would want to be more involved in the outcome, but kind of relying on bigger company experience. Communication is also a skill of design more than anything. And being able to communicate quickly, get it through, like, set the boundaries of what we're doing, what we're not doing, like, how far to take it, that actually is something I feel like I've been investing in more as well. Just how fast can I get you the information you need? How quickly can I make a decision that's, like, sturdy here? This year, I've been doing a thing which is in my Obsidian, I have, like, a file which is just called Decisions. And anytime I make something, I consider a decision a design decision, I write it in there, and then I go back a couple weeks or months later and say, like, was it a success? Was it a failure, or what had to change? And then I'm, like, essentially going back and being like, okay, where am I actually making bad decisions? Because that's the thing that I think is the highest value of me in the future is, like, if I can make more successful decisions, then I think that's kind of what design is going to turn into.
A
Are you able to see places where you've tweaked your practice as a designer based off of those decision logs and reflecting on them?
B
Yeah. For me, the biggest weakness is impulsiveness. So it's like, if I don't take a beat, sometimes I might make the quick decision, and it might seem totally fine in the moment. But often decisions require an extra level of awareness than you even expect. Right. Like, it may seem simple in the moment, but at least taking a beat before the decision and, like, reconsidering the deeper set of options every time prevents you sometimes from pigeonholing down into A bad path. I just like to be quick and like respond quick and like act quick. But the fact of the matter is is that's where I'll make my mistakes. Often if I'm just being a little too rapid and not maybe just reconsidering and reconsidering often like slows people down and they don't want to hear like, we're deep in this thing and like, I don't. Like we think we're pretty much almost done, but it's like sometimes just taking a beat and being like, okay, are we actually on the right path? Is this the outcome we want? And just going through it one more time before saying like, yeah, that's what we do. That could have saved me a few times.
A
Yeah, totally. It's interesting too, even to connect with what you were saying. It's that extra loop and practice of consideration that I find often is the only way that I can get to simplicity. I might have the right idea as my knee jerk reaction. We put in a lot of reps. Like that's not uncommon for me. Sometimes I return back to the idea, but then it's like, okay, knowing that this is directionally correct, but then going through it one more time be like, what can I distill or cut or combine?
B
Yeah, that's something I think Apple just does better than anyone else. And I think it's partially because of sort of this like one year release cycle thing. It's like at any point in that cycle you can kind of be like, is this really the right way? And you can go back to the beginning and it's like people kind of almost are expect that disruption as part of the process. Like it's very much part of the process to just be like, actually we're on the wrong path. Let's start over from this position. And I think that requires a lot of confidence and it requires a lot of low ego or something like you, you can't like just to be able to like and just emotional awareness and comfort. It's like, you know, it sucks to be like deep in something and be like, we're starting over and by the way now let's do it next year like, because we just don't have time. So you know that like that that can suck. So it's sometimes it really is the right call and it, it requires yeah like a lot of confidence to do something like that because it, confidence that you're going to stick together through it.
A
Let's talk about simplicity through the lens of the type of product that you'd be working on. Because I read your writing on simplicity and you reference, like old calc and how they're very purpose built. They do, you know, really kind of one thing. You're just doing calculations. And my question then is, like, how do you think about evoking the benefits of simplicity when you're working on something not only just like a browser, but also a browser in a world where AI is just woven through the very fabric of what the product is, therefore it can kind of do anything.
B
You know, I think it's often about just meeting prior expectations on one level. So for like, example, like working on WhatsApp was, I think, where I got into this mentality more than ever, which is like, it's a chat app, you should be able to chat in it. Anything beyond that actually dilutes the fact that that is a useful interaction in your life. Right. This was kind of from the founders. They had just this, like, incredible drive to make it, like, simple, fast, secure. It's like they had just really strong values about what the thing needed to be. And I saw, like, oh, if you hold on to those values through a product's life, people will believe in it. They'll like, trust it, right? Like, WhatsApp is very popular and people can't communicate. That got me really excited. But then, yeah, like any sort of like utility product, like, if you're relying on the thing to do a task for you and you want it to do that one thing, like, it's just gotta be like, that's the focus. And I think, like, in that writing that you're referencing, I think I kind of described like, oh, if your calculator started being like, I have a software update, or like, you know, like, there's this other feature that you can turn on now or something like that, you'd kind of be like, I'm just trying to make a calculation. And I think that software is so, you know, so beyond that point where you, like, accept all of these behaviors in our software that probably wouldn't be acceptable in that world where you're thinking about just a hardware device that you bought with your own money. But I think like a paid product is kind of like that. Like, if you pay for something, you're expecting something out of that thing and you should have that type of experience primarily, like, yeah, there's still room to be like, try out these other little features on the side or whatever, but the focus should be whatever value you're getting out of it. Also in that piece, though, I kind of show the contrary, which is no product ever really fully succeeds that way. I don't know if I said in there, but notion kind of comes to mind where it's like notion does kind of everything in some ways. The way I thought about it originally was like, oh, that's a nice simple text application, right? But it's like it's evolved so much from there. And I think the counterpoint to simple design is that people want less tools a lot of the time. If I can do it in notion, I'll do it in notion because I already use notion totally. And so there's like a value to adding complexity. You see this like, I mean like maybe Microsoft is kind of like the best case of this ever. It's like I don't hear often like, oh, like Microsoft design is like the pinnacle of like simplicity, right? It's, it's, it's kind of the opposite but like, oh, people got the value because you had all the different things you could do out of it, you know, and it's like they don't do all of those things perfectly well or whatever, but you could do all the things out of it. Kind of like was the vibe.
A
We're experiencing the pull of that as designers more than any other point in history too, because we get to outsource so much of that new functionality to the models themselves. So it's like wherever your entry point is to the model, you kind of can do anything, right? Like it takes a very bare bones set of primitives to allow someone to literally do anything. And that temptation to grow in every direction simultaneously has never been more present. So I'm going to like push on some of the things you're saying a bit because most people today, I mean by most it's probably like 99% of people aren't actually really using AI as a core part of their browsing experience other than maybe like a pre generated answer by Google at the top of Chrome, right? So like the value proposition of dia, at least as my interpretation of it is, hey, actually like AI should be a little bit more integrated into your browser. Use DIA instead. I would imagine you'd feel a little bit more pressure to pull people into some of these more interesting AI use cases that are potentially tangential to the core jobs to be done that you'd associate with a browser. How much does that resonate and then what is that like as a designer,
B
I think the evolution of DIA has been we started from this idea of like what is an Internet, that computer. And now you have this new technology as part of it. The level of the LLMs that we were dealing with early on made us think of it as kind of like a browser with chat. That was kind of like our first, you know, that's where we kind of landed. Then the LLMs got better and we realized the browser can make things, it can make you reports, can make you presentations, like, it can do all this nice stuff. So then it kind of evolved into like, like a browser where you can also make the pages, essentially, right? So that was kind of the next thought. I think what we've come to realize now is like, the truly valuable state of this thing is the browser is context and it's effortless context. You're just doing your work in the browser, but the browser is capable. So, like, I think the morning brief, like, kind of defines this as the first step, right? Like, it's like, here's all the things in your life and I can report back to you on them in a way that helps you move forward. And you don't have to do anything like, and I'm just adding value because you're using the tool that you are already using. It's a constant evolution as the technology changes underneath us of like, what we're capable of doing. But, like, the end goal is an Internet computer. I know that sounds like really bombastic, but it's like, it is a thing and this should be your interface into that type of computing. And the more that it can do it, the better because, like, you know, you spend so much of the, your time in the browser that why not have the features there? So it's like going back to the simplicity thing, it's like, how do you make that feel nice and simple?
A
There's one question that I can't stop asking myself. What if companies applied to talk to you rather than the other way around? And that question is the, the foundation for the all new Dive Talent network. And it's working. Like, right now I'm helping many of the most exciting startups that I know to hire the designers and builders who listen to this show. So if you're curious what might be out there and if you want to get on my list, or maybe you're even looking for your next design hire, head to Dive Club Talent to join today. I remember sitting on a plane reading Josh's initial post about the Internet computer and finding it very compelling. I also remember interviewing Nate Parrott, the first design hire at the browser company, probably a couple years ago now. And one of the things that he talked about as call it a prototype that you all were wrestling with internally was is there a new tab home screen? Like, is there? If you hit command T, do you see anything? In some ways like the daily brief is, it's an extension of that same idea, right? Like that strand has been fore ever. I almost anyone who's designed a browser has thought of this, right? Why did it work now? Like, what did it take? Like, what were some of those internal debates in terms of what the morning brief became? Different design expirations, what didn't ship, anything that you could do to add a little clarity around what that design process was?
B
The first thing we kind of did was we introduced something called new chat. And this was, you know, this higher tier of LLMs in the browser. We weren't like, wow, it does all this stuff. It was like, kind of like overwhelming, but we just had like an internal discussion. We're like, it'd be so much cooler if it just did this automatically. It was that simple, right? So and deliver to you, like, I don't want to do anything, just give me the value of the common things that I'm doing with it. And like everyone was kind of being like, what am I not caught up on? You know, like, those are the type of things that people were pulling out. So the morning brief just came to you answered those questions without you doing anything. And then we immediately saw like, oh, that that's hitting with people. Like they, they found it valuable. And so that, that was like a good starting point for a product.
A
Can we talk about the practicality piece a little bit, given everything that you're working on? I don't know. I think designers everywhere always feel this push to do the novel thing, right? To create the pattern that's changes the industry. You know, what is the pull to refresh for the browser kind of thing. I'm sure that you're experiencing a lot of that, like how stay grounded. What does it take to know when to push past the obvious solution versus when to just pick the thing that people are familiar with.
B
This team happens to be a team of people that are all willing to try to come up with those like new paradigms or new experiences and push forward. And then I think we also have this like counter opinion, which is like, sometimes the obvious solution is the right solution. So like I think in dia, for example, the bookmarks bar, like we tried everything, we tried a little backpack where you throw stuff in. We wanted bookmarks because we wanted to support like if you're coming over from Chrome, like you Got to have access to your bookmarks. And we were like, you can make those amazing. You can make them. Like, I think we have the design article and it shows, like, a small screenshot of, like, eight different directions or something we chose. But it was like, we tried everything. We tried it for months, and in the end we shipped a bookmarks bar that's like, nearly identical in functionality to Chrome. And that was, like, choosing the obvious solution. It was not that we wanted to make it a basic bookmarks bar. That didn't sound like what we wanted to do as designers, but, like, at some point, the egos kind of like, just go away. And you're like, yeah, people actually who want this feature just want to use it the same way. And you can turn it on, you can turn it off, just like a normal bookmarks bar. You can have folders in it, you can open them the normal ways you would. And, like, it just met expectations. It had low downsides, right, like, other than, you know, us wanting to do something magical with it. But it wasn't an easy process. It was a very difficult process to come to that kind of a conclusion. We just couldn't find something that was a remarkably better. Like, for, like, one we had was like, anytime you took a tab, you could just, like, pull it up a little bit and the page would move down and you could, like, put in these little stashes. It felt awesome. It was cool, but it was, like, less discoverable. It was a longer interaction. You know, it's like it just came with downsides, like animation states. Like, stuff's moving around. It's like the bookmarks bar. It's like, if you want the thing, all your bookmarks are there. It's really dense. You can press them. Let's just make it look as pretty as possible, move on to the next thing.
A
If you think about having a fixed budget for novelty as a designer, where have you been more excited or willing to spend it?
B
The first stage of DIA was, can we keep our novelty budget almost entirely to the new features of the technology that's being developed? We shipped only with the top bar. To start, we shipped with a bookmarks bar. We shipped, you know, just basic pin tabs and stuff like that. Like, it was like it was bare bones to start. That wasn't where the exploration started. We, like, decided at some point, like, the novelty budget is going to be completely on the new things that you have to learn using this app. And we wanted room to grow in that area. So the more comfortable you were with the pre existing UIs that you were used to, the less you'd have to take on mentally when DIA came out. Like, I know this is silly, but it was like, it was a little novel to have, like, chat just built directly into the browser as, like, you know, we tried so many different ways to, like, integrate it too. And like, we kind of kind of went with the one that would be the most expected, which was the sidebar is kind of like the primary interaction, because it's like, I have the context of the page now, I have my chat, and it works, right? So even that was like, kind of like reducing the novelty as much as possible.
A
You have kind of been spending it in little places by bringing in some of the ARC functionality and almost reevaluating what needed to exist again. Can you talk about that process a bit? Like, maybe you can even give us a behind the scenes of how you're thinking about bringing the ark spaces into dia. And what's that like? Like, how do you find the right implementation for this more refined vision?
B
In dia, we have a checklist of all the things that ARC does really, really well, that people are passionate about, and we kind of have just been moving down it one by one on, like, the order of what people are saying is the most important one. So, like, you know, at one point there was no sidebar, and that was kind of like a moment for us. We were like, okay, we are going to like, it was always a possibility to do sidebar top bar. But. But one is, we wanted to differentiate DIA enough in V1 that it wasn't our Final Cut Pro 7, I think was out. And then the Final Cut Pro X came out or something like that, and it was like they tried to kind of match all the features, but it didn't match. And people were like, really upset. Or this happened with, like, Lightroom CC and like Lightroom Classic or whatever. Like, it was like, not a total match. And when you have that and they're so close but they don't match, you just get like, kind of pure disappointment out of the new thing until you can build it up. But, like, we were hoping that DIA was differentiated enough that you're like, this is a different browsing experience, right? But yeah, like, we love all these features in ARC and we want them in DIA because we want to feel satiated by the stuff that we enjoy at ARC too. So it's like just listening to people seeing what's right. So we started with sidebar. I mean, maybe we started before that, but, like, sidebar was a Big one. With every single one of these features that we introduced from arc, we do take it through the full process of reconsidering. Like, where could it be improved? How does it fit in with the differences of dia? Can we just do it better in any particular way? So with the sidebar, for example, like, one of the main differences between DIA and ARC is ARC is really like a single window application, which is kind of like a little unusual for a browser. Like, if you open another window, it's like everything is essentially synced between those two windows. You can have them in different states, but it's like, it's one thing where DIA allows instanced windows. Right. So it's like I can have one window that's completely different than another one. You know, there's considerations that need to be taken into account. When I like, if this one is in profile X and this one is in profile Y, what. What is the overlap? What is shared between the instances and what is not? So, yeah, every feature that comes through, we try to, like, run it through the whole process. Also design really widely. Think about, like, maybe sidebar's on the left right now. What else could you do? Like, what are the other ways that you could show vertical tabs? We tried other things. Sidebar still ended up, like, being pretty much the one that checks the most boxes. Then we went forward with it.
A
What's funny is a bunch of other products in the industry went through the exact same exercise with the sidebars, and everybody kind of just arrived at like, yeah, our kind of got it right.
B
Yeah. And now there's like, like a lot, A lot of browsers that offer a
A
sidebar that's not look exactly the same. Okay, let's talk about the quality piece a little bit. I'd love to see what that. That looks like in practice in DIA and where you all are intentionally trying to, like, go above and beyond and push past the baseline. From a craft standpoint, I think a
B
lot of the quality moments in DIA come from really, like, small or nearly invisible moments. Like, Casper on our team added these, like, really nice interaction states for the little buttons. Like, when I reload, it spins, turns into the X and it pumps, pumps back, back out. If I like, the arrows move when you tap them or whatever. These are just like, small moments in the app, but it's things you may do a lot, and you kind of get like, a sense of the refinement through them. Something I worked on, which I still feel really excited about. I don't think people probably think about it very much. But like the URL bar, we changed how it works. We show the domain and the page title rather than the domain and the URL. But at the same time, you're not blocked in any way. So as soon as I hover into here, I have access to the URL, but when I'm not on there, I have the page title, which can sometimes be useful. This was like a extremely small moment, but to me it always, it adds value. Like, maybe because I paid a lot of attention to it in the first place, but I'm like, it just, it's a grounding sort of thing. And it. You don't see complex dirty URLs with a bunch of numbers in them ever. You know, you just have a sense of the page you're on. And that felt like the next, next evolution of a URL bar to me.
A
I really like that example because you only arrive there if you are going through a browser's UX from first principles with like a very fine comb, you know, like, I'm not sure how long it would have taken me to arrive at that as even a potential thing that you could do. It's very cool.
B
Another one's like, if you copy a page link, so if I hit Command shift C, it'll just quickly change that URL bar to give you the status of what happened in the position that it should have happened. And actually, what's also nice in here, like another nice little quality moment, is if you have a URL that has, like, trackers associated with it and you copy that URL, it will remove those trackers and give you a clean URL. But then it also alerts you to that. In the text it says like, copied link without trackers or something like that. So that's like another gesture of quality.
A
Helps someone reverse engineer some of this stuff. Maybe it's going back to what we were talking about earlier, where like, the execution level details are not that crazy for any of this stuff. It's your ability to see them and have the creative idea that, like, oh, wouldn't it be cool if X. Do you have any advice for a designer who wants to stop listening to this video, turn to their product and find some of those quality details?
B
Yeah, I would say that this is the counterpoint to my impulsive conversation earlier, which is like, like, impulsiveness in decisions can be problematic in the way that you can make bad decisions. But impulsiveness in your design is actually something I think you should facilitate all the time. Because trying out like one random Thought pops into your head, go down that path, try it out, see what happens. Like, I think Casper is, like, a really good example on our team. Like, he's just looking around, looking at the buttons. Like, what are the buttons that are here all the time? What can I do with them? And then, like, ideas just come to you and you try them. And. And because of the browser company's just ability to facilitate this, try anything, we don't know attitude, he'll just throw them in the app. And then you start to find out if these things are valuable or not. I think it's just about wasting time. I guess I would describe it. I can stay on task. I have these things that are really important and I have to get them done because the company has goals and all these things are moving things forward. But if you're not playing or you're not messing around, you won't come to those moments.
A
Yeah, I like that. The question, what can I do with them? Is so interesting to me because even looking at that URL bar, I think that's an improvement. I really like it. Nobody ever is going to come to you with a problem and say, you know, I have this problem in this piece of software I've been using. My.
B
It's not solving a problem.
A
The URL bar, You know, like, God, if you could just solve my. No, nobody's ever. There's not one person on planet Earth that's ever been like, I have a problem with my URL bar. It's just the way that it is. You only arrive there through play.
B
Here's another one that doesn't solve a problem. Um, but it kind of does. But I'll show it. When I open a new tab page, there's this animation and you see this sort of, like, prism effect move up into the input one. It ends up focusing your eye to the correct element. So, like, you could argue that wasn't a problem, but it actually helps a bit.
A
Yeah.
B
And. And two, there's not a lot of moments where you can actually fit animations in. Like, for example, moving between pages, I should. Like, there should be a crossfade. Right? That would feel better, but it always feels slower. Like, that's like. I've tried many times to have, like, some sort of state change between pages. It just has to be a snap. But you can do things on the back end of, like, loading a new tab page. Like, the page is loaded. I can start taking action while that animation plays out. But it still, like, gives me a segue into the experience here's the one that doesn't need to exist. Adam, who's an engineer on our team, totally made this thing a fidget spinner for no reason. This element is also used throughout the app, like when I'm getting chat responses like, oh, me about red. I'm talking to him right now. You'll notice that this thing goes out and it changes from the new tab page into here and now. It's going to give me status about what's occurring and it acts as sort of like the focal point. So it's like that continued UI ends up being just a way to drive you forward.
A
You guys have done some work on these interactions. I'll be honest. Like I'm using arc. I'm recording this in ARC right now. I'm on the fence. I'm getting really, really close to coming back to D. I'm really close spaces, you know, that's like one of the big things for me. This level of interaction detail has come a long way in the last eight or so months. Like that is gorgeous stuff.
B
Ark, in the state that it's in was developed for like half a decade and I think that was a bit of a confusing transition moment for users with dia because we had only had like a year into it when people really started like judging it. And the idea is that we've just been like, like pumping non stop effort into both the micro interactions as well as the main features. And I, I mean like I paying a lot of attention to it because I'm so invested in it, but it's really at the level now where you can appreciate these things and the overall experience. About maybe six months ago we were like, oh, people love ark. Like we want them to love dia, so how do we get them there? Like, how do we get them to have that feeling that they loved Autobahn arc, but it's like, it's a different app, it's like a different, different experience overall. So it wasn't like it was a playbook that we could just like do exactly the same. It's like we had to think about these things from some new perspectives, but trying to bring back that feeling, emotion and getting you invested in the thing more than just pure utility before we
A
switch any other craft details that you wanted to show.
B
So another interaction that we have both in ARC and DIA is being able to split tabs within your window. And with that we wanted to make it like more clear how to do it because it's not maybe the most common interaction, but it's, it's, it Ends up being really useful in a lot of situations where you just are trying to compare information or do one thing in one tab and see the information, another tab. So we built this paradigm where you could drag out the tab. And then Adam Stern built this, I should say. He's an engineer on our design team. And it just kind of like, guides you to what will happen. And, like, basically just the language and the drop target then allows you to know more clearly what you're going to do. Like, it actually comes with some downsides. There's like a less space for you to drag the tab, whereas in the arc paradigm, it's like just the whole half of the window. But it. The education element, we thought was, like, important to this, making it more clear, like, what is going to happen. And yeah, it was like a cool little interaction he came up with. And I really like that one.
A
That was amazing. Charlie. I appreciate the tour, and we're approaching the end here, but I have saved the deepest, most gripping, most important question of all. That question is, who is your favorite designer named Gabe?
B
Gabriel Valdivia. Like, this isn't even a question. He might be my favorite designer. End of story. Oh, and his ego is going to explode when he hears that.
A
Well, I was texting him last night and I asked for a few quick hitting questions that we could ride off into the sunset with. And the. There's some. Some practical and educational, and others are a little bit more playful. The first one, I do think that everybody listening has a lot that they can learn from you on, which is, what are some of the less obvious tips that you've added to your practice as a designer when it comes to presenting and getting people excited about your work?
B
Yeah. I think this one I actually feel really strongly about. So. Great question, Gabe. You're doing wonderful. It's got the context. I have a pretty particular strategy for presenting information, which is I really aggressively guide the conversation to a certain point. Like, I want people to be on the same page when they're having the conversation, and that often requires me giving context as fast as possible, but as clear as possible to get people up to speed with where I'm at. Because, like, in general, I often think that designers have sometimes the most context on a problem because they're in it. You know, like, they're. They're, like, thinking through all of the various things from. And it's just. It's repeating in your head. Right. But, like, maybe I'm in another position and I'm coming to this to kind of, like, help Make a decision. And I thought about it from just one particular angle. So like one spreading that context out, giving everyone like the same starting point, but then also framing very clearly what the problem is we're trying to solve so that everyone can be like, okay, we all agree to this point that this is what has happened and this is where we're at, but this is the next step for us. And like, yeah, my job is to provide a solution and be cool about it if people don't like it. But like, but it's more important that I provide a question to have an answer to so that at the end of whatever conversation we're having, we can all agree that we answered that question. And then like in practice, like I often think, you know, it's like I don't show the design necessarily right away. I like kind of over explain it like this. First I try to reduce the information that I'm presenting down to just like the essential points. Because people are going to ask whatever question they need to know to fill in the gaps. Like nobody has a problem really with that. Like people will ask the questions, but it's more so like trying to make it digestible so that everyone's on the same page and keeping it really high level to do that. I think that that that's, that's kind of like my strategy for conversations in both big companies and in one on one environments. It's like, I think it feels pretty effective in general.
A
Is there an example, either real or hypothetical, that you could share about what a good foundational question to answer looks like.
B
The type of question I would try to focus like a meeting scenario on is often hopefully lower level than the bigger problem. Right? Like, hopefully I've done the work that we're in the right space already and I'm solving for the right general problem. What I often will present as the problem is something like, okay, if we take this path forward, these are the downsides. If we take this path forward, these are the downsides. Here's the advantages. You get on this side, here's the advantages. Like this is like a matrix now that we can kind of point our fingers at details, we'll deal with those. But like, if we go this path, I have confidence in my next steps and I can move this project forward. People will always feel comfortable like breaking out of that, being like we're not in the right problem space if that's the case. But like for the sake of a conversation, limiting it to whatever needs to be solved next to move forward. And that's often sometimes, like, bringing it down a level which is sometimes different than, like, if you're going to, like, be presenting up to, like, an executive or something, and they, like, they really need the context of. Of the meta decision. Like, that's the type of decision they're making. The, like, really hard, complex one that may be more vague or whatever, but if it's like, you know, design crit or something like that, it's like, let's just like, solve this one right now or.
A
Okay, I had two more Gabe questions for you. The next is, how do you manage the panic that comes with high pressure design environments?
B
I have a lifelong anxiety disorder. It's just natural for me to feel, like, tuned up. What's cool, cool about design is somehow I've turned it that anxiety into just, like, motivation. Often I, like, get excited. Working with Gabe often does this to me a lot, which is like, when we work together, we're both probably really anxious, but we get really excited and, like, push each other and, like, we're just like, do it. It becomes, like, really frantic or something. I just think that turning the anxiety into energy and motivation, it keeps me going and excited. And then I just associate design with being excited. That's how I deal with it. And, like, I try not to. The hardest part is always, like, trying to remove the personal element a little bit. The hardest part about coming up in design is, like, you're going to be passionate about your ideas, and sometimes people are just going to think they're bad. And you might even be right, like, it's still a good idea or it's like, a good execution. And people might be down on it for all sorts of reasons, reasons that you can't expect, but, like, being willing to go with the flow, try out what other people are suggesting. I was an only child growing up, so it's like one of the challenging parts for me was kind of like being truly collaborative in the design process. But at some point when you're like, internal confidence comes up to a level. It gets way easier to be collaborative because I'm like, yeah, I'll try it. You say it like, Gabe throws me something, I'm like, yeah, I'll try it. I don't even question it. Even if I don't like it. I. That's like, let's try it. Let's find out. I mean, people really appreciate collaborative designers, people who are willing to work with you and whatever you're thinking about, but also, you know, coming to it with, like, an excitement if they see it back, and they're like, nope, that's not what I was hoping it would be like. Then, boom, we're on the same page now. You're probably going to be maybe more into the thing that I was into, and we're moving forward. It's like, it's just a way to keep it going really fast.
A
I always struggle to make sure that I'm dedicating the amount of creativity and mental resources to. To the things that I kind of know are the bad ideas. And, like, I'm going to put in the reps, but I don't want to sabotage the idea, you know, for my own selfish gain. I've been.
B
It's just a sample. Like, this is what it looks like. You wanted to see it. Here's what it looks like. We're going to hopefully be moving on.
A
Quick looks just as bad as I knew it was going to look. All right, last question before I let you go. When are you bringing back bread time?
B
Okay. There's a secret episode we recorded, I think, two years ago, but really both, like, we recorded it video style, like, all modern. We both were like, not now. We finished it and we both said, not now. Like, it was. It was very fun. For the six hours after we recorded, I was like, I can't wait to do this again. And then I think we both realized it's really important for us to focus on the things that we're doing in our primary stuff right now. And it would end up becoming a pretty serious distraction because, like, when we did it, we were all in, like, it was really, like, took up a lot of our mindscape and took up a lot of time, and I think we would want to do it with that same level of passion again. But doing this type of stuff, like, being in public, it's a stressor putting yourself out there. Like, for anyone who's ever, like, gonna be talking on a show like yours, you know, it's like. Like it's. It's dangerous. And that. That's part of, like, you know, it's going to be on your mind in different ways to put yourself out there in the world. So I think we just decided, like, now's not the right time. Like, maybe again in the future, you
A
just give me a heads up when you're going to come for the the Design podcast game so I can figure out other ways to feed my family. I just need, like, a few months heads up.
B
We will not be a competition, but we will be a weird other thing that people can appreciate hopefully.
A
Well, I I'm. It's always fun. Like, it's fun to listen to both of you. But also, I just really appreciate you coming on today, and you've given me a lot to think about. I. I still even have some of the secret sauce and creativity versus execution ideas bouncing around in my brain. I really appreciate you bringing that perspective and sharing a little behind the scenes. Always good to catch up.
B
Yeah. Thank you so much for having me. I. I told you off air, but it's like I watch every episode of the show. I really think you're doing a great job, so it's very much an honor to be here, and I appreciate it. Thanks, Charlie.
Date: July 29, 2026
Host: Ridd
Guest: Charlie Deets (Browser Company; formerly Apple, WhatsApp)
This episode dives deep into the craft, philosophy, and evolving role of designers working at the edge of browser innovation. Hosted by Ridd, the conversation features Charlie Deets, lead designer behind DIA at the Browser Company and formerly on Safari at Apple. Together, they unpack the differences in design mentality at massive scaled products versus crafted, novel experiences, using DIA as a lens. They share actionable insights on balancing utility, simplicity, and delight amid the age of AI and “everyone can execute.” The episode is packed with practical advice, designer war stories, and uniquely candid reflections on the designer’s evolving role.
“You can’t make a decision for tabs without considering literally every possible use case.” – Charlie, [03:09]
“You’re supposed to know you’re using DIA to some degree… When I started using Arc, you could feel it. Like, these people are having fun.” – Charlie, [09:29]
“The amount of things that we do fail and just drop and start over… it’s a lot more than what we ever express in the world.” – Charlie, [06:26]
“Simple, practical decisions executed at a really high level… gives you a feeling of confidence.” – Charlie, [11:48]
“It’s more important than ever right now to basically have these systems.” – Charlie, [11:48]
“What’s the special sauce that designers bring to the table when everybody can execute?” – Ridd, [00:00] “If I keep staying like on this end of the equation where I’m thinking in this realm, I’m more novel over there than I am in the execution realm.” – Charlie, [00:04]
“That trap exists every single day for me now… Figuring out where that line is…” – Ridd, [16:11]
“The temptation to grow in every direction simultaneously has never been more present.” – Ridd, [25:33]
“…the bookmarks bar…we shipped a bookmarks bar that’s nearly identical in functionality to Chrome… Sometimes the obvious solution is the right solution.” – Charlie, [31:03]
“Can we keep our novelty budget almost entirely to the new features of the technology that’s being developed?” – Charlie, [33:09]
“A lot of the quality moments in DIA come from really, like, small or nearly invisible moments.” – Charlie, [37:39]
“If you’re not playing or you’re not like messing around, you won’t come to those moments.” – Charlie, [40:11]
“Anytime I make… a design decision, I write it in there, and then…was it a success? Was it a failure, or what had to change?” – Charlie, [18:38]
“I really aggressively guide the conversation to a certain point. Like, I want people to be on the same page…” – Charlie, [46:36]
On fitting innovation:
“Sometimes the obvious solution is the right solution… at some point, the egos kind of just go away.” – Charlie, [31:03]
On what makes designers special:
“I can pull things back, make it simpler, more understandable for the user… I’m more novel over there than I am in the execution realm.” – Charlie, [00:04]
On quality moments:
“You don’t see complex dirty URLs with a bunch of numbers; you just have a sense of the page you’re on.” – Charlie, [37:39]
On “creative waste”:
“It’s just about wasting time… If you’re not playing or you’re not messing around, you won’t come to those moments.” – Charlie, [40:11]
Defining the “internet computer” browser vision:
“The browser is context and it’s effortless context… you’re just doing your work in the browser, but the browser is capable.” – Charlie, [26:39]
Charlie Deets gives listeners a behind-the-scenes look at how high-level product vision, iterative exploration, and principled simplicity shape the evolution of one of today’s most ambitious browsers. The conversation is rich with real-world examples about the nuanced difference between utility and delight, the designer’s value beyond execution, and the power of small details. Listeners walk away with tactics for reflection, presenting, and collaborating, a clear-eyed view of simplicity in a complex (and AI-driven) world, and the importance of nurturing creative play to deliver truly novel digital experiences.
For more episodes, key takeaways, and resources, visit Dive.club.