Creating a Design System for 1B+ Users in the Age of AI

So, yeah, thank you for the introduction. As he said, my talk will be more of a story than it will be an educational thing, but I hope to have interesting educational stuff in there as well. So, yeah, I'm Noe Yamamoto, technically my title is user interface engineer, which actually emphasizes the fact that I care about UI and I have been caring about UI for a long time. Before working at WhatsApp, I was at Squarespace doing web performance, before that, I helped refactor the marvel.com web page, which is very cool for the nerd in me. JavaScript was the first programming language I ever learned and still really the only one I know well, so kind of a specialist in that sense.

But, okay. Quick show of hands, how many people use WhatsApp here? Raise your hand, raise your hand. Okay, that's a good amount. You can always see the Americans in the crowd, those who don't raise their hands, still haven't tackled that market quite yet. Now raise your hand if you have used WhatsApp on the web or desktop platforms. Anyone? That's awesome. That's awesome.

Did anyone use WhatsApp web when it looked like this? Anyone? Oh, we got a couple. We got a lot of people actually. That's awesome. So, I think there's a lot to love about this design. You know, it's got a charm to it. You can send messages to your contacts. You can send images to your contacts, videos to your contacts.

They're probably not my fault. But yeah, this is what the app looks like today. If you go on web.whatsapp.com, you will first have a little login page and then you'll be treated with this beautiful design, fairly modern, fairly clean, you know, a lot of consistent colors and shapes. Could still be improved, of course, but it's worlds away from what it used to look like.

Did anyone use WhatsApp web when it looked like this? Anyone? Oh, we got a couple. We got a lot of people actually. That's awesome. So, I think there's a lot to love about this design. You know, it's got a charm to it. You can send messages to your contacts. You can send images to your contacts, videos to your contacts. That's about it. That's all you could really do. You know, simple as it gets.

We even supported all of the latest hit phones at the time. You've got your Windows phone, you've got your BlackBerry 10, your Nokia S60 up there. At the time, we actually used a direct connection to your phone in order to run WhatsApp web. Maybe those of you who were around back then, you remember if your phone shut off or went on airplane mode or something, you couldn't use web anymore. That was kind of a huge complaint, but it was one of the things that was made difficult by end-to-end encryption. We did eventually find a way to fix that.

But yeah, this early version of the app was developed and designed almost entirely by one person. It was the same guy who developed the WhatsApp.com marketing page. That's a real 10X developer right there. That was not me. It was before my time, but super impressive. By the time WhatsApp web came out in 2015, this is what that landing page looked like. You can see your generic Android and iPhone right there. You can see the very bluish green accents that we used for everything. Very blocky, lots of sharp corners and light tones. But you know, it's still quite pretty.

This is a slightly later screenshot when we started supporting more features like disappearing messages, starred messages, docs. This is a screenshot from 2021. This was fairly soon after I joined. You can still see that it's largely the same design as what it started out with. Things are a little bit cleaner, a little more fleshed out, but in terms of the actual design language, hadn't really changed at all. And it continued this way for a while. From 2015 to 2024, WhatsApp web kept being developed. Features kept getting released. Codebase kept growing.

All with the same legacy design language that we inherited from the first ever version of this app. You got your sharp borders, your blocky content, very Android 5, very Nokia phone, you know, early, early web stuff. But with that design, we did a lot. We had over 200 million users at the time. If you looked at any of the rankings, WhatsApp web was top 10 websites in the world. But at the scale that WhatsApp operates at, that is still actually one of the smallest platforms. We were at a time bigger than iOS. iOS is since much past us. But because of that, we had about a fifth as many engineers as the mobile clients had. And not a single dedicated designer for that entire stretch of time. Despite that, we managed to still accomplish a lot.

We even had dark mode, which is one of my favorite things. I do not like getting blinded by my laptop when I just want to go send some messages. There were many improvements that would be done to the app just as side projects more or less by passionate engineers. This is one of my favorites. This is the command palette. Raise of hands, has anyone used this command palette in WhatsApp web? Okay. That's like one one-hundredth as many people as raised their hands before. Which I don't blame you, because it was not very well advertised. But this is an example of, like, you know, some of the features that existed only because of the passion of some of the engineers working on the app. You can still use it today, by the way. Command K, Alt K. It will search for things, you know, much faster for those keyboard aficionados in the crowd.

But yeah, despite this lack of resources, we did our best to keep up feature parity with mobile. Because we didn't have a dedicated designer, we would basically be tasked with, here is a mobile design, go make it happen on web. And what that turned into is what I like to call a drawer-based design system. Many of you might be aware of this already. But a lot of our features were essentially just take a mobile screen, throw it into a drawer. Voila, you've got WhatsApp web. Here's another example of that where, in my opinion, the design does not translate super well. I can say that because I'm the one who came up with that screen. It's not my best work.

But yeah, since we were operating on tight deadlines, engineers didn't have the time or confidence to push back on designs that didn't fit web. So if a feature mock that we were implementing had a button with a slightly changed border radius or whatever, instead of just using the one we had, we would design a whole new one, because it had to fit the design mock that mobile gave us. But as the app grew, it became harder to maintain the same design language with consistency, especially as we started implementing a lot more features. Obvious things would be fixed, you know? We used the app every day as engineers, so we would fix the things that bothered us. But when you stare at a screen for your entire professional career, a lot of things you kind of get blind to. So take a look at this basic screenshot of a dev build of WhatsApp web mid-2022. On first glance, it looks fine, right? You know, it's got what you need. You're looking at a community view here with a managed groups drawer open, but the keener design eyes amongst us may be able to spot some inconsistencies here. Does anyone want to just shout out anything that they dislike about this design? If anyone want to be brave.

I heard something in the back, but I didn't hear it. Colors. Yes, exactly. You know, you've got so many different kinds of shades here. You've got how many greens? Let's see. You've got one green, two green, three green, four green, five green, different grays. Let's look at the divider lines. What's going on with that? How come these groups don't have a divider line? These groups do. This section header is gray and not capitalized. This one is green and all caps for some reason. These are buttons. What's going on with this icon size? Why is that tiny? But that one over there is big. What's clickable here? Is it obvious just from looking what is actually an interactive element of this page? Talk about accessibility. This is kind of a nightmare. How do you navigate this screen from a keyboard perspective? I could keep going on. There's a lot of things. There's no border here between the chat list and the drawer, but there is one here. So this is kind of what you get when you have designs being built up over the years by the same engineers.

Fast forward a few years, and in 2024, mobile was planning a huge UI refresh. They were going to come up with a brand new design language, new colors, consistent spacing and shape, refreshed icons, even some larger structural changes like a new nav bar, attachment tray, chat management features like filters. Over the course of a year, they updated the app to be much more modern. They went from, you know, this kind of design that we largely had on web to something that much more resembled the 20th century. Went from, yeah, that to that in one year. Meanwhile... 21st. Meanwhile, What's Up Web doesn't exactly get those benefits quite yet. We, luckily, however, did get our one designer who was super passionate about web and raised his hand a few months after the mobile refresh launched to do it for web. So you can see in this initial proposal slide, a lot of the same points that I discussed being brought up. Our refresh focused primarily on bringing the new color and icon system, but we did ship a few structural redesigns as well. This included moving the top bar to the side, now giving us a lot more room for other icons and a new navigation hierarchy.

And updated the compose box. This one, I worked on, was pretty fun to do the animations and stuff like that. So yeah, after six months of hard work, we were done. The app finally looked like something from the current decade. It matched mobile's new design and we managed to finish on a deadline. We wanted to go further. The first step was to set up an AV experiment, you know, see how users actually liked it. Couple months go by and slightly increased crashes. That was mostly the only engagement win that we could see, metric change. But at least we got a few nice tweets about it. So that was nice.

Well, on the surface, the app looked much shinier and better than before. The speedy timeline and requirement to support both versions of the app for a while meant that the UI codebase was in a rough shape. To refresh existing components without breaking old ones, we were hacking on new paint jobs to existing components, forking rendering paths all over the place. This is one of my proudest achievements. This is what the list item types look like. I don't know how many of you have operated in legacy codebases before. You might have seen this pattern. This is all of the different themes that a single component supports. And this is what you get when you have over the years new features being added and added and added without anyone stopping and being like, wait, what is going on with our UI component system? Super idiomatic and testable, right?

Now, at the same time, in another part of the company, there was a team created to solve the same problem on mobile. It was called WDS. And they were doing a lot of great work. Unfortunately, they focused on mobile. They didn't have the resources to onboard web. But some time passes like this, and this weird thing called AI starts getting popular. I don't know if anyone has heard of that here. Not super big, but in early 2025, it started becoming popular to ensure your codebase was AI ready. Everyone was talking about what it meant to be AI ready and how to get there. I was on a team that was evaluating AI's performance in our codebase and how we can improve it.

I was on a team that was evaluating AI's performance in our codebase and how we can improve it. And one of the things we would constantly see is when creating UI, it would just continue these old legacy patterns. It would just keep iterating on existing components, keep patching things, keep using the wrong components in certain places. Sometimes it would handroll an entirely new component because it just couldn't find the right one. And yeah, this just made the problems even worse.

AI repeats patterns. And if your patterns are poor, its output will be poor as well. So generally, what you're meant to do for cases like this is to teach it. You're supposed to give it explicit context files and say, hey, AI, here is my design system. Here is the components you use for each thing. This is what an example skill could look like that it might invoke when writing UI. But in our case, we didn't really have a first class set of components that we could tell AI to use, right? If we tried to make something like this, it would just be like complete spaghetti, you know?

Design systems are an AI acceleration story. But it's something to remember if you're trying to battle for bandwidth and funding for your stuff. It is core to creating good UI. You need to have an established design system. Having a clean and consistent set of components and tokens to match all sorts of features makes development easier for humans as well. Where to start? I have written a lot of UI in my life, but I've never written a design system before. I didn't really know what to do. So I read. I read a lot of things.

Having a clean and consistent set of components and tokens to match all sorts of features makes development easier for humans as well. And thus, WDS was born. We hired a great designer, wrote a team charter, created a new Figma library, and went off to the races.

Where to start? I have written a lot of UI in my life, but I've never written a design system before. I didn't really know what to do. So I read. I read a lot of things. This is just a quick spread of screenshots of different resources that I liked.

But yeah, where to start? The first place we chose to tackle was to solidify a token system. So we created variables for color, for shape, for spacing, and we defined a type ramp and font. We mixed components so the whole app could have consistent font size, kerning, line height, etc. Then we started the component work.

But yeah, where to start? The first place we chose to tackle was to solidify a token system. So we created variables for color, for shape, for spacing, and we defined a type ramp and font. We mixed components so the whole app could have consistent font size, kerning, line height, etc. Then we started the component work.

To subvert the expectation, we did not build button first. We built switch first. Then we built button. We prioritized by combining essentially the matrix of most divergent and most used. Because we wanted to sort of prioritize in such a way that we could have users make immediate value out of it. At one point we had so much excitement around the project that other engineers were coming up and asking how they can help.

And that is a very awesome thing, but it can also be a very dangerous thing. Because if a developer doesn't have all this context around how to make clean, well-tested, accessible components, you can end up in a situation that's not much better than where you started. We did a lot to make sure that they had the right guidance around how to do that. We were able to get a bunch of component contributions, we called it a Contributhathon.

After building a component, we would hunt down every legacy version of it in the code base and add a lint rule against its usage. I obviously didn't have the bandwidth myself to migrate every single instance, but by adding a lint rule I could be reasonably confident that over time, the legacy component usage would go down, the proper WS component usage would go up. That's not uncommon for engineers trying to hit a deadline to try to make small tweaks to your component so they can fit their use case.

But as a design engineer at a large company, you kind of have to be a little defensive. This is something that I learned, you can't say yes to everybody. You have to kind of take a stand and know that you have the authority to say no to certain designs and say yes to others. To some extent you have to be an arbiter of that as a design system engineer.

Fast forward to today, over a year in, and WS is a mature library serving the vast majority of services in the app, used over 60% of frontend files. Journey's only 1% finished. There are still large components we'd like to build, like the list item. Haven't tackled that one yet, but get excited for that. And UI patterns that we'd like to re-examine. We'd still like to refactor a lot of things to go away from that drawer-based design system and actually utilize the large screen that we have. We've started doing that.

Maybe some of you have used the new media hub that we have in the app where you can view all the media that you've sent across the entire app. That's an example of that. But yeah, I'm super happy with what we were able to achieve. And in closing, yeah, beware death by a thousand small tweaks when you have a codebase as big and as old as ours. If someone is not there holding the bar for quality, quality will not exist. Everybody wants a cleaner codebase. Just show them how to get there. A lot of people know that the codebase situation is not great, but they're pushed to make features. They're pushed to deliver things on a deadline. They don't necessarily have the time to kind of go and re-examine all this stuff.

Don't be afraid to enforce your design system. Lynch rules scale better than launch posts, and remember the AI story. It inherits your patterns, so make them worth inheriting. And yeah, that's all I had. So thank you. Great. This, uh, would you think it's possible to grow a design system bottom up and community-grown when there is a lack of governance within a company? It's more administrative. Yeah. Yeah. I think that's a really good question. A lot of what I've learned in this process is the administrative stuff. How do you navigate within a huge organization? To the question of whether it's possible, I do think it is. I think that you have to have enough sway, though. You have to be in a position where people respect your design opinion and your understanding of the code base, and it's kind of a tight rope to navigate, because you don't want to be seen as the overly strict tech lead who won't let anything go unless it passes his super high bar. But you have to have some amount of that, I think. Yeah, cool. Okay, thanks. So another one is making the UI AI ready. So when you were mentioning you're working with some kind of guardrails there or trying to get it working, I saw also a skill there. Maybe you can talk a little bit about that? Yeah.

Yeah. I have a lot to say about this. I think it's a really big topic. I think fundamentally, having a context file, a skill, or even a rule that the LLM can read that is evergreen, that's up-to-date about what your design system has, I think is really important. I'm interested with using kind of like an MCP tool or a CLI tool that the AI can ask. So it can say, like, hey, I want to build a button and it's green. What are my options? And the output will be, use this exact component with these exact types, and here is the prop list depending on what you're trying to do. So I think the more you can kind of speak AI natively, the better outcome you'll have. And the other thing on that is UI verification. I won't get into that here, but make sure your agent can see the app that it's working on.

Yeah, cool. Okay, so just in the same kind of like AI space here, is there anything about MCP? Do you integrate with that? Yeah, I think I kind of just answered that. We do have some tools that AIs can use for that. I think it's mostly just context files, though, really, and then understanding those context files. In terms of more rich features and tools, it would be the UI verification. There's also a review stage check, where we have like a design reviewer who will be spawned whenever a PR comes in that affects UI, and it'll kind of judge that based on the criteria that we gave it. Nice.

And for the design system team, is there like a dedicated team for that? Or is there some kind of shared ownership among teams? Just also like organizational? Yeah, I think it's going to depend on your organization. I, obviously, being a design system engineer, would like a team. I think that if you have a team that can care about this stuff full time, especially with a designer, that's going to be the best outcome. But you don't always have the funding for that. You don't always have the scope for that. And in those cases, I still think it's worth building a design system and advocating for it, even if it's just a couple of engineer side projects. That's still going to be way better than the situation that we were in before. Cool. Nice.

Yeah. So also kind of in the organizational aspect, I mean, you were talking about lint rules and how to enforce that people use these design systems. Someone was asking, what are the deprecation roadmaps? So how do you actually deal with that when you want to phase the old one out and phase the new one in? Do you actually have anything that is guidelines on that? Yeah, that's a good question. I've made mistakes here. I first started with an error and then got a lot of people upset at me because I introduced thousands of new errors to our code base. So don't do that. Definitely should start with a warning. And if you have the time, you should spend the effort to migrate as much of the code base as you can yourself. Now that's not always going to be possible, but that's obviously the best situation. I think exact timelines are going to depend on the velocity your team works at, how much time you have for better engineering goals, stuff like that. But yeah, I can see how that can be the case.

So when you have the migration strategy, so this top one there, that is mostly about the lint rules or do you have also other pieces of the migration? It's not that simple because a lot of times the new design components will look different than the old design components, right? That's kind of what makes it hard. In theory, you could just go and code mod everything and have all of it migrated from day one. But when functionality differs between what the old overloaded component supports and what your new one supports, you kind of need a human in the loop there to go and say, okay, we need to make this change in our design, which often, depending on the feature, requires some approvals, depending on the organization. So yeah, it depends is the answer.

Yeah, I think when you're working with a big team, then you have a lot of different things that are a lot of different approaches and a lot of different ways to deal with that. For the testing approach, this one is mostly talking about accessibility, but yeah, maybe also the overall testing approach. Yeah, yeah, huge into testing, especially for design systems components. We do use Wave. We will have a lot of e2e tests, more or less, screenshot tests, all of those sorts of things to try to enforce that. We were also lucky enough for a couple years to have a dedicated accessibility QA person who's really great. He was working with us every component we shipped to make sure that it matched his really high bar, and he's who taught me a lot about the W3C stuff, but yeah, I know not what this talk is about, but accessibility is hugely important, especially for design systems. Great. I think that's all we have time for today, but yeah, thanks so much to Noah. Give a hand together for Noah. Thank you.