Establishing Design Engineering

25 Feb07:35 – 08:20 UTCStage: Main StageTalk

Checking session availability…

Hang tight while we load the latest updates.

In this talk, Anna “Spyke” Spyker (Software Engineer) and Ella Moran (Product Designer) share how they established Design Engineering at Tracksuit — a new way of working that enables product designers (and PMs) to safely ship front-end code to production.
What began as UI polish after a release quickly evolved into designers independently shipping full features, using AI, clear guardrails, and standard engineering review. Ella and Anna will walk through how the workflow evolved, what surprised them along the way, and why designers are uniquely well-positioned to describe and deliver front-end work.
They’ll also dig into the open questions this raised for the team — from ownership and review, to whether Figma is still the right starting point.
A practical look at how design and engineering can move faster together, without sacrificing quality.

Establishing Design Engineering

Ella Moran, Anna Spyker at UXDX Community: Sydney: Establishing Design Engineering. Video: https://www.youtube.com/watch?v=cJwtmMwIJCE

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Welcome and introductions

[00:00:05] Sonali: Hi everyone, good evening and welcome. I'm Sonali, your host for today. Thank you for being here and taking the time out of your busy schedules. I would like to begin by acknowledging the traditional owners of the land on which we meet today, and pay my respect to elders past and present.

[00:00:26] Sonali: Today's session is part of UXDX community events, where we bring together people across product, UX, design and engineering to learn from each other and build better products together. A bit of context. UXDX exists to help teams build better products faster by closing the gap between product, design and engineering. Too often these functions work in sequence. We focus on working together end to end, from discovery to delivery. We share real stories and practical tactics, what worked, what didn't, and why, through conferences, workshops and local meetups. The aim is the progress you make and you take back to your team: clearer problem framing, stronger discovery, tighter feedback loops and smoother releases. UXDX is an open, inclusive community. Whether you're here to learn or to share, you're welcome.

[00:01:25] Sonali: So today we have one talk in the agenda: establishing design engineering, a topic that's becoming increasingly important as teams try to move faster while maintaining quality and consistency. I'll start with the intros and we can jump on the topic, followed by Q&A. During the session, if you have any questions, please use the website to post it and we'll get to it in the end.

[00:01:50] Sonali: A quick intro about me. I work at the intersection of product, UX and strategy, currently in the New South Wales Department of Education, where I focus on building digital platforms used at scale. I'm also passionate about community building and helping teams work better across disciplines, which is why I'm excited to be part of UXDX. My goal with these events is simple: to create a space where practitioners can learn from each other, ask honest questions and leave with something useful they can apply immediately.

[00:02:25] Sonali: Now let's talk about our amazing speakers today. I'm delighted to introduce two incredible practitioners from Tracksuit who are doing some fascinating work in this space. Ella is the senior product designer at Tracksuit, specializing in building and shipping products across fintech, consumer apps and enterprise platforms. She's known for bringing design and product thinking together to help teams turn ideas into real impact. At Tracksuit she's also been a driving force behind design engineering, helping designers and product managers confidently ship code to production, build AI powered experiences and improve how teams collaborate.

[00:03:07] Sonali: Anna, or Spike, is a principal engineer at Tracksuit, specializing in bringing machine learning and generative AI into real world production systems. With a background spanning data engineering, ML platform and full stack development, she has led teams building scalable human in the loop AI systems in complex domains. At Tracksuit, Spike is helping redefine how product teams work together by co-building design engineering, creating the technical foundation and guardrails that allow non-engineers to safely ship code to production. Together they'll share practical insights from the field and what's actually happening inside a fast-moving product company. Over to you, Ella and Anna.

What Tracksuit does

[00:03:56] Ella: Hello. Can you see us and hear us? I think so. Amazing. Thank you so much, Sonali, for the introduction, and also UXDX for having us. I'm Ella, and as mentioned I'm a product designer at Tracksuit, and I have Spike here as well, who is a software engineer. Yes, she goes by Spike, far cooler if you ask me. Today we're going to talk about establishing design engineering at Tracksuit. Before we get into this and what this all means, I will do a quick introduction as to what Tracksuit actually is.

[00:04:28] Ella: I've got an image on the right hand side of this slide. This is a real photo, not AI, of a billboard in Times Square. In about May last year Tracksuit purchased a billboard in Times Square and put a photo of everyone in the whole company on that billboard. And now our two truths and a lie absolutely pops off, as you can imagine.

[00:04:52] Ella: But Tracksuit does what's called brand tracking. For those that aren't familiar with, you know, the depths of marketing tech, basically what that means is that the brands that we see in the world, we allow them to have a sense of what sort of awareness levels they have amongst the general population, what percentage of people would consider purchasing from their brand, what percentage of people prefer their brand, and answer questions like that. But Tracksuit does it in a way which is affordable, always on and beautiful. Always on just means that we're collecting this data all the time, in comparison to some of the incumbents which just do it once a year or twice a year or something like that. So that's a little bit about Tracksuit.

[00:05:41] Ella: Let's get into today's presentation. Spike and I today are going to talk about how we established the concept of design engineering, which is essentially product designers shipping quality code to production at Tracksuit. How we got that started, how we got the whole product design team doing this, and then also from there how we got the whole product squad, so extending to product managers, prototyping in code in product. So not in a separate kind of thing that they've spun up in something like Lovable or something like that, but actually in the product. And also where we will go from here.

[00:06:19] Ella: Essentially moving from what we've got on the left hand side. We've tried to be super transparent with our presentation today and show very much behind the scenes of along the way here. We've got some screenshots of our Slack posts from our first ever pull requests, first ever PR reviews, big milestones like that, to today, where we're working in a much more sophisticated way.

[00:06:44] Ella: Now, Spike actually sent me this visual just earlier today, and this is apparently the steps of AI assisted coding. Basically we've moved from being, as product designers, off this chart, to being something like figure six, where we have multiple Claude Codes working on behalf of us at one given point and we're not even looking at the code any more. Okay, Spike, I'll hand over to you for a little bit of context.

Where the team was when this started

[00:07:13] Spike: Thanks, Ella. I'm just going to give you all a bit of context on where we were at as a team when we started this initiative. We're a really small team, just two engineers, a product designer and a product manager. And we were really quickly and really ambitiously working towards releasing a new product, building an MVP. We had a really, really tight launch date, and so what this means is you're always trading off on things just to hit that release date. Our engineers are at capacity, past capacity even, and often things are getting rushed. You're trading off functionality of the app, to be there, versus how it's usable and the form of it.

[00:07:53] Spike: So while the product itself was going to be functional for the release, it didn't meet the high quality visual bar that we would usually have at Tracksuit, but because we were really rushing, function beats form. And so these visual edits and the little interaction details that really make a product what it is were getting missed from this release, just due to the capacity of the team and it being so small.

How it began: one day of fixes

[00:08:20] Spike: So I'll take you on a little story of where this all began. Like we said, we were rushing, rushing, rushing to this release date. Basically what I'd said to Ella was, hey, if you don't mind, once it's all in production, can you have a look, make a list of all the things that you'd really, really like to fix, and I'll block out one day to just smash these out and get them all done. Make sure it's in priority order and we can just get this done.

[00:08:49] Spike: Lucky for me, Ella was in Auckland that day, and so she came to me with this list of features and tweaks that she would like fixed, following my promise of that one day to fix them. I started reading over this before Ella got in the office, and then I was kind of thinking, pretty sure I'm just going to be copy pasting what she's asking for into Claude Code, and just getting Claude Code to do this for me. So why don't I just get her to do that? Cut out the middleman.

[00:09:15] Spike: So when she arrived at work that day I had basically had my laptop set up, Claude Code open, and I said, go ahead, you should make these changes yourself. I'll let you know how to test them, I'll let you know what to do, but I'm going to be as hands-off as possible. And by the end of that day I was literally just sitting there on my phone scrolling on Instagram reels while Ella did my whole day's of work for me. And we got through the entire list of bugs in that one session, which really made me think, wow, this is awesome, she should be able to do this on her machine.

The front-end assistant

[00:09:51] Spike: Which brings me to the next slide, where I'm going to talk about how we actually specifically ended up doing this. Because Ella went back to Sydney, so what we really needed to think about is, how can she do this in a repeatable, more constrained way that doesn't need me sitting beside her and making sure that things are working? So we built her a little agent called the front-end assistant. And the front-end assistant basically had the guardrails on it for only being able to edit certain parts of the codebase, only being able to change certain things, against our conventions.

[00:10:24] Spike: And the way we set up the repository was that Ella could just run the front end locally, make her tweaks and edits, as they were all visual and design interactions, while it would still hit our remote backend on staging. So that would still be on the cloud, but locally she could run her own thing, be on a branch, send her agents, add the prompts and iterate as she wanted. That way she got that really fast feedback on what she's editing, because she's got the front end running locally, but she doesn't have to think about having database credentials or getting onboarded to our cloud platform, which takes, as you guys probably know, a lot of development time to get that all set up. So this is what we landed on, and now basically Ella can just go away and activate that front-end assistant, knows how to make a branch and then submit the pull request.

[00:11:16] Spike: So by the end of this our workflow looked a little bit more like this, where I would just do the literal bare minimum of stringing things through from the back end to the front end. I would basically just have a box of where the front end needs to go, I would pass it over to Ella, and then she would pick it up and fill in the rest of the owl. She would do the rest of the front end feature. This is where we were at, probably November last year, and it's come even further since then. So every stepping stone along the way, it rapidly changes how we're working together and what our handover looks like between us.

A real example of the workflow

[00:11:52] Ella: For sure, thank you Spike. So let me show a real example of how this looked, and this probably would have been quite early in the workflow that we were figuring out. This is an example of something that Spike had pushed, some code she pushed. I pulled it onto my local, and this section down the bottom was what was newly merged. As you can see, functionally it's all there, but I was able to clean it up and make it just look and feel more like a real product. For example, you can see things like the mosaic tiles as opposed to just a big grid.

[00:12:32] Ella: And what I will jump to is, I could work on things like the interaction details of how a card expands. That is just something that engineers are just not going to care about as much as a designer. And if you ask an engineer too many times to go back and forth on improving those kinds of details, they're just going to tell you, we're not doing this, it's out of scope. So those small details just really make a big difference in the overall look and feel of the product, and just making it feel like a more sophisticated product as well. So that was an example quite early on of the way of working, how it actually showed up.

[00:13:12] Ella: Then from there, probably in about late November, so not long after we initially kicked this off, I was able to actually start to build a feature entirely on my own. Previously Spike had been building the skeleton and then I would build the owl, but from here we actually were able to get to a point where I could ship an entire feature myself. So this was another big milestone, where I shipped my first feature, which was the ability to copy a graph or a data visualization as an image and paste it somewhere else. That was pretty exciting as well. I won't show that video.

Rolling it out to the whole design team

[00:13:49] Ella: From there, of course, internally there was a lot of excitement as well, and the whole product design team wanted to be doing the exact same thing. This was a little bit trickier because the different product designers were working on different products, and so what that meant was it was going to be quite tricky for me to get everyone set up in the repeatable way that Spike mentioned before. Again, we've got some screenshots on the left hand side of all the product designers' first pull requests, which were exciting moments.

[00:14:21] Ella: But just to call out some of the things that I learned here and would recommend. It's really important to have an engineering ally with you to support you in that initial dev environment and repository setup. It's so important to have a champion in terms of encouraging you to work in this way, because I think if you have engineers in the team who are a little bit more skeptical or apprehensive it can really slow things down, I guess. So find an ally in each team.

[00:14:54] Ella: But also don't be afraid to lean on Claude and ChatGPT. Obviously these tools can go such a long way in helping you understand a bit more about what you're doing, because it can be so complicated, especially when you're trying to do it for the first couple of times and it just feels like learning a foreign language. I'd also recommend starting small with the changes. This keeps everyone comfortable, and by everyone I mean the engineers, I mean wider stakeholders.

[00:15:17] Ella: And I also encourage recording a Loom of the change that you've made, so that again it's visible. Because what will happen is you'll have one engineer reviewing your pull request, but everyone else knows that you've shipped some code but they don't know what the quality of that code was like. And so if you have something you can point to and be like, no no no, it's a small sliver, this is what I've done, that just helps everyone feel a lot more comfortable, and also means that you won't get looked at if a new bug is introduced. Everyone doesn't start automatically pointing fingers at you. Back over to you, Spike, for this slide.

Iterating on the agent, and treating the code as real

[00:15:57] Spike: Yeah, so our work is very, very iterative. We change stuff along the way all the time. We didn't just land on the best way of doing it in this first try. We did do a lot of trial and error of what the agent would look like, what kind of boundaries we need around it. Originally it was too restrictive, and then we kind of got it to a good point, but then Ella reached past the boundaries of what it could do because she was getting so comfortable with it.

[00:16:24] Spike: So constantly iterating on your agent, not just for what it's doing in the codebase but also for who the user is, and having those different levels of how much it is able to do based on the user, has been really valuable. As Ella's been doing more and more, she's moving from just little front-end tweaks to actual features. So it's really important to make sure that along the way you're making sure that those standards and the conventions of how Ella's working go in place along with her.

[00:16:56] Spike: And then when it comes to actually creating the code, these are real PRs that go to production. These aren't just test prototypes or anything. Ella's code is in production, and the way we approach this code is no different to any kind of engineer on the team. Ella's pull request would go through the exact same review process as any other engineer in the team. It would go through the same CI, it would go through the same tests, the same deployment workflow. There's no difference between a PR that's created by a designer, product manager or an engineer. It's all just going through the Tracksuit standards.

[00:17:34] Spike: And then finally, something that Ella's already touched on that works super well is, create FOMO. Make demos, make noise, post Looms. As soon as we started exploding this all over Slack and showing everyone what's possible, you kind of get a lot of people being like, wow, I could do that too, how do I get started? And that's what snowballs through the rest of the company, and now we have all of our product designers contributing to production code. So be really open about what you're doing and be visible.

Where we're at now: the whole squad prototyping in code

[00:18:10] Ella: Perfect, thanks Spike. So, a little bit more on where we're at now. I want to separate two things. What we've been speaking about so far, where we've got product designers shipping code to production, that's what we've been calling design engineering. But separate to this, more recently we've gotten the whole product squad prototyping together in code. What you can see on screen here is a screenshot of our GitHub activity, and as you can see on the right hand side, I've shown how we've got both designers and PM collaboratively shipping, and this is all over the course of one day. So it's kind of entirely changed how the product team works together and collaborates.

[00:19:01] Ella: This is basically a duplicated version of the repository that we'd normally design engineer into, and we've kept this as a duplicate for now so that we can absolutely run wild with our prototyping and build as much as we want, auto accepts on, without any fear of breaking anything. And as you can see, it's also just changed the shape of our roles, because now the PM in my team is also just shipping his own code of things he's designing. I'm also shipping code. So we're all kind of merging into these builders or producers or makers, which I think people are seeing being said all over the internet at the moment.

[00:19:44] Ella: But basically this meant that we could prototype wildly. Another knock-on effect of this is that now I'm finding myself skipping Figma entirely. Unfortunately for Figma, basically it's actually quicker for me to go into Claude Code and prompt a change that I want to mock up, because Claude will do it in our design system and just does it incredibly fast. So what that means is now I've been handing over a deployed link of the prototype to the engineers in my team, for them to take that code and make any final refinements before they then ship it.

[00:20:23] Ella: I think what we want to do from here is bridge that gap. So we obviously have design engineering, where we're doing smaller changes that we're a little bit more comfortable with, whereas this is more like wild prototyping. I think we next want to start experimenting with, again, a bigger feature, but doing it actually with the intention of shipping the code at the end. And even today I was having multiple instances of Claude Code up and running and working on this. So the pace of work is absolutely changing as well. Back to you, Spike.

What surprised us

[00:21:05] Spike: Yeah. So I just want to touch on some things that surprised me and that we learned along the way. The first one actually was, the first time I put Ella in front of my laptop and said, use Claude Code. I don't have a front-end background, I'm mostly a backend developer, so I didn't know the front-end language. And Ella knew which margin aligned with which margin on the page, off the bat. She designed it, she knows where these things need to happen, where I could be spending hours trying to find the correct margin to make a little bit smaller, which might break something else. So super helpful to have that person who's used to that language being able to articulate it to the AI, a lot faster than someone who isn't used to that environment working.

[00:21:51] Spike: And then, originally Ella was doing little UI tweaks without me knowing. I'd wake up in the morning, there's a PR. But now it's evolved to where entire features are being worked on with our engineering. So that is very surprising. It's great to have people of agency who can just, they see something they want to fix and they are able to fix it, or they're able to make that change.

[00:22:13] Spike: And then the final thing, which I think is very important, is that working in this kind of way really reduces social friction in the team. Often things are bottlenecked with the engineers, and the engineers are the ones who get to make the trade-offs over what's going to make it into prod. But now everyone's empowered to make the changes that they want to make and ship, and we don't have that bottleneck, or that one person being able to overrule other people's opinions on what they think is important. So now we can all kind of take that and run with that. Hand over to Ella.

[00:22:49] Ella: Yep, thank you. For me, the first one is a big one, and that's that every single time this year, or in the past year, I've tried to predict what our ways of working, or even our product, will be in six months' time, it ends up happening like two weeks later. And that is no exaggeration. So I'm just going to stop trying to predict the future at this point.

[00:23:10] Ella: And then secondly, a really big one, an important part of this journey is empowering others as well. Obviously I wouldn't be where I am in my design engineering journey without someone like Spike, but also then, as a knock-on effect to that, the other product designers in my team wouldn't be where they are in their design engineering journey without someone like me. So I think everyone is going on this learning journey, everyone's learning different parts, finding different things that work. And so it just absolutely works best when we all get together and share that. That's exactly why we're here talking today. It's just so important to find the people that are going to go on that journey with you and are equally excited about it as well.

[00:23:46] Ella: And number four, the engineers in my team are very patient. Again, just included this slide as a bit of an insight into the journey, and I do feel like I've come a really long way from a lot of these screenshots. But yes, thank you Spike, and also thank you Venny[?], another one of the engineers in our team, who had to answer a lot of my pretty stupid questions. No stupid questions though.

What's next

[00:24:17] Ella: Okay, so what's next? We initially created this slide as a placeholder and then we realized it's actually probably pretty accurate. Back to my resolution of no more predictions about the future. In reality though, I think a big focus for us is, as I mentioned before, bridging that gap between shipping code in the design engineering way of the world, that we're quite comfortable with, with the front-end assistant there and engaged, versus the wild prototyping we're doing with accepts on automatically. We want to find the middle ground and start to bring that wild prototyping into our actual repository and get a little bit more comfortable there.

[00:24:59] Ella: And also just, again, make sure we're bringing the whole team on that journey. And I think outside of that, just continue learning. And also just making sure that, now that we can ship faster, we're always still shipping the most valuable thing, and it's not just about heaps and heaps of building just for the sake of it. Anything you want to add, Spike, anything we've missed in terms of what's next?

[00:25:26] Spike: No, I love that. I like the fact we tried to make this slide like two hours ago and we were like, you know what, we don't even know. It's pretty relevant to right now.

[00:25:36] Ella: Exactly. Perfect. So I think that brings us to the end. Thank you all so much for listening. Feel free to reach out if anyone has any questions. Actually, I think we're going to go to questions, but outside of all of this, if you want to reach out, we'd both be more than happy to have a chat, and we'd love to hear about the journey that other teams and other people are going on as well. So thank you for watching.

Q&A

[00:26:04] Sonali: Awesome, thank you so much, guys, I think this was great. I actually have one question. I know that you guys have come a long way, but were there any challenges when you just started, or even for your first milestone, were there any major challenges that you want to talk about?

[00:26:28] Ella: I'm happy to start on this one, Spike, if you'd like. I think one from my end is that sometimes there's been a little bit of skepticism about designers coding. Thankfully, obviously, I've got amazing engineers that I work with, but even when you talk about it in wider events, I think people use the terms like AI slop a lot, and also it always gets called vibe coding when a designer does it, but it's AI assisted coding when it's an engineer. So we're really trying to challenge that, and it's AI assisted coding for everyone.

[00:27:00] Ella: I think that just really comes back, again, to starting small. Absolutely monitoring the code that Claude is doing, especially at the beginning. Using another instance of Claude to check and to ask questions about the code that's been changed, and you also learn so much that way as well. So I think just making sure, especially the first few pull requests you're submitting, that you're beyond confident with what's been changed, and you're getting the engineers who were reviewing the code to kind of champion that your code was quality.

[00:27:38] Sonali: Awesome. And there's some curiosity about the team structure. How many people are in the product design team, or how is the team structured right now?

[00:27:52] Ella: So the product design team has four individual contributors and one manager currently. But we're starting to think about what sort of goal the product design team should have in terms of design engineering, and also how that slots into things like competency frameworks, and at what different level should what designer be doing what sort of design engineering.

[00:28:21] Sonali: And I guess, when designer, product and engineering lines are being blurred, where do you see your role goals in the future? Should we be worried, or who should be worried?

[00:28:36] Ella: Spike, do you take this question right now?

[00:28:41] Spike: That's a very good question. Should we be worried? I don't know. I think the people who should be worried are the people who aren't open to working outside of their roles and bringing people along on the journey with them. Don't hold on to your Legos. Let people try things. You've got to experiment, and everyone's along for this ride, no one knows what's coming next.

[00:29:01] Spike: And I think the really important thing is just to bring people along with you. If coding doesn't become the thing that you have to yourself, share it around, let other people do it. I think that's just where I'm coming from, and that's where you should keep your perspective, at least for right now. You don't know what next week's going to look like, so why not share everything around, bring everyone along with you, and champion this new way of working.

[00:29:33] Sonali: No, absolutely. And I think the example that you guys have shared about cross collaborating, I think that's the perfect example of how you are learning from each other, and how, Spike, you're leveraging Ella's design skills, and vice versa. So yeah, it's absolutely amazing, and I would like to chat more about how I can use those things.

[00:30:01] Ella: Yeah, so happy to.

[00:30:03] Sonali: Awesome, thank you so much guys, I think that's it. It was lovely to chat with you and understand what you guys are doing at Tracksuit, and thank you so much for today.

[00:30:18] Ella: Thank you so much, Sonali. And lovely to meet you, and thanks for having us.

[00:30:22] Sonali: Thank you so much.

Speakers

Ella Moran

Ella Moran

Senior Product Designer