S02E04: Jerome de Lafargue
The importance of design at an early stage
This week I drop anchor at my desk and wander over to have a chat to zeroheight’s CEO, Jerome de Lafargue. Jerome started out life as an engineer before co-founding zeroheight to try and solve the problems between designers and developers. In this episode, he talks to me about the importance of design in an early-stage startup, how design systems helped him move faster and where he sees the future of designops going. Let’s set sail.
Show notes
The Transcript
Luke: So Jerome, I suppose, for those who don’t know zeroheight, it’s probably good to start with where did zeroheight come from and what is it that zeroheight is trained to do?
Jerome: So in terms of where it comes from, my co-founder Robin and I used to work at Bloomberg together, that’s where we met, we were both software engineers and we both had the feeling that we wanted to not necessarily stay at Bloomberg for another 10 years. And we wanted to start a company, we had friends that had done it and it seemed like an exciting thing to do. And we also went to, like start-up hype events in London. So Y Combinator startup school makes you feel like that is the thing you should be doing. And so eventually we, took that leap and quit our jobs and joined an incubator which made us realize that starting a company is not about coding. Because we thought we were going to get to sit in a room, drink loads of Coke and just code all the time. But it turns out, I mean we did do that at some points, but it turns out that first few months of starting a company you just have to go for coffee with a lot of people. And I think, going to entrepreneur first, which was the incubator that we joined, was really educational for us because we didn’t know how to start a company. And it turns out there is a way to do it and it really focused us on, how do you find a problem to solve that is worthwhile? And so, in terms of how zeroheight started it very much wasn’t Hey, let’s build a DesignOps company. There was a lot of crappy ideas that we started working on, one of them was a virtual reality house viewing platform, for when you’re trying to try to rent or buy a house and actually post-pandemic, I think that makes a lot of sense but, back then it was just kind of a weird idea.
Luke: You’re about five years too early for that one
Jerome: Yeah, exactly. It kind of almost sounds unglamorous, but we just had a list of ideas that we thought we could start a business with and a lot of them just were rubbish. But one of the things that EF helped us realize is, what is your insight? What do you know that other people don’t? And one of the things that they recommended is, just think about the problems that you encountered at your jobs. So I started thinking of the pain point that I’d seen at work, at Bloomberg and the team that I was in and a lot of these had to do with the collaboration between designers and developers. And that’s where we started leaning into, UX tool space. Initially, we built a handoff tool similar to Zeplin. It turns out Zeplin had a pretty strong market share so that didn’t pan out. But that got us into this space and it got us talking to designers and developers and that’s how we eventually found out about design systems and what that was and that workflow and then realized, through research, that through having more of those coffees, that documentation for the design systems was actually a pretty big pain point for companies like big and small. And so we kind of iterated our way into that space.
Luke: And I suppose it’s really nice as well because when you folks started, DesignOps wasn’t even really a thing. It was probably at the point where it was being defined by these big companies. And yet you’ve kind of found this niche in through design systems to the point where now it’s all about DesignOps. And I suppose even though you didn’t set out to create this DesignOps company it has kind of been in the ethos of zeroheight from the beginning. I suppose going back, you’re building design tools for designers, right? And just to make it abundantly clear as well, you and Robin weren’t designers, right? You were developers solving the problems of designers. I suppose that must be a really interesting space to get into because, for any company building for designers, design is a pretty damn important thing and getting that right. And I suppose, how did you find that? Did you have any of those pain points early on building design tools for designers?
Jerome: So, I guess maybe, first of all, I, despite being a developer, had a really strong affinity for good UX by being super geeky about great products. And I love that and I recognize that. I said that was important regardless and so the kind of startups that I looked up to, like Digital Ocean, we’re like, wow, you can make DevOps actually good, like you can make a product that’s nice to use. And I always wanted to build a nice product, but then when we realized that our audience is designers, the bar I already had in my head for the quality of the product I wanted to build, just got raised even higher. So, it doesn’t mean that we had a design team there was just two of us for quite a few years, but it meant that we had a high bar for UX pretty much from the start.
Luke: Yeah, I mean, one of the things that obviously now I’m at zeroheight, but, I’ve been using zeroheight for years beforehand. And it is one of the things that surprised me coming in here is I assumed that it was built by these super high profile UX designers, just because of the experience of it. And I’m not just trying to blow, smoke up ass there. But I suppose that must have been hard to do from day one with a small team. And I suppose, were there ways that you found, not easy ways, but quick ways to do it, or easier ways to do it, to making good design efficient.
Jerome: I think we created a design system without really knowing that it was a design system out of pure necessity. Startups live or die by how quickly you learn, how quickly you iterate, so your ability to learn fast is just primordial importance and so we had this dynamic with Robin where I was working on the commercial side, like the CEO, trying to get business, trying to figure out where we were going. And in the early days, Robin was the one that was primarily building the product, but I did have this role of designer without having the label. And so we ended up having a lot of conversations around like, me being a little bit annoying about margins and titles, not having the right font size, etc, etc. And it was just slowing us down, so eventually we just agreed on and we worked with an amazing freelance UX designer called Fabien, shout out to Fabien, they built us a design system which we then implemented. And it was just some cool components and we basically just had a master CSS file, but that allowed us to go so much quicker because then we were no longer having to have all these discussions around margins. It was, cool, this is what we’re using from now on and it allowed us to iterate faster. It kind of sounds a little bit drastic but I think that there was a period of our company’s history where I think it could have killed us if we didn’t have that because we went through a phase of essentially, needing to get the onboarding right so that we could launch and make a profit, otherwise we were going to run out of money. And so during that period where we figured out we need to user test at a rapid pace and the part of the product that we were user testing, because we’re building an editor, we realized it’s kind of hard, there are some things where the quality of what you can learn is so much richer if actually picked good people for the product. And so we were like, we need to be able to iterate on the front end super quick. And we spent actually three months on the onboarding because we gave the product to people, the first one that we released and gave to someone, they had no clue how to use it. And we’d built it in a bit of a vacuum, which was a bit ironic cause you know, we’re like a design tool company, but we’d not really user-tested our product. And so we gave it to someone and they were like, I’ve no idea what to do with this. And we were like, oh shit, because we knew that our product was going to grow through users picking it up and sharing it and if users didn’t get what to do with it, it wasn’t going to work. So we needed to get that self-service motion working and that required the product onboarding to be really good. It was really important that we were able to go from the point of I have no clue how to use this to, oh, I get what this is. And it took months of iterating the onboarding through kind of rapid prototyping and the fact that we had a design system made that possible. But when I say we running out of money, we had six months, so every week where you can go a little bit faster, get that user test out, learn from it. And the first couple of iterations still wasn’t working right, so every week counts. And because of the nature of startups where you can just be able to point out where you don’t have any time left, it was super important that we could go faster.
Luke: It’s funny, cause having been in startups myself as well, I feel like design systems are one of those things that people think that they’ll get around to later. They’re like, oh, we think we know why we need one because everybody talks about them and so everybody does need one. But it feels like it’s actually quite rare for people to invest in them really early on. But as you said it actually does provide those efficiencies to mean that you live or die through that quick, rapid prototyping. How long did the initial design system take to get those initial components in so that you could start creating things quickly?
Jerome: Not long, especially cause it was a team of one, Robin building the product, you don’t have anyone that you need to align with really. So I think essentially at that stage you just need to have a well-organized CSS library and that matches the design system that our UX designer Fabien had provided and it didn’t take long because a lot of the code was there you just needed to kind of refactor it to get it into the shape where it’s standardized. But I think the thing that is kind of subtle but important is that you do kind of want to think of what do you need at each point in time, right? So when we were fresh out of our software engineering jobs, thinking of startup ideas, like doing a design system for virtual reality house viewings at that point would not have been a good idea because you’re at a point where you’re just throwing stuff out so quickly that any sort of standardization is a waste of time, but then you get to a point where you’re like, okay, we believe that this is the thing that is gonna work so let’s try and iterate fast. So, it’s just kind of thinking like at every point in time, what makes sense. And if we started building comprehensive documentation at that point that would have slowed us down, right. So the thing that we do, that zeroheight helps companies with, we didn’t need at that point. Cause it was just Robin on his own, the documentation is in his head. So, I think that is important. It’s like, you do want to start early, but you don’t want to over-engineer your design system because then it kind of defeats the purpose.
Luke: Yeah, it’s basically figuring out what it is that you actually need and what’s going to make you move faster. And what is just that, oh, this will be, this will be good to have later down the line and almost like planning it out. Did you have a sort of clear plan in your head of where it was going to go or because it was so organic did that come later?
Jerome: You know, I hesitate to say this but I don’t even know if we still have a plan right now, right? I think we’re a team of 30 people we’re growing fast, but we’re still not at the stage where we need as comprehensive a design system and DesignOps tools as the companies that we serve, we’re still figuring it out. And, that’s kind of exciting because we’re on our own DesignOps journey whilst we’re helping other people with there’s, we’re kind of figuring us out as well.
Luke: Yeah. So I suppose looking back, it’s pretty obvious the right things that you did. Is there anything that you’d wished that you could go back from a sort of DesignOps/design point of view that you could go back and go, oh, I wish we did that earlier, or I wish we did that then?
Jerome: The thing that comes to mind, I don’t want to offend anyone, but I think for us working with larger agencies, which we tried to do, wasn’t a good fit. So this is less about design systems and it’s more about, again, what’s appropriate for your stage on your design journey. I think for us, when we found a really good freelancer, in Fabien that could help us just in a very pragmatic way and go at our pace, I think that was great. And I think before that, we tried to few the things in terms of like, okay, we are passionate about UX, but we still need someone to execute and make us some designs, we worked with some agencies and it wasn’t necessarily right.
Luke: The right thing for the right time, right. It’s I suppose it goes back to what you were talking about, like overcooking and sort of over-engineering the process. You kind of feel like, oh, it’d be great to get a whole team of amazing people from this agency and to do it, but sometimes you don’t need that and it’s not the right thing for your team. So one thing it is rare for us on this podcast to have non-design senior leadership. And I know that we have a lot of people out there who are in positions of building companies who listen. So is there any advice that you’d give to other startup founders or senior leadership with regards to design within their org?
Jerome: I kinda like that you said non-design leadership, because, in a way, I would say you don’t need to have had a career in UX design or design to consider yourself as a design leader. I think in a way, that’s my advice you can be a design leader If you just care about it, and if you are passionate about it, that’s kind of how I see myself, when I was a teenager, like writing essays, I would really care about the font, a lot of people didn’t care, but I was like, oh no, it has to be like Garamond Pro because I just cared. And so I think like that affinity, it has influenced me throughout and has made me want to build really nice products and I think that I do like that the lines are blurring and I think quality UX and building great products is something that any leader full-stop should aspire to because it is good for business, but it’s also.
Luke: It’s almost like table stakes. It’s like having a good quality product these days is table stakes. You know, back in the nineties it felt like you could get away with just having really shittily designed feature-rich things. Whereas these days, Apple ruined it for everyone, in a good way, in a good way I have to say. So, obviously, being CEO of a DesignOps company, you must have thoughts about the future of DesignOps. So I’m curious, where do you see DesignOps going? What’s getting you excited at the moment?
Jerome: I think the future of DesignOps, we often look at DevOps because I think there is a strong parallel. Software engineering exploded in the 2000s, and then you had loads of DevOps companies building amazing stuff. And UX has very much exploded in the past decade. And so we think this decade is all about DesignOps. And I think commoditization is what you saw a lot in the DevOps space where we were able to build zeroheight without having to have an in-depth knowledge about how to set up a server, right? Because we just use AWS or similar platforms. And that enabled us to innovate because it enabled us to focus on other stuff. And I think the same will become true for DesignOps and design systems where in the future, I hope that Zerohight can play a part in this, but we want people to be able to innovate and focus on the problems they’re trying to solve and not how to set up their design systems in a sense giving people a lot more stuff that they don’t have to worry about and so they can start focusing on problems. For me, what that essentially means is we want the startup that starts a company in 2023, to be able to have the same tools that Facebook has, but they can get them at the budget that they can afford and they don’t have to be Facebook. They can start with those tools whatever is appropriate for that stage, but, startups and scale-ups can have a lot of that stack of DesignOps which these days is not necessarily available. They can have a lot of that from the start. And in a sense, what that will enable is raising the bar for UX because if any startup can have a lot of this commoditization and they can have a lot of the value of DesignOps, from the start then it means that products will be better from across the board. And yeah, we think that’s super exciting cause it essentially means zeroheight will contribute to the world being able to make better products
Luke: Yeah. I think as you said, it feels like the dev side of things got their stuff sorted over the last sort of 5-10 years, to the point where now you can create this amazing PWA by just installing a couple of libraries and you’re almost ready to go and it’s almost getting a lot of the stuff that you’d worry about that isn’t the core of what you’re trying to do, the core of the experience, out the way so that you can focus on actually building the thing, right? And I suppose it’s exactly the same for design, right? We need to get all the tooling and process stuff as efficient as possible and have the support for the design teams who actually design stuff quickly and get it into code quickly and have as much of that automated as possible.
Jerome: You know, I mentioned startups and scale-ups, but a lot of big companies don’t have that DesignOps stack because the people that make the financial decisions haven’t given them millions of dollars that Facebook or Airbnb have for that DesignOps teams. And so, those are the companies that we want to enable as well. If we lowered the barrier to entry, then it means that any company that wants to start investing in DesignOps can now do it with a lot smaller investment.
Luke: Yeah. That makes sense. Alrighty then, so before we cast you off to your imaginary island so that you can spend your days in peace, I mean, the life of a CEO is not an easy one. What is the one piece of music, the one piece of literature and the one luxury item that you get to take with you? Let’s start with the music.
Jerome: So, one of my favorite bands is The National, so I’d probably just take their discography.
Luke: Oh, I mean that is some proper sad boi music for an island life. I like that, as an old emo myself.
Jerome: It would just make me nostalgic for the old days where I wasn’t on the island.
Luke: And how about the [literature], are you much of a book person,
Jerome: So I have a massive list of books that I want to read. I dunno if this is allowed, but it’s a series of books that I have been recommended many times, but I haven’t had a chance to read it yet. So I’d probably bring those, I think they’re quite chunky, it’s the kind of the Three Body Problem series, which is like a sci-fi/AI series and I’ve just kinda been recommended by many people.
Luke: Great, who was the author of that one?
Jerome: It’s, I’m going to butcher this but its, Cixin Liu.
Luke: And you’ve got a luxury item to take with you as well.
Jerome: This is not original or that exciting, I don’t know if this is allowed either, but I would bring an 18-inch laptop with an ethernet cable that goes into the ground and connects to the internet.
Luke: Of course, yeah, it’s the classic sand internet.
Jerome: Yeah, because I think if you have a laptop, you can have access to so many things. So, in terms of not getting bored, I think the internet is pretty good.
Luke: I mean, what do you think you’d do actually on the island with your laptop? Would you spend your days getting back into code or are you just going to use it to play video games?
Jerome: I think a bit of both, but yeah, I mean, that’s the beauty of the internet, right? You can work, you can play. So a laptop It is.