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 kind of be more of a story than it will be like an educational thing but I hope to have some 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 marble.com webpage, 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, a 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 hand 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. Okay. Raise your hand if you've ever run into bugs on the WhatsApp web. No, just kidding, just kidding, don't do that. They're probably not my fault. They might be my fault. 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. It could still be improved, of course, but it's a world 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 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, it 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've got your sharp borders, your blocky content. Very Android 5, very Nokia phone, early, early web stuff. But with that design, we did a lot. We had over 200 million users at the time. If you had 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 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.

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 1,100th as many people as raised their hands before, which I do not blame you, because it was not very well advertised. But this is an example of some of the features that existed only because of the passion of some of the engineers working on the app.

But this is an example of 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 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. But 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. 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 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? That 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. You know, 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.

So 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 this kind of design that we largely had on web to something that much more resembled the 20th century. Went from that to that in one year.

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.

See how users actually liked it. A couple of 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. 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 code base 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.

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.

No, this is what the list item types look like. I don't know how many of you have operated in legacy code bases 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 without anyone stopping and being like, wait, what is going on with our UI component system? Super idiomatic and testable, right? I'm sure that's gonna have no bugs at all.

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's heard of that here. It's not super big. But in early 2025, it started becoming popular to ensure your code base was AI ready. Everyone's 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 code base 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 hand roll 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. This is not ours, just kind of something that you would do. 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, use this type in this case, unless this isn't the case and then use this one. It wouldn't really be maintainable. So it was with this context and with this energy that I was able to make the case for bringing WDS to web. So design systems are an AI acceleration story. That is 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. 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? You know, I have written a lot of UI in my life, but I had 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. The one that I'll call out here is the area authoring practices guide. If you're kind of new to creating accessible components and confused at where to start, WDS has good resources, but W3C has their own documentation page that is actually amazing. It has so many good examples of different components and how to make them accessible for screen reader users, for keyboard users. Super super interesting and important. 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 built text components so that the whole app could have consistent font size, kerning, line height, et cetera. 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 like 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. So we did a lot to make sure that they had right guidance around how to do that, but 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. It'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 to say yes to others. To some extent, you have to be an arbiter of that as a design system engineer.

But yeah, 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 is 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 reexamine. 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 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've been 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, you know? 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 reexamine all this stuff. Don't be afraid to enforce your design system. Lint rules scale better than launch posts. And remember the AI story.

It inherits your pattern, so make them worth inheriting.

And yeah, that's all I had. So thank you. Great.

This, 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 codebase. And it's kind of a tight rope to navigate because you don't want to be seen as like 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 preempted 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 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 like MCP do you integrate with that or? 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 like 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. Yeah. So 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?

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. You know, 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 engineer side projects, you know, that's still going to be way better 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 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 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. From there, 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, yeah. I can see how that can be the case.

So when you have the migration strategy, so this top one there, that that is about mostly about the Lint rules. Or do you have also other pieces of the migration? Yeah, it's not it's not that simple, because a lot of times the new design components will look different than the old design components. Right. Like, 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, OK, we need to make this change in our design, which often, depending on the future, requires some approvals depending on your organization. So yeah, it depends, is the answer. Yeah. Yeah.

Yeah. I think like when you're when you're working with a big, big team, then it can you 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. So we this one is mostly talking about accessibility. But yeah, maybe maybe also the overall testing approach. Yeah. Yeah. Yeah. Huge into testing, especially for design system components. We do use Wave. We will have some a lot of like a 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 of years, for a couple of 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 kind of the W3C stuff. But yeah, I know I know 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 it give a hand together for Noah. Thank you.