Most people do not think about design when a thermostat works, a fitness band syncs, or a banking app helps them make a decision without friction.
That is usually the point.
Great design disappears into the experience. It reduces confusion, hides complexity, and makes hard technical systems feel obvious. But behind that simplicity is a long chain of decisions: what gets built, what gets cut, what gets explained, what gets tested, and what actually makes it into the customer’s hands.
Lauren Von Dehsen has spent her career working inside that chain.
Across Nike FuelBand, Nest, Google Health, Matter, and SoFi, Lauren has helped shape products at the intersection of hardware, software, and human behavior. Her work has touched connected devices, smart homes, healthcare, fintech, and now the emerging world of AI-assisted design.
Her biggest lesson is blunt: documentation is not the product. The process is not the product. The customer only judges what ships.
That idea sounds obvious until you watch how teams actually work.
The Product Is the Only Thing the Customer Sees
Early in her career, Lauren wrote about the idea of designing the product, not the documentation. At the time, she was working in environments where hardware and software had to come together in new ways. These were not mature product categories with well-worn patterns and obvious playbooks. Teams were inventing the product, the process, and sometimes the testing methods at the same time.
On Nike FuelBand, for example, people were literally running up and down stairwells to test whether the device was tracking activity correctly. That is the reality of building something new. You do not always have a clean lab environment, a perfect spec, or a known answer. You have a product that needs to work in the messiness of the real world.
For Lauren, that shaped a core belief: a designer cannot just hand off polished screens and assume the job is done. The real work is making sure the idea survives contact with engineering, testing, constraints, trade-offs, bugs, edge cases, and launch pressure.
A beautiful design file does not matter if the shipped experience fails.
That mindset is especially relevant for startups. Founders often confuse design with surface area: colors, screens, typography, polish. But design is more fundamental than that. It is the practice of making decisions about how a product behaves, how people understand it, and how the experience holds together under pressure.
Nest and the Power of Cross-Functional Design Culture
One of the chapters Lauren looks back on most fondly is her time at Nest.
Nest was not just a company that made better-looking thermostats and smoke detectors. It helped redefine how people thought about everyday objects in the home. Before Nest, most people did not spend much time thinking about their thermostat. It was a beige plastic box on the wall. Functional, forgettable, and usually ugly.
Nest changed that by bringing software-level interaction design, hardware craft, and brand-level attention to a category that had been ignored.
But the real lesson from Nest was cultural.
Lauren described an environment where she did not have to constantly explain why design mattered. Everyone cared about the product experience. Engineers, product leaders, designers, and other functions could debate almost any aspect of the product. The difference was that, after the debate, the team trusted the person closest to the decision to make the final call.
That balance is rare.
In weaker cultures, design is either isolated as “the designers’ job” or diluted into endless committee feedback. At Nest, design was everyone’s responsibility, but designers were still trusted as experts. That is a powerful distinction.
For founders, this is one of the most important takeaways from the conversation. If design matters to your company, it cannot be something you bolt on at the end. It has to be part of how decisions are made from the beginning.
What Founders Get Wrong About Design
Early-stage companies often bring designers in too late.
A founder may define the product direction, product managers may shape the requirements, engineers may begin scoping the system, and only then does someone ask design to “make it usable” or “make it look good.”
That is backwards.
Lauren argues that designers are most valuable when they get context early. Not when every decision has already been boxed in. Not when the team simply needs a screen. Early context allows designers to understand the customer, the business goal, the constraints, the technical trade-offs, and the hidden assumptions behind the product.
That does not mean every startup needs a huge design team. It does mean founders need to be honest about what they expect design to do.
Are you hiring someone to make the MVP presentable?
Are you hiring someone to define the customer experience?
Are you hiring someone to help shape product strategy?
Those are different jobs. They require different levels of seniority, different skill sets, and different levels of organizational trust.
The mistake is not choosing one path over another. The mistake is pretending you want strategic design while treating designers like production support.
Scaling Design at SoFi
Lauren joined SoFi in early 2020, just weeks before the pandemic changed how teams worked. At the time, SoFi was in a high-growth phase, operating across a wide range of financial products: banking, investing, lending, crypto, and insurance.
That created a very different design challenge from Nest.
At Nest, the work centered on tightly integrated hardware and software experiences. At SoFi, the challenge was scale, complexity, and coherence. How do you create one unified customer experience across financial products that behave very differently? What should be shared across the brand? What needs to be specific to each vertical? How do you build a mature design and research organization that can keep pace with a growing company?
Lauren eventually scaled SoFi’s design and research function into a 100-person organization. That required more than hiring. It required building rituals, processes, expectations, and cross-functional relationships that could evolve as the company changed.
One of her points is especially useful for leaders: rituals have to serve the outcome. They cannot become the outcome.
Design critiques, reviews, sprints, and research processes all have value. But as companies scale, the same rituals that once created alignment can become bottlenecks. A critique with five people may be useful. A critique with 30 people may be theater.
Good design leadership means knowing when to change the system.
Process Is Useful Until It Becomes the Point
Design teams love process. Design sprints. Double diamonds. Workshops. Critiques. Frameworks. Research panels. Naming conventions.
Some of that is useful. Some of it becomes internal language that does not help the broader company.
Lauren’s view is practical: use the tool if it helps the team get to the next decision. Do not worship the tool. Do not over-explain the ritual. Do not assume cross-functional partners care about the purity of the method.
Most partners want to know what decision is being made, when the answer will be ready, and whether it will help the product move forward.
That does not mean design should become reactive or shallow. It means design leaders need to translate their work into business-relevant outcomes. The best design process is the one that helps the team build a better product faster, with fewer blind spots.
Anything else is overhead.
AI and the Next Wave of Design Tools
The conversation also turned to AI and how it is changing design.
Lauren sees clear productivity gains. Designers, like everyone else, can use AI to brainstorm, write, summarize, explore concepts, and accelerate early work. But she also sees a major limitation: design is not only language.
For many software tasks, moving from keyboard input to conversational prompting is a relatively natural abstraction. But design often involves spatial judgment, visual hierarchy, motion, color, breathing room, sequencing, and subtle interaction details. Describing those details in words can become frustrating fast.
AI tools may generate strong first concepts. But as the designer tries to refine the work, make precise changes, and bring the output closer to a specific vision, the process can become fatiguing. The more exact the desired change, the harder language-only prompting becomes.
This is why Lauren is interested in tools that combine chat-based interaction with direct visual manipulation. The future of AI design probably will not be pure prompting. It will be a hybrid interface where designers can generate, edit, manipulate, critique, and refine in the same environment.
The open question is which tool becomes the design equivalent of the AI coding copilot.
The Hardest Design Trade-Off: Craft vs. Reality
One of the most honest parts of the conversation was Lauren’s reflection on how her own thinking has changed.
Earlier in a design career, it is natural to want everything to be elegant, complete, polished, and deeply considered. That instinct is valuable. It creates standards. It pushes teams beyond mediocrity.
But leadership requires a different kind of judgment.
Sometimes speed matters more. Sometimes a business constraint matters more. Sometimes the right call for the company is not the designer’s ideal recommendation. Lauren described moments as a leader when she had to make decisions against her team’s design preference, not because the team was wrong, but because other constraints had to win.
That is the maturity curve of design leadership.
The goal is not to abandon craft. The goal is to know when craft is the decisive variable and when it is not.
The Real Job of Design
The through-line in Lauren’s career is not just design excellence. It is systems thinking.
FuelBand required understanding the relationship between a device, an app, and real human movement. Nest required turning overlooked household objects into intelligent, trusted products. Matter required thinking about how devices communicate across ecosystems. Google Health required building consumer UX in a deeply sensitive domain. SoFi required scaling design across a complex financial platform.
In every case, design was not decoration. It was the connective tissue between technology, behavior, business, and trust.
That is the real lesson for founders and product leaders.
Design is not what happens after strategy. Design is one way strategy becomes real.
It is how a product explains itself. It is how complexity becomes usable. It is how teams make decisions visible. And, ultimately, it is what customers experience when all the internal debates, documents, meetings, trade-offs, and intentions disappear.
The customer never sees the process. They only see the product.
👂🎧 Watch, listen, and follow on your favorite platform: https://tr.ee/S2ayrbx_fL
🙏 Join the conversation on your favorite social network: https://linktr.ee/theignitepodcast
Chapters:
00:01 — Introducing Lauren Von Dehsen
00:48 — Lauren’s Origin Story in Design
01:25 — Choosing Design Over Math and Science
02:56 — Discovering the Design of Everyday Things
04:31 — The Product Lauren Is Most Proud Of
05:43 — Joining Nest During the Google Acquisition
06:48 — Why Nest Changed the Smart Home Market
08:11 — The Timing Behind Nest’s Breakthrough
10:28 — Design the Product, Not the Documentation
11:21 — Why Great Concepts Often Never Ship
13:14 — Taking Ownership of What Customers Actually Use
13:40 — Designing Across Hardware and Software
15:09 — Inside the Secret Nike FuelBand Project
16:27 — Asking the Questions Nobody Had Answered
17:21 — Designing Before and After Figma
18:01 — From InDesign Specs to Collaborative Design Tools
19:56 — How Figma Accelerated Product Design
21:16 — How AI Is Changing the Design Landscape
22:19 — Why Prompting Is Harder for Visual Work
24:15 — Claude Design, Noon, and the Future of AI Design Tools
25:20 — Why Design Needs More Than Words
26:13 — Lauren’s SoFi Chapter
26:30 — Leaving Google for a Faster-Stage Company
28:03 — Why New Problem Spaces Create Better Design Thinking
29:34 — Joining SoFi Right Before COVID
30:27 — Building a Mature Design and Research Organization
31:11 — Designing Across Banking, Loans, Investing, Crypto, and Insurance
32:04 — What Founders Get Wrong About Design
33:19 — When to Use Familiar Patterns vs. Diverge
34:26 — What Nest Got Right About Design Culture
35:21 — Trusting Designers to Make the Final Call
36:24 — Moving Design From Execution to Strategy
37:54 — Applying “Product, Not Documentation” to Design Leadership
38:21 — Rituals, Reviews, and Scaling Design Teams
40:10 — Thread, Weave, Matter, and Smart Home Interoperability
41:23 — Designing for Devices That Need to Work Together
42:17 — The Most Common Early-Stage Design Mistake
43:32 — Bringing Designers Into the Conversation Earlier
Transcript
Brian Bell (00:00:56):
Hey everyone, welcome back to the Ignite podcast. Today we’re thrilled to have Lauren Von Dyson on the program. She spent 15 years at the intersection of hardware, software, and human behavior, designing products that people interact with every single day without thinking about it. She shaped the UX of the Nike Plus Fuel Band, very cool, when wearables were still a bet. Helped define how smart home devices talk to each other at Nest, very cool. And then informed the Matter Protocol now adopted by Google, Apple, and Amazon. Built Google House Consumer UX Org from scratch. and then spent six years scaling SoFi to a 100-person design and research operation. And the list goes on. Thank you so much for coming on, Lauren.
Lauren Von Dehsen (00:01:34):
Absolutely. Thank you so much for having me.
Brian Bell (00:01:36):
Well, I’d love to start with your origin story. What’s your background?
Lauren Von Dehsen (00:01:39):
I come from an industrial design background academically. I grew up in New York. Maybe that’s also helpful to hear. And I went pretty quickly into technology and software development following graduation. So it was a great entry point into the world to kind of know that I wanted to pursue design much earlier than I find some of my colleagues knew that and getting kind of a head start into the space.
Brian Bell (00:02:01):
Yeah. So what was the aha moment where you’re like, I’m doing this. I’m doing the design thing.
Lauren Von Dehsen (00:02:06):
Well, I’ve been credited as a very deep and sometimes overly deep thinker. is maybe the best way to say it and going into my college search I was coming from a background academically that was very strong in math and science both of my parents worked at IBM and were in various forms of engineering and project management but I had this kind of lucky extra context that my aunt and uncle had gone to Parsons and were both graphic and industrial designers and had been pursuing that career and I grew up around that and got to see what they were doing so I’m kind of a product of my environment and circumstances but when I was looking through colleges and trying to really be thoughtful about what I was going to pursue I found that as much as I loved the academics of math and science and learning it and studying it I couldn’t see myself being as excited about the careers I understood that would lead to which wasn’t necessarily all of the opportunities but the ones that I had on my radar And when I thought about the times where I was doing creative pursuits, whether that was alongside my academics or during the summer, I found that I had a different level of passion and interest. And so I’m very fortunate that it kind of all came back together and I actually used both sides of that. But I didn’t know that when I was pursuing it and took the leap of what felt like a very risky leap to go down the design path.
Brian Bell (00:03:25):
Yeah and I didn’t really even get exposed to design until I became a product manager right and I came into product management from marketing and so I was even maybe in marketing a little bit with landing pages and things like that and email layouts, but really it was like product management. I was like, oh, there’s this whole like world of how things are made. You know, I think one of the first design books ever was Design of Everyday Things. Yes. It’s just such a great book. Classic. How are doors, you know, like doors designed, you know, like you could have a knob and you can have a plate and you can have a bar and like what are the different reasons for those different affordances, right? To open and close doors and you just learn this kind of stuff.
Lauren Von Dehsen (00:04:04):
I think it’s a real eye opener at least for me I think I had this moment and I can’t quite place maybe what age it was at but I had this moment where I went wait a minute everything around us somebody made a decision about whether it was an intentional decision whether it was I’m what’s a product that you’ve worked on that you’re just really proud of that you look back and you’re like that was my best work I have a soft spot for anything that that I put hours into, right? Because like anyone that works in the tech space, you know, you really invest a lot in making these products. I think the one that always, the chapter that always stood out the most to me was the Nest product suite because they felt so substantial and monumental and there’s a level of excellence that the team and the company really committed to, particularly in the early years and the era.
Brian Bell (00:05:27):
Before Google acquired them, yeah.
Lauren Von Dehsen (00:05:29):
Well, I joined right in the midst of the acquisition. There was a pretty big hiring spree, right? Because with the backing of Google, there was means to do it. But I like to say, I think when I joined, I used to think, how do I make people think that I was here before acquisition. I want to know all the, you know, the details and make sure that I know this as best as I can. You know, I think that was out of just a love and adoration for what the initial early team had done and wanting to continue that forward as we expanded into what, you know, was kind of the height of the product suite that Nest put out across HVAC, smoke detectors, cameras, security, doorbells, etc.
Brian Bell (00:06:07):
And so... Talk about the design of everyday things. I mean, you know... Very everyday You know smoke detectors
Lauren Von Dehsen (00:06:15):
the things that I think before that era, you wouldn’t even have really spent much time or energy thinking about. And now they’re, you know, these somewhat high tech tech devices. And I think there was just such a beauty and excellence and attention to detail that the Nest team was able to deliver. And it was something that was just a standard that was held across every function, everyone on the company, no matter what they were contributing to the success of it. And so when I think of those products, I just think of them so fondly because um it just felt like the team was firing on all cylinders yeah and everybody knows
Brian Bell (00:06:49):
and loves Nest products if you know it’s a great interview question actually you can you know ask a product manager or designer you know tell me about your favorite product right and why you love that product and a lot of people love their Nest products what do you think it was about kind of the timing of of Nest I think about this a lot as a VC we care about timing a lot you know like I wonder like what year was it founded like 2009 or 11 somewhere in there yeah you have the right hour I go somewhere in there you know and I often think about this as a VC like if the Nest founders you know sent me their pitch deck or you know they would probably get an intro hopefully get an intro would I invest right around you know what do you think it was like looking back because up until that point we were used to kind of you know the oddly shaped plastic box thermostat that was just what it was is the Honeywell or whatever it was and that’s just how they worked it’s like they had three ugly gray buttons and it was like this yellowing box that hadn’t changed that much but we got a little LCD display you know whereas before it was like you know the stuff that we grew up with in the 80s or whatever what you know what do you think it was about the timing where like Nest could succeed when it did how it did
Lauren Von Dehsen (00:07:59):
I’ll give you my perspective obviously there are some that I could really tell you the facts in a way that, you know, they firsthand lived it. I think with something like that, you have this kind of perfect storm of components. I think there was a realization that technology, both hardware technology and software technology, were getting to a point that made some of the technical components possible. What I mean by that is, you know, the guts of the first thermostat, the way that I I’ve always thought about it was it was really a more rudimentary cell phone and because we had many generations of the iPhone never mind the fact that the people starting Nest really knew those products intimately you know they could carry that over almost seamlessly into a different I’m phases of technology or themes in the industry. There’s this catalyst of like something made it possible. And then you have a team that’s interested in a particular problem that’s well suited to what the technology is allowing. I think with the early days of Ness, my understanding of it always was that there was such a push on the environmental side because the thermostat in particular had such a connection to how we use energy and power in our homes and that I think struck a chord with conversations that were going on and what was out in the world that people were starting to be wise to and interested in doing their part and so that’s where yeah the technology is the enabler but then you have these other maybe additive pieces that when all happening at the right time give that great environment for something to pop up like nested
Brian Bell (00:09:56):
And I guess everybody had that, you know, perfectly crafted iPhone experience around the same time, too. And you’re just expecting things to, you know, feel great. And the thermostat definitely did not until this came along. You published a piece called Design the Product, Not Documentation. do you recall that paper and like what the core argument was yeah it was a long
Lauren Von Dehsen (00:10:15):
time ago and I was very early on so I think part of my motivation to write was to just organize my own thoughts and learnings and how I was approaching design in the early years of my career but that was particularly an insight I think partly driven from hardware development it might have been written more in the fuel band era than the nest era but same you know same general idea and what I realized was that a lot of designers would be really proud of the concept that they came up with and the thing that they had shared with their team and a really innovative idea but the amount of those that make it to what actually ships as far and few between kind of by nature of what we do. And what I started to realize was that, yes, I needed to make documents and specs and I needed a way to communicate with engineers and team members to express my ideas, but that It kind of didn’t matter what was in that file if it didn’t actually make it into people’s hands. And what it took to make it into people’s hands was explaining myself, you know, 10 times more than I thought was necessary and double checking my logic five times, even though I was pretty convinced it was the right call. There were new pieces of information that kept making me have to rethink a decision that I had made weeks ago or spending hours just you know bug bashing which of course is such a standard thing we all do today but we were you know learning how to do that on mobile apps and in more interesting platform environments that we hadn’t had before and we were learning how to do that across a hardware device and an app that spoke to each other which was kind of a harder thing to wrap our heads well how are we going to test this we had people in the fuel band days we had people running up and down the staircase the emergency staircase in the office building trying to figure out how to get some points on the band so when you’re making something that doesn’t I think the motivation behind that piece was, as a designer, this is my problem too. I can’t just sit on my laurels that I made the screens and I made the flows and I gave it on time so that nobody downstream of me was held up. I have to have ownership in what actually makes it into the customer’s hands because that’s the only thing they’re ever going to judge the product on.
Brian Bell (00:12:35):
Speaking of FuelBand, you were at RGA. Do I have to say Slash?
Lauren Von Dehsen (00:12:39):
No, no, no. RGA is correct.
Brian Bell (00:12:41):
You know, there was this moment you’re working on a connected device. Nobody knows. And this is kind of a recurring theme in your career, I guess, which is kind of this hardware software integration. How down into the industrial design are you going versus staying at the kind of the software layer?
Lauren Von Dehsen (00:12:55):
I always worked with industrial design teams. I never practiced industrial design professionally, even though that was my kind of degree origins. And so the scenario would, it would be different on different projects. If the device had a lot of buttons and direct interaction on it, there might be more reason to collaborate in those early phases versus a device that maybe was more simplistic and we had to just make sure enough of the pieces of hardware were correct that would give us flexibility down the line of the the project lifecycle to determine how the software would use that hardware. So I would say it was pretty sliding scale depending on the type of product and the specifics of what that needed.
Brian Bell (00:13:36):
What was that like working on the fuel band? I mean, that was one of the first connected devices and guessing you had to bring your design the product, not documentation mindset into that.
Lauren Von Dehsen (00:13:45):
Yes. Yeah. I came into it. The project was already kicked off and I joined the team a midway towards the first launch so it was totally secret I was exposed for the first time to like a locked down environment where we have to go through multiple
Brian Bell (00:14:00):
layers of security to get to the devices and things like that that’s right exactly
Lauren Von Dehsen (00:14:05):
it was just it had so much allure around it that I think I was just you know taken by like oh my gosh I can’t believe I’m in here and getting to see how this how this happens and then you know you get into the project and again this is pretty early in my career I might have been like designer senior designer at best at that point you get into the project and you think okay all these like super smart people have worked through all of this and they’ve already been on it for however many weeks if not months and I just need to like do what I can to help and plug holes and then you start running into things like any product development right which you know I was naive to at the time where we didn’t we never talked about how that thing was going to work which just kind of either been overlooked or it’s just working right now as the assumptions that were made along the way as an output of everything else that was decided. And I started to realize that, you know, I was kind of just assuming somebody knew better. And one of the things I think clicked for me was, no, no, no, no, no, just assume nobody had the time to think about that and that it just went under the radar and you’re better off asking the question and finding out there is an answer than or obscuring it or just sitting on it thinking somebody knows this. And so I found one of the things that was really great is that the more that I asked and the more that I poked, the more I realized how new everyone was to it. It didn’t matter their years of experience. The problem space was so new and we didn’t have patterns for it. We didn’t even have some of the technology setups we needed to really be successful. And so you have to kind of design the tools and the process alongside the product itself.
Brian Bell (00:15:41):
So you’ve been a designer, what you might call before Figma and after Figma. How did that change? I remember when that came out and I like what a sea change that was for me as a PM.
Lauren Von Dehsen (00:15:52):
Yes.
Brian Bell (00:15:53):
In getting the spec of the design, speaking of design the product, not the documentation, to the front end devs, right? Yes. And now you’re basically communicating HTML and CSS. Yeah, pretty much like pixel perfect. What was that like? Because I remember like, you know, back in 2013, we’re using like envision clickable like images, clickable, basically images from Adobe.
Lauren Von Dehsen (00:16:17):
Yeah, I couldn’t even do one better. I think my first design documents were created as if I was making a physical book in InDesign. and then at some point I’d have to print them out and it would be like 150 page stack of paper and what was on which page was kind of a choose your own adventure inevitably an engineer would come and say do you have an answer to this I said oh yeah it’s on page 39 didn’t you see it of course they didn’t see it that’s a
Brian Bell (00:16:44):
freaking textbook
Lauren Von Dehsen (00:16:46):
So it was really like a make do with what you have kind of environment. I think when, you know, Figma came around, we were all trying to wrap our head. If I recall correctly, we were all trying to wrap our head around sketch because that was kind of its predecessor and made this leap to the idea that there could be actually a tool made for this type of design. And we don’t have to just repurpose the tools that are out there for other flavors of design and other media products. in terms of like a Photoshop that would optimize more for imagery and print at the time. So it was really interesting, but I think there was this kind of like, you know, like anything and quite honestly with any other software platform that comes around that we use as technical teams, you have this moment of like, is the migration worth it? Is it worth us all stopping and figuring this out. And so I think there was a lot of mixed yes and no’s on Sketch and trying to figure out what it would really get us, but a lot of people very excited about the potential. And what I remember is Figma just came in on the heels of that so quickly and just had enough of the pieces that were missing, the cloud hosting, the comments, the ability to really collaborate through the tool and not just be in this endless versioning and file upload type of situation. And that was just such a game changer And then I think from there, you know, I think it’s allowed the discipline to mature Because Figma came along at the time where we started to have some ideas around the best way to handle mobile devices And we started to have some ideas on the best web practices And we coalesced on patterns that prior to that we were all trying all different things in each product And so Figma being able to be a shortcut to some of those patterns and ability to not have to spend time on what at that point was the easy stuff and get to really just spend time on the core of the product and the functionality unique to that product. I think it was just a huge accelerant. Now, the challenge on my side is by the time Figma came around, I was more and more and more in a management role. And so I’m really good at commenting. and I’m really good at breaking some people’s files to make a quick edit that I’m trying to communicate. But it is amazing how quickly, you know, you have to really keep up with the tools and learn the tools if you want to stay in it. And something that I’m now looking at, you know, with the new landscape, well, which tools do I want to start learning alongside everybody and not necessarily have a disadvantage there?
Brian Bell (00:19:11):
Yeah, that’s a great segue to the next question, which is sort of, you know, how is the landscape and tools changing with AI? Is there the, you know, the open claw or clawed co-work of design out there like how is that changing how you guys do things because you can if you’re a PM you could just go I don’t know say make me an interface that does this to this and that and this other thing and I’ve done it right yes you’re like a lot of people have had that vibe code experience how’s that changing design as a as a function and are there like new tools that you guys are evaluating that you’re excited about
Lauren Von Dehsen (00:19:43):
Yeah, there’s at a minimum designers are getting the same sort of productivity improvements that everybody’s getting right because there’s plenty of things that we do that’s beyond the pixels or the screen development right that these tools are just accelerating so We’re all in it together. But I’ve been thinking a lot about it lately. I’ve been trying to use it for my own work and I’ve been trying to be more of a, I would say like an IC mindset in approaching these tools. And one of the things that’s become very, very clear to me is that when your work product, hopefully this will make some sense, when your work product was the output of keyboard keys, abstracting that to a different layer of written conversation is a pretty natural progression. It’s the type of abstraction we are used to going through as the tech world. When your output is about moving things spatially or adjusting a color, or trying to create more breathing room and white space or thinking about a sequence of things in more of a flow and a logic or animation for that matter. It doesn’t have as much of the natural abstraction to like trying to describe that in words. And so what I’ve noticed is that the tools are doing a great job of brainstorming. They’re doing a great job of getting really high quality concepts and prototypes that would have taken designers a long time to make and maybe wouldn’t have explored as wide of a set of options in the past because of the time limitations or expediency. Once you get that first thing back, when you try to start getting it closer to what you might have in mind or where you see optimizations, there’s this kind of Fatiguing element the more turns you take and the more specific you’re trying to get the AI to change it almost seems like the harder it is and so I’ve been watching and hopefully I have no preference in this. I have no personal stake in this, but I’ve been watching what Claude is doing now with Claude Design, which is in a very, very early state and has some kind of limited access to it right now. And they’re starting to use a dual interface where you can manipulate some things in line and then you can chat like we’re mostly accustomed to at this point. And I’m really interested in a company called Noon that just came out of stealth mode. It seems like most people are waiting on the waitlist. We’re not sure if anyone’s gotten access just yet, but similar in thinking about how to bridge kind of what a designer needs to where some of the rest of the tools are going. And I’m sure there’s more. I think even I haven’t gotten a chance to go into depth, but I think even Figma made an announcement in the last 24 hours. So I’m hopeful that this is all just a matter of time and it’s just sequencing and what the teams can get to. But it’ll be interesting to see how the tools kind of address a more maybe specific and unique type of working style that a designer brings to the table than some of their cross-functional peers.
Brian Bell (00:22:44):
Yeah, I guess you could say that Figma was kind of the culmination of Web 2.0 tools, right? interactive collaborative user-generated stuff that’s in a web interface and we clearly have not reached the culmination and peak of AI co-pilot driven design yet maybe it’s cloud maybe it’s something else but something will come along where it’s like okay and I’m reminded based on what you said earlier about you know a picture is worth a thousand words you know the old cliche right and a design is kind of worth it’s you know a thousand words too and a video walkthrough is probably worth ten thousand words let’s talk about your SoFi experience. You were there for a long time. Are you still there?
Lauren Von Dehsen (00:23:21):
I just stepped away at the end of March.
Brian Bell (00:23:23):
Wow. Congrats. I mean, you had a very long run. You joined right before COVID, kind of broke everything down. What was that run like? Because SoFi had a really incredible run and you had your hands probably on everything there.
Lauren Von Dehsen (00:23:34):
Yeah, it was a very fast paced and rewarding chapter. I had the insight that it was time to leave Google and I wanted to go to a company at a certain size and phase. And so far was that in the 2020 time period.
Brian Bell (00:23:54):
You mean you didn’t want to go back to another big political, big tech company?
Lauren Von Dehsen (00:23:58):
It’s not where I do best. I have a lot of respect for those that do, but.
Brian Bell (00:24:03):
Yeah, I’m not a politician. That’s my problem.
Lauren Von Dehsen (00:24:05):
Yeah.
Brian Bell (00:24:06):
I say exactly what I mean and I have no filter. And so Microsoft was not a good place for me. People kind of do all the like doublespeak corporate things. And I’m just like, well, I think you’re wrong.
Lauren Von Dehsen (00:24:19):
I can relate to that I can relate to that I don’t have much of a poker face I’ve been told I liked I liked I always liked the teams that felt the level of urgency to make decisions and ship and I found that that came with like a certain stage in the company’s life cycle and yes you could experience that inside of a big
Brian Bell (00:24:37):
company if that organization is very much like that I mean Amazon felt like a startup you know just felt like a series bc startup just moving as fast as you can everybody’s like speaking their mind there’s no pot like there were politics just 10 years ago it didn’t completely different from Microsoft
Lauren Von Dehsen (00:24:54):
Yeah well that I’ve never been inside of Amazon but I could see that based on the cultural tenants so so if I met a lot of the criteria in terms of like scale and phase and it was a totally different problem space which I maybe the history you read out maybe explains I actually like switching after being in a space for a reasonable amount of time and really investing in it I like switching into a new space because I find it brings a lot of creativity
Brian Bell (00:25:21):
yeah it’s like if you’re yeah like you don’t want to sit there and design the next iteration of the thing you’ve already been working on for multiple generations I’m guessing as a designer you’re kind of like all right it’s just another version of Nest you know like great it’s a little more it’s a little more spherical now like you know ready to move on you know
Lauren Von Dehsen (00:25:39):
And the act of learning, I mean, I don’t, every designer is going to be different, but the act of learning a new space and asking all the questions is just a very creativity kind of inducing mode to be in. So the first couple of years of being in a new space, I always found very exciting.
Brian Bell (00:25:56):
Yeah. That’s why I like being a VC. Like I’m constantly talking to founders and doing new things all the time.
Lauren Von Dehsen (00:26:02):
Yes, exactly.
Brian Bell (00:26:03):
So it’s never a dull moment. It’s like, oh, like I didn’t know you could do that with like dermatology, you know? exactly I would have ever gone to YouTube and said show me like what the latest AI is like being used in dermatology you know I’ve never you know that’s right so
Lauren Von Dehsen (00:26:22):
going to SoFi was you know I had I always had interest in my personal finances I felt like they were setting themselves up to be in a spot that could really be interesting across what was a very active fintech environment in 2020. Yes, going just, what, six weeks before we all ended up at home was a very strange and unpredictable circumstance. I was very fortunate to meet people in the office before that started because I think... Yeah,
Brian Bell (00:26:47):
like a month before, yeah.
Lauren Von Dehsen (00:26:49):
Yes, just even having one moment of FaceTime was meaningful. But I think what... That chapter for me, and I’ve done a lot of reflection in the last couple of weeks in terms of stepping away, it was really about how do you create a more grown up and mature research and design organization? And I had come from these environments where people were teaching me what that meant. And I was really lucky to work with groups that were coming from environments that had worked with the best and were doing it at such a high level. And then this opportunity was like okay what have you learned and how do you put it into practice and how do you take a company that wants to grow into that and take them to the steps to do it so a lot of my role was really focused on how to build the discipline and the practice but of course how to execute and keep pace with a growing and changing company and so yeah we we spend a lot of different financial segments from banking and investment and more recently reentering the crypto space but also the bread and butter of the company historically was loans and there was a play to move into insurance so talk about you know all different concepts that some of the other fintechs in the space especially in the earlier years would have only tackled one of those and yet we were trying to tackle all of them in parallel and so a lot to wrap your head around and a lot to kind of figure out as a designer what’s shared and what needs to just be the same because you’re under one brand and one company and one app providing one experience to the customer and then what are all of the variants and specifics that the products just work different and the verticals just work different and you still have to accommodate all of that in its gory detail so it was an interesting kind of ecosystem problem to tackle
Brian Bell (00:28:30):
Yeah, as an investor, I love teams that have, you know, a builder, like a CTO kind of person, you got the CEO, the salesperson, but I love seeing a designer on the founding team. I think it’s a really neat thing when they’re, you know, thinking about design right from the beginning, or like it’s one of the first hires. What do you think founding teams and founders get wrong about design when they’re going from zero to one or one to 10 at their startups?
Lauren Von Dehsen (00:28:58):
When you’re not a designer, you’re coming to it as a founder, a cross-functional peer. It’s easy to have a definition of design that is kind of based in whatever you’ve seen up until that point. And maybe you’ve seen something really amazing and you’re trying to replicate that one-to-one.
Brian Bell (00:29:15):
You mean every startup has a chat interface now, like right down the center of their screen? Yes. Yes But for you know dogs and it’s like this interface it’s right there like see you just like have the dog look at it talk yes yes well there is no there is
Lauren Von Dehsen (00:29:32):
absolutely an art to knowing when to use the pattern that everybody is using and when to diverge absolutely I also mean it from a how does the how does the discipline function inside of the company what decisions are they making what do you task the designer with what permission do you give the designer culturally how do they sit amongst whoever else is there at that early stage it’s an interesting one it’s like maybe an engineer would say that they’ve experienced all different interpretations from their cross-functional peers but from my stance it seems like the uh the cross-functional definitions of design somehow span a wider breadth. And so...
Brian Bell (00:30:11):
There’s gotta be like a design meme out there where, you know, like you got the product managers like, But do our customers want it? And then, you know, the engineer is like, but can it scale to a million users? And then the designer is like, but is it like easy and fun to use? Right. And it’s like almost like the triangle, you know, cost scope and time triangle. Yes.
Lauren Von Dehsen (00:30:30):
Yes. Yes. And I found, you know, like I mentioned before that Nest was one of the chapters that I often go back to as just amazing learning experience. I found that in that environment, I never had to explain what design did or what why I should be in that conversation or what I had to contribute.
Brian Bell (00:30:46):
That was the differentiator of the company, right? Just better design everyday products, you know?
Lauren Von Dehsen (00:30:51):
And the way that that was achieved was that every function cared about design and every function understood that they were making decisions that were contributing to the experience and what other companies might say were contributing to the design. And the best way that I could explain that set of cross-functional partners was that anyone could argue any element of the product development. It didn’t have to be in their lane. I had plenty of people tell me what feature they wanted to see next or why the feature should work differently from a design perspective. But once you heard everybody’s point of view and you took in all the feedback and contribution, the team really trusted whoever was sitting in that seat to make a final call as a subject matter expert. So you had this constant working in the gray space, everyone working in the gray space, and then this trust that the right person with The decision making responsibility would ultimately make the right decision. And I think that was like the most maybe inspired and interesting definition of design where everybody felt responsible for it, but yet allowed the designer to make a call. Whereas, you know, I think where SoFi was in its maturation process, I was coming into a team where we want something different out of the design function and we want it to be more strategic and we want the types of results that would come from a strategic minded design team. but we’re in a situation where the way information is getting to them and the types of tasks we’re tasking them with are far more boxed in and without context and less ownership and some elements of that is oh is the team at the right seniority is the team at the right skill set mix do you have the the right people doing the right types of things like engineering there’s many many different sets of skills and jobs within a design team even if they have a design title they might not be coming to the table with contributions and a design team knows how to use them. But cross-functionally, do you know if you got the right type of person? So when you’re early stage as a founder, I think the question becomes, what are you looking for this to do? How are you thinking about it in the mix of where you’re starting? Is this something you want to make as a tenant of your company? And if so, are you appropriately finding someone with seniority and experience the way you would for other disciplines? Is this more of a means to an end to get to an MVP? It doesn’t mean that any of those are right or wrong. Does your decision match what you’re trying to achieve and what you think is important to that business and that product?
Brian Bell (00:33:25):
Let’s wrap up with some rapid fire to wrap up questions.
Lauren Von Dehsen (00:33:29):
Sounds good.
Brian Bell (00:33:30):
I hesitate to call them rapid fire they’re kind of like kind of just loose ends a loose end section so you wrote that documentation will never be seen by the user only the product matters apply that to design leadership what’s the equivalent of over documenting and how design leaders run their organizations I think the
Lauren Von Dehsen (00:33:44):
equivalent is probably the way the design leaders set up the rituals right in the same way rituals are there to facilitate work and connection and feedback and yeah exactly make some amount of predictability in what’s otherwise a very organic and somewhat chaotic process yeah And so one of the things we did a lot with at SoFi sometimes successfully sometimes was a learning learning misstep that we needed to improve was at each kind of change of scale we had to look at are the rituals still working for us or does it have to adjust is the test the team gotten too big for this format to work and so
Brian Bell (00:34:22):
being really having like design committee meetings with 30 people and I’m like oh yeah this is probably too many people giving feedback on this experience
Lauren Von Dehsen (00:34:30):
Exactly there’s a tipping point of how many people can be in an effective critique where you’re really helping each other as peers then there’s a purpose to do cross-functional reviews and do you have the right people in those meetings and has that changed from when they originally got set up because the dynamics of the company have changed with scale and evolution and so I think as a leader you have to be willing to say this is the process I like to use and I’m going to bring my expertise to the table but I also need to be watching what’s working for the team and at some point the thing I love using may no longer be the right call and does somebody else have a good idea of what we do next or have I thought about it deeply enough that I have an idea of maybe what we’ll try in the next phase but it’s that facilitation it’s like the facilitation can’t be the thing The facilitation has to be the means to the outcome that you’re really trying to focus everyone on.
Brian Bell (00:35:19):
So you worked on Matter. Maybe you could explain what that is. And it’s a rare thing because it kind of outlived your tenure at those companies and now it kind of lives on in multiple companies.
Lauren Von Dehsen (00:35:30):
The thing I worked on at the time was called Thread and Weave, and it was a protocol, networking protocol that Nest created as kind of a necessary component to how the devices were meant to work with each other. And it created a bit of a closed loop system where anything in the house could communicate over a different type of network, what we would have called the mesh network. and it was neither Wi-Fi nor Bluetooth, which like blew my mind when I got there. Somebody tried to explain that to me and I said, what do you mean there’s a third thing?
Brian Bell (00:36:01):
It’s like a whole nother radio frequency. Don’t worry about it.
Lauren Von Dehsen (00:36:04):
Exactly. And I really thought the person didn’t know what they were talking about for the first 20 minutes of the conversation and go, wait, I don’t know what I’m talking about. So it was really a fascinating project to work on. And what eventually happened is we all knew that with these home devices, locking somebody into one environment just didn’t seem like it was going to be practical over a long period of time. But when I was working on it, we didn’t know how we were going to get there. And the team that lived on with it eventually turned it into what we now call matter and I’m sure it’s evolved quite a bit but it was fascinating because it was true technology innovation and when you’re thinking about radio frequencies and mesh networks and yet part of the reason I was hired was because I had worked on the onboarding and pairing elements of the fuel band. And so I knew that it was a totally different problem when I got in, but from the outside, it looked like kind of the same design problem. And that was how my involvement started there.
Brian Bell (00:37:04):
So you’ve been around a lot of different teams and we talked a little bit about founders and setting up kind of design cultures, but what is a single most common design mistake early stage companies are making and a thing that you’d fix in the first 30 days if you went into like an early stage startup?
Lauren Von Dehsen (00:37:18):
My honest answer is I would assess and I would try to figure out what I thought maybe the bottleneck was. But one of the common things that I would imagine might be worth fixing early on would be how is the start of a project developing? It’s really easy to bring in each function at the point at which it’s obvious that function needs to contribute. But I think the best products and the best teams actually think about over communication and inclusion really, really early in a project before it’s obvious that all of those people need to be in the meetings and tracking along. And I think as a designer, especially if you have a really talented design team and really capable individuals on the team, the more context you can get them in the beginning of a project, the more that they can really be utilized in the fullest sense. And so that’s something that I tend to look for.
Brian Bell (00:38:09):
Design communities tend to celebrate process sprints, design thinking, double diamonds, qualitative panels. So you published a piece that says process is a trap and the product is the only thing that matters. That was a long time ago. Has your view evolved or do you kind of stick to that point?
Lauren Von Dehsen (00:38:24):
I think it depends. I still think some of the language we use to talk to ourselves falls flat. with our partners. I think we can be at times, and I apologize to the design community, but we can be like a little bit too esoteric about things and think that that’s going to be what makes it through when really our partners just want to know when we’re going to have the answer and if it’s going to be by the deadline they’re expecting.
Brian Bell (00:38:50):
Yeah. When will you have the design?
Lauren Von Dehsen (00:38:52):
That’s right.
Brian Bell (00:38:53):
Yeah. We need it. We start our sprint Monday and it is Friday afternoon.
Lauren Von Dehsen (00:38:56):
That’s right.
Brian Bell (00:38:57):
Yeah. And so those can you have it done by Monday morning? Yeah, like I remember all these conversations.
Lauren Von Dehsen (00:39:03):
Yes and there’s a whole other piece right where you have to set realistic expectations and negotiate about those types of things but you know I think those tools serve a purpose when it’s the ritual or the approach that gets to the conclusion or the next step that the team is trying to unlock but it’s not because they have a fancy name and a fancy concept behind it and that everybody participating in that ritual needs to fully understand it it’s because it might be the right tool for the job And so, you know, we in more recent years, we pushed really hard on design sprints. And one of the conversations that would happen internally in the design leadership team would be like, some of these things we’re calling a sprint isn’t really a sprint or it’s some other form of a sprint that we would call something totally different.
Brian Bell (00:39:48):
It could just be a block of work, you know?
Lauren Von Dehsen (00:39:51):
Right.
Brian Bell (00:39:52):
And so work.
Lauren Von Dehsen (00:39:53):
so I mean they probably they’re probably sick of me saying this but I said look right now all of our partners understand what a sprint is and they are bought into it and they’re seeing the results of it. And we want to keep doing these. Now is not the time to get technical about the name and which variant we’re doing when and why this is fit.
Brian Bell (00:40:14):
Do I have to work faster and sacrifice quality in a sprint? Designers are like really thinking it through, right? Yes. What is the essence of a sprint? Let’s like talk about it.
Lauren Von Dehsen (00:40:25):
Yes we like to we like to noodle on those details and that is part of what we do but when misplaced it can be counterproductive and so I’ve just never subscribed so much to the precision of the names and the kind of on paper process and it’s more about which thing is going to facilitate what we need in the moment and try to be a little bit more organic and flexible with the process What’s something you’ve
Brian Bell (00:40:50):
changed your mind on that you like used to believe that you no longer believe or vice versa
Lauren Von Dehsen (00:40:55):
That’s a good one. I think when it comes to design, I think that I’m a little bit more understanding and flexible to meet the business where the business is. I think when you start out in design, you want everything to be at the most resolved, beautiful, elegant,
Brian Bell (00:41:16):
thought out. The further you go from the code through design, through product, through the rest of the organization, the messier things get. yes you know like up here in the business world it’s messy you know lots of politics and different product lines and different you know just all kinds of different constituents and different needs and functions absolutely a little bit more pure design is like you know the the physics of products right what I mean by that is like mathematicians kind of shit on physics people and vice versa like you guys are like this is how things work and this is like and then and then along come the coders and I know this is like math it’s pure it’s code right and it’s never heard it put that way but I follow you I follow you I just this is what I do I just come up with stuff on podcasts and I get paid for it I guess now
Lauren Von Dehsen (00:42:08):
Yeah but yeah I mean you start out in design wanting to make the world beautiful right and do the best you possibly can and it’s not to say that that part of my opinions changed but what’s appropriate for the problem being solved and where is the perfection, maybe a necessary trade-off to efficiency or speed to market or some other thing that’s going to be highly critical and important to the product and the business success. And I think I had a really early awakening to that that kind of started the path of changing my mind when I started managing where there were times I had to make a call against my team’s recommendation. And it wasn’t because I didn’t understand the team’s recommendation or they weren’t. Well reasoned in the recommendation but I was responsible for working cross-functionally to understand how that stacked up against other constraints and requirements and sometimes a different requirement had to win out and so it is interesting to have to kind of learn that lesson and then once you do find a way to apply it where you’re not losing your standards or expectations but applying it at the right times.
Brian Bell (00:43:19):
Yeah. Well, that was a really fun conversation. I learned a lot and really enjoyed it. Thanks for coming on.
Lauren Von Dehsen (00:43:25):
Absolutely. Thank you so much.
