How AI is Transforming UX and Agile Teams with Nick Cawthon

In this episode, hosts Peter Maddison and Dave Sharrock sit down with Nick Cawthon to explore how generative AI is revolutionizing the relationship between UX, design, and agile development.

Key Topics:

• Embedding UX research into agile sprints, balancing short-term feedback loops with long-term strategic insights
• The "electric bicycle" analogy: How AI gives teams superpowers but can also accelerate you in the wrong direction
• Why Nick believes he'll never use Figma again, shifting from design tools to code-native prototyping
• Building functional prototypes using company design systems and generative AI tools
• The evolution of team size: From 6-8 person cross-functional teams to powerful 2-3 person teams leveraging AI
• The architect's mindset: Understanding the technical foundation before designing the interface

Three Key Takeaways:

1. What an incredible opportunity we have; it feels like the year 2000 again, with the excitement and disruption ahead
2. Small teams (2-3 people) with diverse perspectives can now move incredibly fast using modern tools
3.  Speed is powerful, but you still need feedback loops to ensure you're building the right thing and not racing in the wrong direction

Connect with us: Website: https://definitelymaybeagile.com/ LinkedIn: https://www.linkedin.com/company/definitely-maybe-agile-podcast Email: feedback@definitelymaybeagile.com

Chapters

• 0:04 Meet Nick and today’s focus
• 1:10 UX inside agile teams
• 2:39 Building fast feedback loops
• 4:20 Balancing short and long cycles
• 5:39 Systems, patterns, and reuse
• 5:39 Common early UX pitfalls
• 7:00 Entering a new team well
• 8:03 Learning the stack to design right
• 9:35 Why UX is now embedded
• 10:47 Generative tools blur roles
• 12:14 Real impact vs vendor hype
• 13:08 Prototyping with real components
• 14:47 Designers starting from code
• 15:53 Coherence, guardrails, and oversight
• 16:31 Experience over feature lists
• 18:33 From patterns to true experiences
• 20:12 Code-native design beats mockups
• 22:55 Team size, skills, and clarity
• 26:04 Three takeaways and closing

Transcript

Peter: 0:04 Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello, everybody. It's nice to be here again. I'm here with Dave, and we've got a special guest today, Nick.

Nick: 0:19 Oh hello.

Peter: 0:21 Would you like to introduce yourself?

Nick: 0:23 Hi, I'm Nick. I'm calling from the San Francisco Bay Area. I'm pleased to meet you, and can't wait to hear about what we're gonna discuss and share.

Dave: 0:33 Likewise. Where do we want to begin? I've got lots of questions because I'd love to learn a little bit about what you do at Gage in particular. You talk a little bit about UX and research, but maybe to kick things off, we're definitely maybe agile. The podcast, we always touch on something around agile and things like that. And agile and UX, certainly I would say probably Peter as well. We've both experienced a lot of teams that work really, really well embedding UX into their agile teams, and other teams that really kind of struggle to bring the skills into the teams and how they're performing. And it really becomes one of those oddball conversations where it's unclear how to embed UX into the agile delivery process. What's your experience or your recommendation in that space?

Nick: 1:23 Yeah, that's a great launching point for a conversation because you're right. As a consultant, I come into many different organizations and see different levels of aptitude as well as desire to bring in UX or user research into an agile process. Oftentimes I sit alongside product managers and engineers, and then as the role of a researcher or a designer, need to begin to advocate for the user on a sprint basis. But sometimes research takes a long time, and it takes time to synthesize and try to understand some of the bigger machinations at play. And so when you are in your sprint planning session, sometimes that can't be actionable just quite yet. So, how do we build processes that allow us to have some of those more shorter insights? And when I come into engineering-specific organizations or engineering-led or founded organizations, oftentimes you're beginning to establish those feedback loops so that on a constant basis you can have focus or attention on different things. And that means opening up your calendar to a user base or a customer base that's willing to give you their feedback. And it's wonderful to formulate a relationship with the brand and an investment in the product. And there's no sales involved. I mean, you may be giving them a thank you gift for sharing their workflow or their screen or their frustrations with you, but you're not trying to upsell them on anything. You're doing it both for the sake of a product that they invest their time in and that you've invested your career in. And so with those faster feedback loops, with those cycles of, hey, do you know where there's something that we're talking about next sprint? I want you to show me how you use this. And then they go and they click and they show those errors or those roadblocks or points of frustration, which are exactly what you're trying to address. And those can be a lot more actionable on a shorter term basis than maybe some of the glacial persona and definition and pivots around product and positioning that we're used to that take a lot of engineering time or product management requirements that need to be baked a little bit more fully. But it all starts with a healthy, user-centric process and a research team that's willing to undergo, collate and conduct that research.

Dave: 3:40 And do you find it's good for the UX and the research to sit close to product, close to the team? Do they alternate? What's your—again, so there's this really interesting thing about short cycle time, long cycle time work that gets done. In some ways, embedding on the team is just going to lead, I assume, or we've certainly seen to a lot of short cycle time conversations about minor, minor—they can incrementally build quite significant changes up, but they're not that long-term really understanding the customer's behavior, what their needs are, and so on in the same way.

Nick: 4:20 Yeah, a marathon is not a collection of sprints. Exactly. A marathon is a paced event that one should have the mentality that they're undergoing a marathon when they join any company, not that they're undergoing a series of two-week sprints that seems to go on forever. So that short and long-term mentality, I think that's the role of a researcher or even a UX designer, where they're understanding how they can unlock things in the short term, and that may be as simple as interface design or legibility, or UI, or advising on copy or workflow, and to be reactionary when blockers come up to play or questions come from the developers or review needs to be accomplished. And then there's the long term of understanding how it all fits into the bigger picture from a design perspective where that goes into patterns and system-based design and components and making sure we have reusability for our interface, which benefits the developers in the sense that they don't have to create any new code, they can repurpose old ones. And then also from the end user who can now see consistency in an application as it's been developed, so short and long, synthesizing where the product is going from a directional standpoint, but being reactionary on a sprint-based pace.

Peter: 5:38 Well, what are some of the common problems you start to see when you first start interacting with the teams and sort of bringing some real UX to the table, if you like?

Nick: 5:48 Common problems from our perspective is an impatience to want to get things done or to envision if I first do this, then it'll lead to that, which will open up something else that can start to really build upon itself as a continuous improvement cycle. But that takes patience and clarity and understanding of the technology to know it's not just easy as waving your hand and redesigning a workflow. There's underpinnings of data structure and all those different kinds of application-specific development concerns. So I've often struggled with that, and that which the customers may be complaining the loudest about may not be the priorities of the engineering team that has to pay down tech debt oftentimes before addressing new or existing features to understand the weight of developmental constraints is also something that UX design and research teams have to really comprehend and allocate for.

Peter: 6:50 What sort of approach do you start to take when you're starting to work with that new team then and starting to say, hey, what am I gonna—what do I gotta do first?

Nick: 7:00 My approach is always to get good at what they're doing. I worked for an organization called NPM, which was Node Package Manager, and it was a DevOps tool in which you could install libraries and have it built into other libraries. It was one of the, and still is, one of the most fundamental parts about front-end development was being able to bring in pre-built JavaScript components and have it fit into others. But it was an organization that hadn't done any research, and as the first designer slash researcher to be able to educate on that process was something that I needed to facilitate, as well as to educate myself on their process, was something that I also needed to do. And so my first attempt was like when I submit myself to this company as a resume, I'm gonna do it as a node package. And I'm gonna create an account and I'm gonna create a JSON structure of my education, my experiences, and all these things. And when I submit a resume, it's gonna be in the form of their product syntax. And it worked wonders, but it was a testament to the willingness to adopt and understand the underpinnings of the technology. If I was an architect and you asked me to build a site, a house for you out in the desert, I would need to understand soil and humidity and winds and environment and whether or not people stayed inside or outside before I could design a house. And I think the same thing is true with UX and design as it comes on to engineering-focused applications and teams, is that you've got to really know where that house is being built in. Is it gonna be tall? Is it gonna be short? Is it gonna have air conditioning before you start waving wands and making things look better?

Dave: 8:47 And that almost speaks to the fact that you can't simply look at better funded competitors and go, okay, we're gonna steal what they're doing and try and replicate it over here, because of course there's that whole other side of it, which is how does it embed with how your organization works?

Nick: 9:07 Yeah, absolutely. We looked in that NPM example, we looked at GitHub quite a bit of how they handled repositories and access management and organization versus single user relationships, name conflicts. There was a method in place, but again, as you said, GitHub was an entirely different company than this 12-person startup pre-Microsoft acquisition that was just trying to make their way in the world.

Dave: 9:35 Now, I think the days of using UX have really grown a lot in over the decades that we've all been working in the space. Now I think back to way back in the day, I remember Jakob Nielsen introducing the idea of usability and website design and things like this. And now we're in a world where it's more and more common to have UX actively in the organization on the team rather than this—maybe a company that we go and look to or something that we do once every few years. What's driving that? What do you see as driving that?

Nick: 10:13 I mean to stick with that architect example. If you've ever done a major remodel, to take the plans from the architect and say, see you later. The abstraction versus reality gap is a very real one. And if there's a set of plans in place or a set of designs in place, it doesn't mean that when they built this house, that there's not a need for consultation of what happens here or how does this work or what we thought the permit would allow it doesn't. So, how do we adjust from that? There's still that need for interpretation of what the actual site will be versus what it was designed to be. So there's always a gap between design and development. That's an interesting conversation to go into now with all these generative tools, whereas any designer can be a front-end developer if their prompt is good enough. And where do those roles start to blend? And where does that value continue to come in from each respected parties? Where now the opposite is true, whereas every front-end developer can be a good UI designer if their prompt is written correctly. And so now we find that kind of balance and delegation of tasks and responsibilities even more blurred. And I'd be interested to hear your thoughts on what agile teams will have to do to adapt to we're all swimming in the same IDE now and have these newfound superpowers.

Peter: 11:36 The SDLC as a whole starts to change significantly once we introduce these tools across all of it. And suddenly you find that one person can do a lot more across a lot more domains if they've got the right prompts and agents and tools in place to be able to extract the right information. Doesn't necessarily mean they'll always get it right. And a lot of the time we're what we're seeing—some of the more recent reports is that the very big numbers that the companies who are selling the tools like to boast about are not what we're actually seeing on the ground in the actual development teams working with the tools, but they are having a massive impact. It's—I know I mean I use them regularly to build sort of POCs or small tools, and so like it works great. It's like you can just say, yeah, here's my branding palette, these are all of the rest of them. Go build me a front end. I need it to do X, Y, and Z, and away it goes.

Nick: 12:35 Yeah. Here's the IBM Carbon Design Pattern library. Here are the components that you need. You want to write it in React. Here it is in React. And by the way, don't install anything. Let me lock the package.json file so use only the guidelines and the ramifications that I give you. I've had an engagement with a Fortune 100 company in New York, where I was brought in by the head of product because he couldn't get design resources, they were all tied up on public-facing things, and yet his internal tools team was stuck and things were broken, and they needed to address a workflow that had long since been ignored. And because as a contractor, I had an email address and access to the GitHub repository of the pre-built code components for their own proprietary design system. I took those and built out using a Google Sheets as a database to fill out a POC or a prototype of how the workflow will go. Again, it was really data heavy, rich internal tool. But at the cost of if somebody made a mistake, it would be in the millions if that deal or assembly got done wrong. The rework and the retribution for that was extremely expensive. And when presenting that to the traditional design team to say, hey, I skipped over this whole drawing process and approval of new components, and then the component gets given to the front-end team, and the front-end team has to develop the component because I'm only here for a couple months, and you have had this design operations workflow that, however, hygienic is also extremely slow. What I'm doing is starting at the end and building the prototypes from that, using those to test and validate and hand over to the front-end team to say it's using your version of React of Tailwind, and nothing's changed in your package.json file. But here's how I built it out. You just need to change it from Google Sheets to Postgres. And you should have a fairly good assimilation of validation, logic, error conditions, flow, loading states, all those things that make the web a good experience or a bad experience. So that's how I'm seeing disruption in these teams. As now I'm starting to push designers out and saying if you can get to the code base, you can use that as a model for which to start to design from.

Peter: 14:56 Yeah, yeah. The understanding of code, just being able to run it against it and then use that to extrapolate or say, okay, what's the next thing I need to build? Creating context at scale across very large complex code bases is—yeah, it's definitely an area that seeing a lot of progress.

Nick: 15:13 And don't forget version control. I was smart enough to clone it and then work within my own repository. But if I'm ever having to push things up with approval, that's where things get a little bit riskier.

Dave: 15:27 I find it interesting that you end up making everything more available because we're now no longer dependent on getting either identifying who it is in the organization that we need help from or finding the resources to be able to go out and get something, you can actually, whether it's on the coding side, on the product discovery side, wherever it might be in the process, you can now get a lot of help in coming through and like that creation. Do you see just with that? One of the things that we're certainly seeing is the need still to look for coherence and congruency with what gets built and make sure that this is really solving the problem that we're looking for, and it isn't taking some sort of middle-of-the-road path. And that sort of that almost not approval is the wrong word, but the oversight to make sure the end goal isn't being lost as a lot of these problems are being solved more rapidly with less of that formal process in place.

Nick: 16:31 Yeah, the analogy of these generative tools I like to use is an electric bicycle, which the first time I had the aha moment, it was the same feeling of being on an electric bicycle with a throttle for the first time to say, oh my goodness, I've got these superpowers and look how fast I could go. But you can also go faster in the wrong direction. And if you find yourself with a flat tire or a dead battery, all of a sudden the way to get back is a lot further. So you got to understand the knowledge of the bicycle, which means the things about the version control and the code base and design pattern, all those things that help us pedal along our design and development workflow. But hopefully the map that you've gotten from your PM or your product lead is the correct one, is that you're trusting them to steer things in. And I know it's an easy answer to say, well, that's product's job or that's project management's job, and so I shouldn't have to worry about that. And I don't mean to be dismissive about it, but that's the value that they bring in. If design and UX is bringing a human-centric approach and talking about these different elements of interaction or product workflow, and that's where our value is, then the same thing should be true with prioritization and anybody that's responsible for the reigns of the product itself.

Dave: 17:49 I was actually at a conference last week talking a little bit about generative AI and where these things are going, but also about some of the expectations that you can have as you're using these tools to build things out. One of them is to focus on experience over sort of maybe unified or focused experience. So each individual is having their own experience versus just features and making sure that you can do lots and lots of things. So that idea of less of a marketplace of opportunities to go do things, much more tailored and much more experience driven. Is that, would you agree with that sort of observation?

Nick: 18:32 Experience driven has the mandate for the last 10 years as UI became redundant and commoditized with the advent of freelancing platforms or design libraries. Project Kennedy created one for Google. Apple followed suit because they saw that on these mobile devices, that from the early stages, developers were creating their own design patterns. And it was wonderful and quirky and subjective, and each had their own, but it diminished a brand value because if you went onto the Apple store and just installed these sort of junky looking apps, the legibility was poor, and it reduced the perception of the applications that were built upon the Apples and the Androids of the world. And so the concept of pattern libraries and systems design thinking was that inception of let's make all Google products look like a Google product, or let's make all Apple experiences look like an Apple experience. It also kind of had this perception of UX was, and if you think about the early reactions to the Apple products, well, it just works. It's an Apple or a Mac, and it just works. And what does that mean? That means removal of information, contextual displays of data, affirmations of progress, and sort of making people not feel anxious with the Oracles and the Sun Microsystems of the world. If you showed any sort of aesthetic or emotion, it gave off this impression of not bringing enterprise scale built by engineers for engineers. And that was a horrible place to be in in the early 2000s, where we were just sort of sitting through installation CDs that were like completely unintelligible of what was happening. But things changed with the iPhone and the mobile and the design patterns. And then the onus became on us as the designers to expand our capabilities into experience research and qualitative interviews and understanding of data and surveys and how to synthesize and recommend where we can improve from here. And so, yes, I think the experience is a really big part of how we go from an abstraction of an idea or a design into the implementation of a pleasant product.

Peter: 20:43 Yeah, that makes an awful lot of sense. It's interesting to hear you talk about sort of that evolution that we've been through from the sort of early 2000s up till now. And, as we were talking about earlier, like you can pull this in and start to create products very easily on some of these platforms now that you can just pull on those resources and pull them in. Even things like Figma, for example, and being able to use like DevMode to create the snippets of this is what the design should look like, and then feed that into the Gen AI system to have it build out what you need.

Nick: 21:17 Yeah, it's still in its alpha though. Figma is trying to pivot hard, but again, it's meant as a design tool where tools that are code native and can understand components rather than snippets I think are gonna outpace Figma. But I've been doing tools like Figma for the last 20 years, everything from Visio and PowerPoint early on into the more design-specific softwares, and we reach this wonderful place of productivity with Figma. It's the sort of the lingua franca of my field. However, I'm never gonna use it ever again because now I can figure out what a code representation of something I want to look at from an application level would be. And I would rather train design patterns in code than push and pull and draw on design because it's closer to the truth than the abstraction.

Peter: 22:13 Yeah, I've been wondering about that too. The—you can go to a tool like Lovable and have it just generate that front end for you and it's fully interactive. Yeah. Versus having to design it in Figma and then have that feed into the build system.

Nick: 22:30 Yeah, yeah. It—you know, maybe from a high level, sort of I want to see the entire ecosystem, but at that stage, pencil and paper is just fine. You don't need to—you don't need to display all the fineries of interaction at that sort of storyboarding phase. That can still be scratch or even in Miro or some diagramming software. Because, as you mentioned, if you go into one of these generative tools, Magic Patterns is a wonderful one that's great for wireframing out interactions and then it will translate it into a repository. And that is the level of fidelity that you want to get from a prototyping phase. And with that validation of a user, you can put these in front of your users to test. Does this match your expectation of what this is supposed to do? And from there, that translation into real component development is not a hard one.

Peter: 23:23 For sure. So Dave, any more questions?

Dave: 23:27 Yes, I'm waiting for you. Can I—and maybe because I know you're just going to do the wrap-up thing in just a second. And I was just, as you've both of you have had this conversation, so maybe this is an open question to both of you, which is nowadays when you go in and see a delivery team, a team that's responsible for building product out the way traditionally we've been doing over the last decade or two, what do you expect to see on that team? Whether it's like, is it the same six, eight-person team with a cross-functional team? Are you looking now at two or three-person teams? I know, Peter, you and I talked about these one-person teams recently. What do you see on a team that's using the tools and the practices that we've been discussing compared to what used to be a normal, quote-unquote, normal agile delivery team?

Peter: 24:19 Well, we were talking about this recently, right? The idea of the pizza team and the team as a small entity because of one of the things we were talking about earlier, is that you can have a broader—the tools give you a broader access to different domains. So your—the need to have that front-end and back-end expertise, potentially you can become more of a full stack developer, although I think there's still a long way to go in a lot of these things, but there is a lot more capability to cross domains and to gather information in different spaces and use that to feed into other areas, meaning you can get more done with a smaller team potentially.

Nick: 25:04 I'd agree with that. As long as the word clear about what each individual is responsible for bringing in. If again, my world is trying to validate opinion or being curious about thought, and then spinning up and building research cycles that can provide that. And then product, I'll let your interview with product speak for itself, but that kind of collaboration and all these magic promises that I've given you about upending the design process are only possible because I have a front-end engineer on my team who's helping me figure out my rebase conflicts and where my JSON file needs to be. Like I need that kind of education and amnesty around I don't know how to use these tools. They just came out. So take that with a grain of salt.

Peter: 25:58 Awesome. So at the end of our podcast, we're gonna come up with our usual three things. So I'm going to let you go first, Nick, as the guest of the day. What would you want our listeners to take away from this conversation?

Nick: 26:12 What an opportunity we have. If you had asked me 18 months ago, my sort of lay of the land—like, you know, Bitcoin is still around and NFTs, people are dabbling in blockchain. Haven't really—you know, I know there's things happening, but it hasn't really affected my daily life. I don't see the broad impact of it. But today, wow, it—you know, it feels like 2000 again. It's really disruptive and exciting. There's all sorts of discussions around climate and ethical impacts of these technologies that from electric bikes to prompt engineering, that we're starting to figure out its intended use. And so what a fortunate time we have in front of us. So take away that—being gracious that we have these opportunities in front of us. That's my first one.

Dave: 27:08 Dave? I think I'm gonna build on top of what Nick's just saying because we've covered a number of things in the conversation. I really loved a little bit about what we're talking around, you know, the long cycle, short cycle challenge of UX work and integrating with that short cycle delivery on the one hand. But the thing that's sort of spinning in my head as I leave is the impact two or three people can have using that landscape of tools and opportunities because it's not an obvious place where to go for the tools, they're changing as rapidly as we're talking about them. But there's something to be said for that. Two or three people bringing different perspectives into a conversation and being able to move very, very rapidly to get those out in the open and start getting feedback and things like that. It's just I couldn't agree more with where Nick's saying going on that one.

Peter: 28:04 I think I dare you to say something else. Yeah, Peter, let's go for that. Because you just mentioned going rapidly, we did talk about that too. It's also still very possible to go rapidly in the wrong direction. You need those feedback loops and you need to understand like what is this the right thing I'm building? Is this—it still has to be a market for it? You still have to figure out is this working the way that it's supposed to? And collecting that feedback, understanding like, is this valuable is another key part of it too. So you don't go rushing off in completely the wrong direction. Well, with that, I'd like to say thank you, Nick, and thank you, Dave, as always. These conversations are always fun, and look forward to next time.

Dave: 28:45 Until next time. Again, thank you very much, Nick, for joining us.

Nick: 28:48 Thank you. Have a good weekend.

Peter: 28:50 You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital, agile, and DevOps at scale.