Amazon's recipe for design-to-dev harmony at scale
User Stories
Elliot Tu
Nov 2023
Managing a relentless design-to-dev pipeline and leading a UX team within a massive organization is no easy feat, but Adam Warner, Principal UX Designer at Amazon, has been pulling both off for decades.
In our recent webinar, he was kind enough to share his experience and insights with us, detailing how his four-person design team at Amazon supports hundreds of developers and external partner teams.
How does he do it? By being super critical about his team's design-to-dev workflows — and by using Zeplin to bring his team's workflows together across the product development cycle. Because in his experience, when you need to communicate design changes to 200+ people and 10-15 devs per project, "you cannot scale that conversation" using just Figma.
Here's a preview of our session:
Here are the biggest highlights from our session with Adam:
1. Intentionally moving from messy to structured
He emphasizes the need to acknowledge the early-phase work of designers — which is often messy, flexible, and focused on iteration — but then also intentionally integrating it with the work of developers, who need structured, reproducible methodologies to work efficiently.
2. Creating a open-door policy
He institutes an “open-door policy” that nurtures continuous, proactive communication between designers and developers. An essential part of that effort is documenting the full history of all important design decisions for the product — Zeplin’s version-control features playing a huge role in that.
3. Smart use of tooling to avoid constant ad hoc syncs
He unites his designers and developers around a single source of truth in their shared workflows so they’re not wasting time having side conversations and meetings to clarify design intent. For them, Zeplin is their “core point of unity” — its organization and communication features give them the structure and scalability they need and can’t get in Figma.
Zeplin helps create hierarchy and focus that's hard to maintain within design software alone. It auto-updates screens and tracks changes, making it a valuable tool for maintaining an organized workflow. With Zeplin, we can streamline the design-to-dev workflow, promote efficient communication, and save both time and money.
Adam Warner,Principal UX Designer at Amazon
4. Having his designers join code reviews
By taking the unique step of including designers in code reviews, he identifies and resolves discrepancies between the design and implementation sooner — saving time and resources by avoiding last-minute changes.
Interested in more of our chat with Adam? Check out the full transcript below or access the full recording here. 🎥
Tools like Zeplin are not an option for our teams; we have to have that level of communication and final handoff and specificity. Because — if we don't — there's absolutely no way we could support this many partners, this many people internally.
Adam Warner,Principal UX Designer at Amazon
You can also see for yourself why Adam swears by Zeplin in his design-to-dev workflows by requesting a demo or joining an upcoming live Zeplin group demo. ⚡
Transcript:
Adam Warner:Yeah, you can kind of see that I call myself the grumpy old man in my group at work. That's because, as you can probably tell, I've been in design for a long time—20 years, to be exact. The first 10 years were closer to something like print design, traditional graphic design, and then about 10 years in UX. So yeah, three major corporations, and I'm very comfortable working. I would say I'm more comfortable working at a massive company than I am at a small company. I've definitely learned how to navigate corporate structures.
Yeah, that's been fun on occasion. I'm also a certified Scrum Product Owner, so I have a lot of experience going through the whole agile process—doing backlogs, sprints, running sprints—all the typical things that a Scrum leader does. Now, the coding section here, Elliot, I always feel a bit reluctant to even list this here. The way I like to put it to the engineers on my team is that I know enough code to completely screw up everything. It has been helpful, by the way, in communication with engineers and the development team. But yeah, it's been a number of years since I've actually sat there and run through the code with my team.
So, as far as tooling outside of the coding sphere, when I first started, there wasn't much for UX. There really just wasn't much there at that point in the industry. Honestly, it sounds kind of ridiculous to say these days, but we were using a lot of Photoshop and InDesign. There were all sorts of early tools, if anybody remembers them, like Justinmind and Balsamic, which was a popular solution. It was really pure UX, a lot of whiteboarding, a lot of low-fidelity stuff. Balsamic is still pretty good for that, honestly. But I was prototyping in Adobe InDesign, using it for its Flash export capability. Pretty interesting. Then Sketch came along, and it was like a huge breath of fresh air, amazing. And then, of course, had a second wind of that experience with Figma. So these have been the major revolutions, right, in the UX tooling space.
Especially as someone who has worked somewhat on the coding side, I've actually worked on design. I think I've told you this before, Elliot, I've worked on the side of actually doing the design and then having to be an engineer on the same project and then consume my own designs.
At the phase that Sketch had come out, we weren't quite to Figma yet, and then Zeplin came out of nowhere. That was really a revolution because it was the first dedicated handoff designed to dev handoff that I had used or encountered. It was just a significant improvement across the board. Literally, nothing like that existed, and it really allowed, maybe if somebody has an engineering experience in the room, they'll understand this.
But I'll give you a very simple example, Elliot.
I used to do a bunch of SVG exports for a particular app I was working on, you know, SVG file format. I would export those straight out of Sketch back in the day. For anybody that has tried to consume an SVG or call an SVG that has come out of Sketch, you get all sorts of garbage code in that. It wouldn't even render on the engineering side. So running that exact same thing through Zeplin, just one of those neat little features that's in the background. You guys don't advertise it that much, but it's one of those things that you should. You actually should. It runs it through an SVGO compressor. Which typically is a separate thing you have to do, and so it automatically does that. It cleans up the code, strips it down to just the coordinates and the colors, and then rendered perfectly in the app.
That's just like a small example of the things that Zeplin did that, again, you didn't even really talk about that makes engineers' lives significantly easier.
Elliot Tu:Yeah, that's definitely something I think that our marketing team will take notes on and start advertising page, yeah.
Adam Warner: Yeah, definitely, all those little things you do in the background are actually vastly important to the flow of product design at Amazon for sure.
Elliot Tu: Yeah, tell us about your team structure.
Adam Warner: So, when we were talking about having this conversation, Elliot, I don't even know how many employees we have, but I don't know where you pulled this number, but I am sure it's right or it's probably too conservative, frankly. We're a huge company.
But my team is relatively small in the grand scale of that. So, I think a lot of people are surprised to learn just how small design teams can be at these large corporations. My team, in particular, has only four members.
I'm the design lead, and then I've got three UX designers that work on my team, and that's it. So, it's a team of four, and we're supporting about 200 people, at least 40 developers. I would say conservatively, we support 20 external partner teams. Being the video team at Amazon, being UX, that means anytime a team within the company wants to show a video on their experience or on their page, that literally comes through these four UX designers. It is a massive job, and I like to say UX is a horizontal among verticals. This is absolutely true, and it gives us a very good through line, so we see essentially like…okay, I'll just give you an example within my department, Elliot.
We have an acquisition team, a distribution team, we have a selection and Sciences team, and all these teams are focused only on their what we would call vertical. Whereas UX is horizontally supporting all of these individually. That includes external partners, other teams. It's pretty amazing how much work comes through a horizontal in that situation.
Tools like Zeplin are not an option for our teams. We have to have that level of communication and final handoff and specificity. Because if we don't, there's absolutely no way we could support this many partners, this many people internally.
All of my designers, including me, are juggling many projects, I would say upwards of 10 projects each at any given time. So yeah, absolutely, tools like Zeplin are 100% necessary for our team. There's no way we could scale to this sort of support. And we've just seen a massive increase in work in the past few years.
Elliot Tu: Definitely. Take us through more of those design to dev challenges, for example. What's complicated about design and dev collaboration, especially at scale?
Adam Warner: Well, everything is complicated at that scale. You've got it on this slide actually. This is kind of the hard part about modern software development.
It would be nice if everything was kind of bucketed, and it was an A to Z sort of process. It doesn't work out that way. A lot of times, you are building the plane while you're flying it. That is really what it feels like. Things are dynamically changing. You're having conversations even after handoff. You're getting into these conversations where a PM comes in and says, 'Well, we need this change, we need to support this new use case.' You have scope creep, you have scope increase. You have to go back, talk to engineering. Obviously, having that conversation on the design is pretty critical.
I think you have it on this slide. I think designers deal with the fluidity of that situation a little better because our tools are really kind of made for it. Figma's made to do quick iteration. I can always say I can make a pretty picture really easily. It's like handing it off and making it something that engineers can implement is the hard part.
Of course, on the engineering side, they actually have to do the true work of implementation, bringing that to life, coding it together. You've got to have some transparency in that process between PM to UX and then UX to engineering. If you don't have transparency, all of that building the plane while it's flying is impossible. Especially at this scale. We're talking, again, 200 people. Maybe there are 10 or 15 engineers just on one project. You cannot scale that conversation. You can't just have an impromptu meeting for every single decision.
Elliot Tu: Yeah, I can't sync ad hoc with like 200 people.
Adam Warner: Exactly. And so collaboration is obviously super challenging without some way to actually have those conversations and have them specifically on the designs that we're implementing.
Of course, there are plenty of features I’m sure we’ll talk about a bit later within Zeplin that allow you to see diffs between different version commits and have those threaded conversations inside the app that make that actually possible.
Elliot Tu: I can imagine it's kind of hard sometimes to get like two or three people on a call, so I can't imagine trying to get any more than five.
Adam Warner: Yeah, it's really difficult. At the end of the day, designers and developers have this core unification, this core point of unity in most cases. We've talked about personalities, right? There's always going to be people we conflict with or personalities we conflict with. But generally, the assumption and the best way to look at most people at work is we're all kind of going after the same thing. Designers and developers are going after the same thing. I've seen a lot of instances where designers and developers will butt heads with each other. There's a misunderstanding between the two sides where sometimes the flexibility and everything that designers bring to the table really conflicts with the precision and the efficiency that developers need. But at the end of the day, we want to ship a good product.
There's very few people that go into work and say, 'I want to make the crappiest app possible, something I would be ashamed to put in my portfolio.' Like, no one's doing that, right? So, we do care about the user experience. We do care about making a high-quality product. The question is really how do we facilitate handoff in such a way that it actually makes that process easy for both sides and honestly builds relationships?
That sort of Open Door policy, back and forth of having engineers and designers talking with each other constantly — it really does build relationships that are critical to delivering a good product. Yeah, so we share common goals, so we need a common solution.This slide here is a little bit like what I was just discussing, which is that the early phase of design tends to be very messy. Even the most organized of designers, and I know I personally will have like 60 screens, different variants, and then as I'm going through reviews and talking to PMs and stakeholders, and we're refining, refining, refining, that line that represents the design process starts to get straight. That line gets less squiggly. It starts to get more straight, and I'm starting to say, 'Okay, this is what the final design is.'
Using a tool like Zeplin allows you to make that final commit, literally you’re committing a version into Zeplin. It allows you to say, 'Yes, this is it. This is going to be the final design I'm going to hand off.' It gives developers a very specific, rigid set of requirements and screens that they can then take as final. Yeah, I think this is critical to have something in between the design phase and this more rigid development phase, right? You've got to have something in there that filters all of that chaos into something that's clean and understandable.
Elliot Tu:Yeah, I mean, the chaos in Figma is not necessarily a bad thing. I think, for designers, that's kind of a necessity almost — to have that freedom, the creative freedom to operate like that.
Adam Warner: It's the advantage. It’s the advantage of our design tools to give us the most flexibility possible.
Elliot Tu:But when developers are looking back, they don't necessarily want to see the whole thing, all the ideation that got there and the squiggly parts.
Adam Warner: It's a mess, you know? The truth is, Elliot, you can take three different designers, you look at their designs and at their Figma docs, and they’re all going to be arranged completely different. No matter how hard you try to enforce consistency there, especially at scale, you're never going to enforce consistency across the board. You can try mechanisms of force to get there, but it's much easier to just have it funnel through a more rigid system. And let that system handle things and essentially bringing unity to all of the designs that the engineering side sees.
Elliot Tu: And still allows that creative freedom on either side.
Adam Warner: Yeah, absolutely.
Elliot Tu: Yeah, no, that makes a lot of sense. It's very poignant.
Adam Warner: Yeah, culture for sure. Again, it's that transparent, open-door policy for engineers to come to design after we deliver the final design in Zeplin. I can't tell you how many times and how much I appreciate it when engineers come back and say, 'You know, Adam, this actually doesn't scale in this way, or you forgot about this one outlier scenario.' It's like, yeah, you feel like an idiot for a minute as a designer, as a UX designer, yeah, of course. My immediate response is, 'Oh, I should have thought about that. That's on me. I should have been the one to think about that.' But then it allows me to go in and make that iteration, communicate that to the engineer in the comments and say, 'Okay, yeah, I'll go back and fix this.'
And by the way, one of the niceties of Zeplin – and I don't think people really think about this too much, maybe on a small scale, but in a big company, this is really important – when you're having those threaded conversations with engineers, it's also emailing. It's also copying to an email, going through Outlook, and so it's actually tracking this conversation in a very public way that is super critical. A lot of companies, I think a lot of us kind of use tools like Slack, and we're just having these conversations. I haven't made this comparison before, Elliot, but I just thought about it. Slack is basically like Sketch or Figma, right? It's kind of messy, but you can make quick decisions, iterate really fast. But when it's a plan of record thing, we always email because we want a paper trail. There's something to that more definable chunk that then exists with a paper trail, very similar to the way Zeplin operates, where I have a clear list of changes per screen basis.
So yeah, looking at point two, “tackling issues as soon as possible”. Sometimes I think this just happens naturally with number one [of an open door policy]. So you're going to see these issues, more proactive communication on issues before things even have to go to QA if you have that transparency and that open door with engineers.One of the steps that I go a little further with my team – I would say this is probably more controversial, but I think it's super useful — is typically, in any large corporation I've been in, the engineering team essentially delivers during their sprints what we call code reviews. They'll deliver a snippet of a feature and say, 'I tried to implement this button, and when you press it, it turns green or something.' Typically, those only run inside the engineering department. It's quite rare for designers to get involved in that process. I get involved in that process. If one of our designers is on a project, they are included in those code reviews. So, that results in a lot of emails. I think I have somewhere between 20 and 30 code reviews a day that come through my inbox, but it gives so much visibility. This is back to that visibility conversation.
Yes, you have it in Zeplin, and then you also have it on the implementation of the code itself. By the way, I can call back to the Zeplin screen. If something's wrong, I go, 'Okay, yeah, it was supposed to turn green; it actually turned red. So, by the way, here's the link to the Zeplin. This is where we had this conversation. This is a link to the actual requirement, like the chat. Because that's another beautiful thing about Zeplin that I haven't mentioned too much is old school linking, just linking to something and putting that into a document, like a business requirements document for a project, is actually super useful.
Zeplin allows you to generate a permalink to every single chat, every single requirement, every single flow segment. Any small detail you can think of in Zeplin is linkable. You can generate a permalink to that, and you can pretty well depend that that permalink is not going to change. Because, unlike often in a design tool where I'm adding and deleting screens and stuff, I'm actually just continuing to refresh a delivered screen in Zeplin and then keeping a very complete version history.
Anyway, I definitely get involved at the code review stage. By the way, one last point on this, Elliot, that I think is important is it actually saves the company money in the long run. What typically happens if you don't do this, if you don't have this open door between designers and developers, is you'll get to the end of the process, and something won't be right, somebody won't be happy. This is usually a week before we ship, and designers are going, 'No, this doesn't look right,' and PMs are going, 'We have to ship in a week, it doesn't matter.' Engineers get stuck in the middle, engineers get completely slammed between UX and PMs. They get crushed. What they have to do is a litany of changes that creates instability within a week. So, that costs a lot of money, and often you have to push back dates, which also costs a lot of money.
Having this continuous development, continuous transparency, continuous open door really does save you significant money because by the time the design team sees the final thing, there's usually not that much wrong. We usually don't have a lot to critique because we've already seen it 20 times. It's just really fantastic.
Elliot Tu: Yeah, and I think something that you're mentioning – even these smaller issues that maybe Zeplin addresses – they sound small when you talk about it in its own instance, but everything you're talking about is multiplied at scale at Amazon, right? All these little time savings and all these blockers, they get even larger when you're talking about supporting a team of 200 people plus 20 external teams, right?
Adam Warner: Exactly.
Elliot Tu: This is like a quick kind of like what you were mentioning.
Adam Warner: Yeah, there are all these invisible little inefficiencies that we don't often think about, at least kind of at a management level. But when you're on the ground and you're a UX or you're an engineer, you deal with this stuff constantly. And without anything in between your raw design and the ultimate dev team or the engineering team is a way we would use it. It's messy. I think we get to this a little bit later, Elliot, but it is just, at its core, it's very clear how much messier looking at someone's design file that has 20 versions of the same stacked on top of each other. Depending on the designer, some of it might be clean; for one designer, it might be incredibly messy for another designer. That's really hard. It's really hard to communicate.
I go back to the old file naming thing, Elliot, that used to happen a long time ago. I think some designers still do this. I used to put 'final' at the end – 'final, final, final' – and I'm like, 'Yeah, no, this is really for real, the final.' I would always have this name at the end of a process that was like, you know, 100 characters. It's ultimately what you do is you kind of get that same thing in the design tools, like in Sketch or Figma. You kind of get the, 'Oh, it's final. No, I promise this one. I'm gonna draw a big green box around this screen. You know, this is the one that you should use.' So yeah, it absolutely creates some mistrust and some miscommunication, and we've actively seen that before. We've literally just seen engineers click on the wrong page. So it's like they'll literally just be on the wrong page within the Figma file, and it's like, 'No, no, no, no. You're supposed to be on this page.' So, we're constantly fighting that. Is it possible? Yes. Does it create miscommunication and rework? Absolutely, it does.
Elliot Tu: And it goes back to, like you said, I think about Figma. Like you said, designers are not all the same. So, if an engineer knows where to look for one designer, he may not know where to look for the other designer. That just compounds the problem, I think.
Adam Warner: Exactly. And, yeah, I mean, we don't have to go into it too much. We're probably running short on time, Elliot, because I've told you before, I can probably talk for three or four hours about all this.
Elliot Tu: We’ll do a part two.
Adam Warner: Yeah, we'll do part two for sure. But even Zeplin's integration with tools like Visual Studio Code, with Slack, with Jira – actually being able to have the Zeplin screens directly on the user stories – these are all super nice things to have. Not all teams have access to all these tools, but if you do, oh man, it is fantastic. It is so great to have those designs perfectly integrated with your project planning and with your code.
Elliot Tu: You know that as a part-time coder
Adam Warner: Yeah, exactly. You know, I've been there, so, for sure. Yeah. This one is the screen I was talking about, Elliot. It's just – I mean, it's a mess. So, frankly, this is actually a pretty clean one. It's not too bad. I've seen worse. Let's just put it that way. And yeah, it is possible, but it just – it's just hard. You look at this. I mean, most of the people on this call, I would imagine, are UX designers. We know how to create hierarchy, we know how to create focus. You know, you look at this – is there a lot of hierarchy and focus to this? If I'm looking for one specific feature or maybe I'm just looking for one button, there is this part – this task, by the way, it actually creates work on the designer part as well. You have to – you essentially, let's say if you don't use a tool like Zeplin, you have to recreate it as best you can within the design software. You have to make the buckets that Zeplin kind of generates for you just by default. You have to actually recreate those things inside of your design tool. It's a lot of work.
Frankly, it's like going backward in time to when – this is gonna point out my age again – I was having to deliver literally like PDFs with like, you know, this is like 10 pixels, this is 20 pixels, this is, you know. And it's like the less designers have to do that, the better. Frankly, if you have a change, you've got to render that, or you've got to resubmit that. Whereas in Zeplin, all you've got to do is – let's say if I change a gap from 20 pixels to 10 pixels – right? And then I send that screen to Zeplin, it's gonna auto-update that screen. I can add a comment about the commit. The engineer is actually going to be able to click and see the diffs between where okay, it was previously 20 pixels, now it's 10 pixels. And then, of course, if you're using Slack, they'll get an update on Slack about it. It's just – yeah, it's really fantastic for communicating those things.
Obviously, a solution is documenting in Zeplin. I think, you know, you can look at this. It doesn't take a lot of intelligence, let's just put it that way, to look at this and go, 'This is a lot cleaner. This is a lot more understandable.' Especially if I've got 20 engineers. I'm saying this engineer is dedicated to these five screens, this engineer is dedicated to these five screens. I can easily see the differences here in the left panel. I can see requirements and behaviors that all automatically show up in the right panel. And then, of course, I can just click through.
I can also just click on this design and, of course, see all of the measurements, all of the different specifications. We won't even go into things like style guides and, you know, and, of course, flows. One of the big advantages there is that I can literally split up a flow into different groups. Then I can permalink those flows to the appropriate team that's responsible for that part of the flow. So, yeah, just so much cleaner here. So much more understandable focus.Yeah, it's just like, even in a document-heavy culture, like a lot of big corporations, and including Amazon, we still have a lot of just documents, right? We just have a lot of digital documents, and that's the way these projects are still tracked even to this day. And it's a lot easier to go in here in Zeplin and say, 'I can provide a link to this screen, and it will always be the link to this screen no matter what happens, right? It will always be the same link or the same behavior.' That's just so dependable and it's so nice to be able to, like, just link directly inside of documents and say, 'Hey, just go here. This is where this is discussed.'
Elliot Tu: I think in Figma, that link might change, right? Or it might break if there are changes made.
Adam Warner: Yeah, I mean, Figma, you know, and we should give credit where credit's due. I mean, Figma has done a better job of doing linking as of late, but it's still – it's like the comments. It's still messy. There are versions, but then if you look at the versions, it's like every single ridiculous change, every autosave. It's very hard for an engineer to go in there and look at that list and go, 'Yeah, like, I'm going to find the exact change that I was looking to understand.' That's difficult. And it's also true that generally in Figma, I'm kind of working a little looser with the designs, right? I'm not delivering – you know, I'm not coming down the mountain, so to speak, with these perfect designs and saying, 'This is what you should develop, engineers,' you know? I'm changing screens a lot, and if I delete that screen, I redo it, I do something like that, that link's gone. That link is forever gone. Whereas I can literally, even in Figma, come up with a new screen, rename it with the same name, export it to Zeplin, and it's going to update the screen that had that original name in Zeplin.
So I can still maintain that link in Zeplin even though I've completely broken it in Figma. And so that's kind of like what I was describing earlier, Elliot, all these little niceties that Zeplin does. I think it's honestly a little difficult to communicate all of these in a significant way. But when you put them all together, they kind of add up to more than the sum of their parts.
Elliot Tu: And also, you know, again, I keep saying this just because I'm always in awe of the size of Amazon. But just those tiny things, and then all at scale becomes something even crazier.
Adam Warner: "Yeah, yeah. Sorry, I like this slide. It's insane. Obviously, as a designer, I know what's going on here, right? Like, I get it. But it just points out how bad it can get when engineers are looking at, in particular, files that are not organized super well on the design side. This is what an engineer can encounter in Figma. Yeah, it's obviously scary and not great.
So, yeah, flows in Zeplin are much clearer. So yeah, this is much, much easier, much more intentional. And I think this is something, Elliot, I mentioned to you earlier when we were talking about this slide. It's friction. There is some friction to this. I'm not going to sugarcoat the fact that. You know, obviously, you guys aren't paying me for this. I don't work for Zeplin. I couldn't. Honestly, it would be a massive conflict of interest. So, like, the truth is, I do a lot of flows in Figma. And when I bring these over, there is some auto-flow that happens in Zeplin, but I have to go and do this extra work to make a flow in Zeplin. It's not required, by the way, but I do. If I want this, there's extra friction. I have to go in here and make another flow. So there is friction. But as we've talked about before, I think when we were discussing this exact presentation, there's just extra – there's an extra cleanliness that you get out of doing your flows this way. And then again, with the scalability of something like Amazon, where I'm having to deal with this massive team, as you're showing on this slide, I can separate that flow out into individual pieces. I can send those pieces to just the team that's responsible for that thing. And then, of course, do doc linking. So it's just a much cleaner way to document this sort of information.
Whereas in Figma, frankly, I'm usually treating it as kind of a play space for prototyping. So, a lot of times what I'm doing in Figma is just prototyping to kind of see if this is the right interaction, the right behavior. It's not really engineering documentation. I wouldn't be down on anyone's process if they did not use flows in Zeplin because there is some additional friction that you need to take on there.
But, it just goes to show you that everything that's built in this tool is purpose-built to make that transition from design to development an easier process for engineers to be able to understand how this project should be broken up and how it actually works. I think flows is another good example of Zeplin going the extra mile and making those little extra features that you will not have by default in your Figma flows.
So we're not looking at spaghetti.
So, yeah, measuring the impact of Amazon's workflow. I think all of these are true, by the way. But, you know, I mentioned this to you earlier, Elliot – my team, in particular, has grown fourfold. We've really seen an increase of 4X in the number of people that we have on the team just in the past year and a half, two years. We have seen more than a four-fold increase in the number of projects. And a lot of that is due to the team just becoming very prolific.
We've got a lot of partner teams coming to us now. So we're seeing even more projects than a full four-fold increase. And we're still handling it, which, if you look at the numbers and if you look at four designers dealing with this level of work, that's kind of a miracle. And really, that comes down to process. When you scale at this size, you have to be more rigid about your processes. And whether that's design, whether that's attending code reviews on the designer side, coming into the engineering code reviews, increasing transparency, designing flows, for example, those are the things that will make or break a development process at that scale.
Elliot Tu: That's good to hear. I think one thing that should be said is Figma obviously works so much within the design tool world. For us, design to development, that handoff has always been our bread and butter, our only focus. So, like you mentioned, going that extra mile is kind of like what we're focused on the most — that specific design to development handoff process.
Adam Warner: Totally.
Elliot Tu:Thank you Adam. We can hop into some Q&A now.
Fin
