Show notes
Show Notes Peter and Jesse are joined by Chengying “Z” Zheng, who shares her experience migrating a design team to be AI-first — off Figma and into code. She discusses how design leadership and operations divide the work, what happens to roles and titles when everyone becomes a builder, and how to make good design easier than bad design. Z on LinkedIn: https://www.linkedin.com/in/changyingz/Z’s Substack: https://changying.substack.com/Jesse James Garrett: https://jessejamesgarrett.com/Peter Merholz: https://petermerholz.com/ Transcript Jesse: I’m Jesse James Garrett, Peter: and I’m Peter Merholz. Jesse: And we’re finding our way, Peter: navigating the opportunities Jesse: and challenges Peter: of design and design leadership. On today’s show, Jesse and I are joined by Chengying Zheng, better known as Z, the design operations, or should I say experience operations leader with extensive experience in tech. She shares with us how she guided a design team through an AI transformation, setting aside Figma and building right in code, her thoughts on the evolution of roles and teams, how to maintain quality, and the new work of operations. Hi, Zee. Thank you for joining us Z: Thanks for having me Getting the team off Figma Peter: The conversation we’re having with you, for me at least, started, I wanna say, six to eight months ago, when you and I were in the offices of Figma at a gathering. There was a lot of folks there, but you and I had peeled ourself away from the crowd, and you looked at me, you looked around, you looked at me, and you said, ” It’s a little weird for me to be here because I just spent the last three months or so getting my team off of Figma and into AI tools.” And we talked a fair bit about that. You’ve been writing about it in your newsletter, but I’d love for you to share the, the highlights of that experience. Yeah, the highlights of that experience. Explain a little bit about where you were and what that journey was like and how you did evolve a team out of Figma and into more kind of AI-native practices. Z: Yeah, absolutely. It was a really interesting moment. I remember that conversation A lot of folks at the time were talking about AI transformation. Everyone was thinking about it. This was still last year, still a little bit early in this curve about AI transformation, so a lot of people were thinking about it, and people were doing it, and some, of course, AI-native companies were way ahead compared to the rest. They were already out there. And our team was interesting because we had this mandate, like any other tech company, right? So you will start to do AI transformation, to incorporate AI into your workflow. So for designers, the first thing that we looked at was how designers prototype. We weren’t even thinking about how designers ship, we were talking about prototyping. And of course Figma has been the de facto tool for product designers for many years by now, but in this new workflow, we were thinking about getting designers to prototype with the new capabilities, with all the vibe-coding capabilities. And a lot of our designers started to see that Figma, instead of a prototyping tool, which is what we used it for before, had now become a wireframing tool. Basically, you come up with ideas and then draw them out in Figma, but then you- the prototyping is actually happening in the coding part, in the vibe coding, whatever the tool was back then, whether it’s Claude or OpenAI, whatever. So I wrote about it. I audited our Figma. Of course, as the operations person, we look at our Figma usage and everything. I audited it one time, just on a random day, I looked at it. Out of our hundreds of licenses, there were 50-some people using it that day, and only five of them were from our product design team. Most of the others were marketers, PMs, everything. So that was a very interesting moment for us to look at tooling and at the designers’ tool stack. But that was months ago, actually, compared to right now. Everything moves so fast, and that feels like so long ago. Telling engineering what changed Jesse: I wonder about the cross-functional aspect of making this happen, because there is always this sort of ripple effect whenever one team changes the way it does things, on how that team then interfaces with the teams around it. How did you manage the cross-functional conversations as you were transitioning the team out of Figma as their primary way of doing things and into vibe coding? Z: Yeah, that’s definitely a lot of challenge and work. So I actually proposed it back in October last year, to our design managers, to design leadership. I said, “Let’s get our UX designers out of Figma.” Of course, everyone was like, “No freaking way. You are crazy. Designers are in Figma, that’s our tool,” and everything. But the reason I proposed it is that it wasn’t just a random proposal, like let’s get rid of tools or anything. At the time, we had a new design system that was entirely in code, and we were fortunate in a way, because instead of trying to continue building multiple design systems and trying to move them along, to modernize all those design systems, from the top down there was a mandate. This is the design system we’re going to use. That design system is in code. And that’s really what prompted this proposal. That didn’t happen, so by the time I talked with Peter, that was already three months after. I think we talked at the end of last year, and it was October when I was proposing it. But by then, just de facto, no push or anything, designers were already out of it. But there was a lot of conversation. If I could have done this all over again, I would do it differently. I would be reaching out to the engineering team immediately and talking about this transformation. At the time, this just organically happened, and then by the time I talked to Peter, this is… That’s when we started to realize, oh gosh, we need to talk to engineering a lot more. Some engineering teams still required our designers to give them a Figma file. Some other teams were more open, and you could do other ways of prototyping. And there was a lot of discussion about what designers were doing in code, and we also had to go out and talk about it. There are levels to “designers shipping code” There are different levels of designers in code. So there’s the- One, the basic thing about getting designers into code is engineering empathy, right? So engineers now, instead of just coding, they do a lot of reviewing code as well. So what it takes to- for an engineer to build something, that’s something designers should understand as well. And then another level is where we got our team to prototype, but then by the time February this year came around, our designers were actually shipping production-level code. It sounds so grand, production-level code or whatever, right? But by then we had worked with the engineering team, put a lot of guardrails in place, about what designers should not be touching in terms of code. If it’s an API, if it’s infrastructure, if it’s, say, if it touches a flow, these are things designers should not be doing. And what we’re actually talking about when we say shipping production-level code is paper-cut-level shipping of code, right? So change a piece of copy, change a wrong component, small changes. And so these are things people sometimes talk about, “Oh, designers shipping code.” They put it under a blanket umbrella that says, “Designers shipping code.” But there are actually really different levels of designers even touching code. People are not getting there because, “Oh, designers shipping code. Are we turning designers into engineers?” No, absolutely not, right? So same thing, we opened up Figma for other cross-functional teams to use. PMs using it, engineers using it. Are we turning engineers into designers? Probably not. Are we turning PMs into designers? No. But we’re turning everyone into a product builder, a contributor, in a way they’re passionate about, wherever they see a fit with the tool. Now we’re basically just giving everyone all the tools, not just keeping Git for engineering, Figma for design, or whatever the PM tooling is, but we’re actually giving the entire tool stack to everyone who is touching product and building, and they use the same tools we have. And so that’s where it is. But it takes a lot of talking, coordination, and it really does hit some nerves because everyone is jumpy, and designers say, “Oh gosh, engineers designing, PMs designing,” and the engineers say, “Oh gosh, designers coding, PMs coding.” So I wouldn’t say it was all smooth, but at least that’s something we put a lot of effort into, and we saw results from doing that. Standardization doesn’t scale anymore Jesse: One aspect of your story that I think really resonates with what I’m hearing more and more, and what I’m seeing in AI transformation efforts broadly, is the notion that you have to meet people where they are inside the organization. And imposing a kind of one-size-fits-all policy for this technology is not actually going to get you there, that you need to be able to find ways to leverage potentially a broad range of different skills across your team in a way that you haven’t before, and to be able to accommodate a diverse range of different kinds of workflows, and setting different kinds of expectations accordingly, cross-functionally, with how product and engineering interface with and interact with design. I wonder for you as an ops leader where your mind goes when you think about managing operations across a diverse, distributed set of work processes that no longer fall in line with a single paradigm anymore? Z: Absolutely. So I come from a very strong operator’s perspective, right? So in the past, as operators, you were the process wranglers, basically. That’s what it is. You want to… The word we used for the longest time was standardization. Standardize the process, and that will actually scale, right? So but right now we’re pitting speed versus quality. There are a lot of discussions in there, whatever. Like you just said, standardizing everything won’t work anymore because different teams move at different speeds, and different teams have probably started to adopt slightly different workflows. And some teams might… Some companies, some teams, might even allow them to use slightly different tools or whatever. So I wrote about it, and to talk about it now from an operator’s perspective, I push a lot for shared principles, and then giving people the agency to work out the details, how to execute it, and to have a little more flexibility instead of standardizing across the board. But shared principles are something every team needs to spend a lot of time aligning on, and also educating everyone and talking about, because if you think about shared principles, for designers, there are certain things, right? Accessibility is a, for us, something we care a lot about, and engineers care about that as well. And engineers probably care a lot about their code quality as well. So their APIs, nobody touches, and as long as we’re clear about what everyone can contribute and that everyone should reach out to the experts to contribute, that helps the team move in different formations, but still moving in the same direction. Should ops be leading the AI transformation? Peter: I’m, so, I’m gonna continue on this thread because when we spoke about this at that Figma meetup, the light bulb that went off for me is that this type of AI transformation might be better led by operations folks than design leaders. Whereas my kind of working assumption in the conversations I’d been having with clients and whatnot, design leadership was responsible for that. And, if they had an operations person, maybe would be leaning on them to help. But something that’s also happened over the last couple years is a lot of ops teams have evaporated. And so the, the irony being we’re in now in this moment that is so operationally heavy, and many teams don’t have operations folks to help them through it. And I’m wondering what is your relationship with design leadership through this type of experience? What are you responsible for? What are they still responsible for? How do you distribute authority? Who’s making what decisions? That kind of thing. Z: Yeah. So if you think about design operations in general, with your leader, it’s always a balance. It is always challenging to divide that responsibility and accountability. It’s just because different teams work slightly differently. So in my specific situation, it worked out really well because at the time, I reported to the head of design, and her mandate from the top down was AI transformation. And then my part of the work was actually getting that done. And then the design leader coming in down to the team, this AI transformation, you think about it as a gr- grassroots effort. Everyone wants to use something, build something. But to do it right, you absolutely need top-down support, to give people the time to do it and to give people the direction, where to go and what we want them to do. Do we want them to stop at prototyping? Do we want them to ship code? We do need to know what the end stage is that we need to get the team to. And as an operator, then we can actually help the team achieve that and figure out the logistics, scaffolding the team step by step, how do we get there, get the designers into code. I came from a very technical company. It’s extremely hard to get into our production code base, rightfully, and it should be. It shouldn’t be turnkey, where everyone can ship code. So there’s a lot of coordination. It’s my role and my team’s role to go out, reach out to our engineering partners, “Come on in, help us do it right, because you do want us to do it right. You don’t want to review crappy code. You want to teach us to do the right thing.” And then so in return it helps them as well. And also a lot of explanation as well, “Hey, we’re not trying to be engineers. We’re actually trying to take care of the design debt that engineers never have the bandwidth to take care of, and they are very small paper-cut things.” Leadership owns the what, ops owns the how So my goal is really to focus on the how. How do we get the team there? But design leadership is the what. Coming in with the what, and giving the team the mandate. That’s really important. With these things, if you just say, “whoever wants to get on the bandwagon, let’s do it,” it is really hard to move that fleet in the same direction. Those would just be sailboats, right? Everyone’s like, “I want to go. I want to go really fast. I want to do something.” And then someone else wants to do something else. “I want to use this tool.” “I want to use that tool.” So the design leader needs to come in and say, “This is where we’re going to get people,” the what, and then the operators come in with, how do we get there? And that worked out really well. And then also because we’re… We say it’s design operations, but on the other hand, nowadays my perspective on operations is that maybe we’re not design operations, we’re just operations, in a way. Experience operations, whatever. Reaching out to more teams outside the design team. And after our transformation for the design team, I ended up going out, because of our training, we had everything in place, documentation, recordings, process, all the things in place. Now other teams, these non-technical teams, came to ask us and say, “Can you train our team? Can you train our team?” So our team members, our operators, actually went out and thought more about how to leverage our knowledge to up-level the cross-functional, cross-board, company-wide AI transformation, everything. So I’m thinking and trying to figure out, do we still use this term design operations, and does it still have a meaning? There might be, but there might be more. Maybe design operations…
Full show notes at the publisher