From Napkins to Agents: How AI Rewired Product Design

Hi folks. Welcome to Engineering Evolved. My name is Tom, and this podcast is all about how we deal with engineering challenges in the workplace, and how we can improve some of the stuff that we're doing when it comes to optimizing processes and procedures, and doing stuff right. And so I have brought along today Amelia Prasad, who works at Concept to Cloud as our director of product. And we're gonna talk about how AI has changed her workflow from a very manual process into something that's more automated, but obviously the good parts of that, the bad parts of that, and everything goes in between.

So before we get on with that, I'm gonna let Amelia introduce herself properly. To you, Amelia. Okay. So as you said, I'm director at Concept to Cloud. Uh, I've spent my career building zero to one products, um, usually in mission oriented work, uh, heavily focused on regulated data heavy environments.

Before I worked in product, I worked in, um, astrophysics and climate science. Um, and so I've always sort of kept a focus on mission focused work. Yeah, and so now I build with, uh, you at Concept to Cloud and deliver an array of products from anything from healthcare to fintech, um, or just fun stuff. So yeah. We do like the fun stuff.

That's cool. Okay. As we sort of look at how the, um, the, the processes have changed over years, can you give me a little bit of insight into what, like sort of pre-Claude, pre, uh, LLMs, like what your workflow looked like from a, from a UX design, a research, and a product build out perspective? Yeah. So before Claude, you know, you could put in a prompt and you could get information on anything.

So you, you would have an idea. Let's say you had a product idea that you wanted to build, you'd have to go in and you'd have to do a lot of manual research, right? Reading articles, compiling information. Then, um, you would have to do everything in like a rigid order. And you know, to some extent that's still true, but you would have to look at, you know, competitive analysis, like what else was out there, and you'd have to go through a lot of the stuff, um, manually.

Like if you, if you had a competitor product, you'd have to look at each product, see what they offered. Um, and it, and it just wouldn't be auto- auto populated like it is with Claude. And so the workflow would end up being, you know, you do the manual research, you draw up the wire frames, and you really had to do a lot of preparatory work because before you could design anything, you had to make sure all of this was squared away because the design aspect would take a lot of time, and so you wanted to get it right. Whereas now you can kind of just throw something at the wall and hope for the best and fix it before the end of the day. So yeah.

Okay. Like prior, prior to the way that you work now, we're talking an awful lot of note taking and human based research, I guess is, is a lot of what was going on. Still is to a degree, I guess. But like, you know, allowing for that to happen and then like what, um, what tooling did you use outside of a notebook to be able to like, you know, build out these product designs? Yeah, so you, you'd use like a mix of things.

I mean, primarily obviously for design, like you'd use Figma or Sketch or Adobe XD if you were feeling daring. But you would have to use like Miro, you would use things like Maze, you would compile your research. You would use a lot of sticky notes, like whiteboarding things. There, there's a lot of value in UX work for keeping the tooling very rough because it would keep a UX designer from becoming too attached for, from showing something to a stakeholder that looked finished. You always wanted to keep it in motion, and so the tooling needed to stay somewhat primitive, and that was intended as insurance to make sure that the product that you finally decided to put the effort into came out to be, um, a well thought out product.

So yeah, in, in that regard, the tooling, you know, in terms of software, like yes, there's Figma, yes, there's note taking. You know, people are using Google Docs, they're compiling their notes from interviews. They're using Mir- and I'm sure a myriad of others that have maybe fallen to the wayside now, both in use and in memory, but a lot of pen and paper. Um- So when it came to, um, working with customers, working with, uh, clients and, and that type of thing, like pre LLMs, there'd be a lot of like research, note taking, Figma build out. Would the mock-ups and the prototypes largely be done inside of Figma to be able to give people an understanding?

Or would you use, again, still like, uh, notebooks for, for, for rough mock-ups? How did, how did that look? If you're doing rough mock-ups, and I, and I feel like this is sort of a lost art form, there is a lot of value to, uh, back of the napkin drawings and paper mock-ups, right? Before, like really before you invested any of this time in sort of drawing boxes in Figma, you would iteratively, like you would storyboard, you would write it out on pieces of paper. Just, just, just like get the broad strokes down on paper first.

Go through that with like a small subset of people, and then continue to iterate on that, uh, before you would go into any sort of, um, sketching or any kind of programmatic environment, just because of how much time it, it used to take, um, you know, for any UX designer. And because UX was so broad, like, you know, you, you, you may at, at the time there's a limited amount that you could do. Each of these things took so much time. So you may have a UX researcher doing the wire framing and the prototyping on paper, and that might be handed off to like a different person, whereas now like you can, one person can go from end to end. So yeah.

Okay. That's cool. So, uh, for, as a disclaimer for anybody who is listening, we met each other working on a project at Princeton University, which was all to do with social media and collation of data. Um, and I think that's sort of where we both got our first insight into LLM usage and how it can tweak, change stuff. And this is well before Claude Code and Codex and all that type of stuff existed on the market.

But I feel like at that time it sort of started to give us some exposure as to what you could do to be able to rapidly prototype stuff. Yeah. So like how, uh, uh, as in, in your, in your mind and the way that it worked for you, that, that, that transition from, uh, back of the napkin stuff through to where we are today, what's changed, I guess, um, over the course of the last few years? So yeah, so it was transitional, right? You didn't go from back of the napkin to Claude Code to what you have today, where you put in a prompt, and all of a sudden you can get an application.

The earlier uses of it and, you know, we, we did this together, but, like, the earlier uses of it were for tooling, were for small bits of how could you automate, like, the administrative processes, right? So, like, how could I take my notes and have, like, ChatGPT or Claude Code, like, disseminate, you know, what the notes were? Or, um, early versions of Miro, like, how could I cluster my affinity maps, things like this. So, like, the, the, the progression really in the last year h- you know, it really started from AI workflows before AI building. And so one of the first things that, uh, I worked on or that we created, that I requested, mm, with the help of the engineering team, was a notetaker.

I was doing interviews, and I was doing walkthroughs, and as a UX designer and doing UX research, you're, you're talking to someone, you're navigating the walkthrough. You also want to take notes, and you also want to, um, be present to the person that you're speaking with. And so on this project at Princeton, I'm speaking with researchers that know topics across just a myriad of, of industries from the information environment. And so you really need to focus and listen to what people were saying. So, so what we did was we created, you know, a notetaker that I could just tap a little button during my interviews and say, "Okay, take note of this.

Take note of this. " And, and it, and it removed the cognitive load of me having to, like, manually remember to type in everything while also trying to pay attention to the person in a fast-paced conversation. Yeah, so, so stuff like that was very useful early on. Um, and so it, it, it started to treat different areas of UX design before, you know, Claude Code or ChatGPT or whatever you use developed into something where I could make a platform from beginning to end. Lovely.

So moving on then from sort of basic Claude interactions and mocking up, like, some of the stuff that we did in terms of the notetaking, uh, tooling and what have you. You know, moving on now to something from a workflow perspective that I suspect was quite alien to you back at the start of using Claude Code, because obviously Claude Code, by definition, is supposed to be something that allows for developers to develop, but also we see Cla- Claude Cowork, which came out of that because they realized people were using it on the desktop processes and not just back end stuff. So yeah, as, when, when you made the switch from using just the Claude web app chatbot thing to Claude Code, um, I suspect that was, that was a step into the unknown again. Yeah, absolutely. So I'm not a developer in any, in any measure or knew a lot less about development at that time, right?

And so, um, using Claude Code, I heavily relied on you, I heavily relied on members of the team. Like, I didn't even know what, um, GitHub was. I didn't know how to, like, do version control, any of this. So stepping into Claude Code, it was just like, A, I had to learn a little bit of how to create that structure, that work environment for myself, completely, you know, different from Figma. But once it got going, it was, you know, it was much better at the time than, than using Figma.

It was much faster. I don't know, like at, like at that point, and, and I think there was some tentativeness, right? 'Cause now you have a designer that's like, "Oh, well, I wanna code this, and I've made this thing, and now I'm developing. And what does this code look like? Is this, is this something that I can pass over to my front end developer?

" Right? Is that something that they like? Was it good enough at the time? Did it go through, you know, all the proper checks? Did it have testing?

Was it, you know, linted? You know, I still don't use the terms properly. But yeah, like, uh, it, it was a huge thing. Switching over to that environment, it's a change of mindset because you're no longer, you're no longer working on an infinite canvas. You're now working in sequence.

You have to put everything in in sequence. So you really have to have a plan of, of what you want to do, of how it needs to be built. You will need to understand things not from a, "I'm gonna draw it on canvas or draw it on paper and structurally build it properly later. " If you're gonna be efficient, you need to understand structurally, like, how to build what you're about to build. And, and in that regard, like, that is something where I think still you need the experience of building products to use any agentic tool properly or efficiently.

I don't know. I don't know what that was like for you either, having a designer come in and be like, "We've built all this stuff. Here you go. It's done. " Well, I feel like there's, there's, there's a few different aspects to this, isn't there?

Because there's the positive aspect in a small team especially. I think this, this is a scale thing as well. In a small team where you can have a designer who also can build code that uses the same frameworks as whatever the application is gonna be, then that gives that team the ability to move faster, move forward faster and quicker and more efficiently, because some of that can be handed over. But I feel like there does need to be a decent handoff between what the expectations are from the developer to what the designer is designing to make that efficient, because otherwise you're just gonna tear it down and start again anyways. So I think on a small team, there's an awful lot of ability for a designer just to hand over code that can be tuned up, tweaked, improved.

Um, but we also, I feel like we found with some of the stuff that we were building out, that you also hit the limits of what the designer can do inside of Claude Code because of the lack of guardrails and checks and balances that go around it. Because at the end of the day, you're creating a fully fledged application. It's not a mock-up anymore. But at the same time, Claude isn't necessarily clever enough to be able to discern, like, whether or not to do something and what knock-on impact it's gonna have. And of course, various contracts we had, we've seen that happening with developers, let alone designers.

And so that... There's, there's definitely a, a trade-off there as the applications become more complex as to how to make that work for everyone. Yeah, no, that's very true, because that is something that I ran into, and my frustration was very apparent. So as, you know, as a designer, like, you have an infinite canvas, and in your mind, you have an entire idea of the way the flow of something is going to work, and you start to build that in Claude Code, and you don't know that you need to tell... You don't, you don't know at the time that you need to tell it to refactor your code, that you shouldn't have a file that's, like, 6,000 lines long or something like that.

And then it, you tell it to do one thing, and it, and it breaks the rest. It didn't understand what, you know, context was. It didn't understand Claude skills early on. Well, I don't even know if they existed early on, right? Like, like, all these, these rules weren't in place.

And so it's a, it's a twofold thing. It's a designer can create something that's very bloated, but a designer being a designer is going to create, like, a number of different options, which can then be a bottleneck for the developer. And then, yeah, like it just You know, a designer is going to need their engineering team to educate on, like, how to engineer or productionize code or how to do things properly. And, you know, there, there weren't those guardrails there. There's no education, or there wasn't at the time, in Claude Code into how to build something properly.

And, and, like, you know, that's fine. That's just the nature of technology. But it wasn't there at the time, and so it would lead to a lot of frustration. You could try it out and, and a lot of designers would say, "Well, oh, you know, this isn't great. It doesn't build things exactly like how I want it to.

" And they would err... They would prefer to stay with something that they could build very specifically. But, but if you really wanted to get something out quickly, if you were doing-- if you were creating an idea or platform that was somewhat unique, that wasn't like what we were doing at Princeton, it was new, it had never been done before, to be able to create a visual of those ideas for developers to build off of, you know, it becomes very important or very valuable to have those broader ideas. A designer doesn't necessarily know how to say, "Well, these are the acceptance criteria for what I'm building," right? They don't know how to say, like, "If this, then that," right?

They, they, they know how it works, but, but... And, and this is not, this is not a Claude Code thing. This is just universal designer to developer handoff issue that's always existed. But yeah, I mean, and like when, when you're working on a small team, like the value of it is, is infinite because you can show, like, new ideas to the team. Whereas if, you know, we were a larger team, like I could have done smaller pieces at, at a ti- you know, smaller pieces.

So in that regard, in that regard, Claude Code was sort of a, a challenge, both for making sure you didn't bottleneck for your developers, but also to make sure that you could build things to the scale that you wanted to build them without it breaking every single time, so. Which it's much better at now. It's true, but there was-- there's always been different options, though, haven't there? Because, like, on the market up until, well, on the market still currently, um, apps like Lovable, which give you the ability to knock up full, full applications, but without having to understand all the bits that go on under the hood. Did you, did you try experimenting with Lovable or any of the other adjacent apps and, you know, what did you find there?

I did. I d- I did try Lovable. I tried, um, some of the others. You know, I tried Cursor early on. Um, probably worth a try again.

I think with those apps, the, the danger was... Not danger, but the drawback was those apps were basically just built on top of ChatGPT. They were built on top of Claude Code, and what they did was they created a UI that was more digestible for it. Like, and this goes back to the other question. It created a UI that was more digestible or recognizable to a designer.

But equally, it was much slower than actually taking the time to go into Claude Code directly, like to work in your terminal and to build. And this I found really frustrating, right? If you invested maybe like a week or two of just like choosing to, you know, make your mind a little more adaptable to working in a coding environment as opposed to UI environment, you kind of got the best of that world. But if you, if you worked in a, in a wrapper or something like Lovable, and, and not to, to write Lovable, but, uh, you got this middle ground that was always gonna be a step behind whatever Claude Code, Claude Code or Anthropic or, um, OpenAI was gonna develop because they were doing this as derivative work. And if what you wanted to do is, was stay ahead or, you know, be efficient about your usage or really understand like a cutting edge tool, you weren't gonna get that with essentially like a third party app.

It's just like, you know, first hand information versus playing telephone. And using things like Lovable, you know, there's so much... I, I haven't used Level- Lovable in a few months, so I'll, I'll caveat it with this. I don't know what it's like now. But it felt like there was a lot of bloat to the software.

There was a lot of rate limiting that didn't exist if you worked in the direct Claude Code environment. But that is a big ask, uh, for some, you know... It is a big ask for designers. You know, it's always a big ask for someone to switch their entire work environment at the speed that, you know, agentic workflow is developed, um, which was very quickly. And to go from, you know, drawing things in boxes in Figma or working on paper to just saying like, "Here, now work like a programmer.

You know, do everything logic-based and not instinct-based, and, you know, convey the structures that you have in your mind in a way that a programming language can understand," it, it's a, it's a lot to ask of really anyone, particularly at that time. So yeah, using things like Lovable, using third party apps, my experience with those, uh, not great overall at the time. Just, just not great. It was just like getting watered down, watered down ab- ability. So you talk about being rate limited and that type of stuff using Lovable as an application build out.

But, um, obviously now there's Claude Design now, or Claude Designer, whatever they call it- Yeah... 'cause I've seen it in the desk- in the app. I've never used it, but like, would it not make more sense now to be able to, rather than Claude coding on the desktop, to use something like that to be able to build out what you needed to be able to build out? So I've tried, I tried Claude Design when it came out. Uh, I'm sure it's great.

I think with Claude Design... So, so this is where I'm at now. Using something like Claude Design is great. It uses a lot of tokens, you know, and it, it, it uses the models that use just a ton of tokens. And, and I, I haven't quite hit my rate limit because I don't use it extensively.

But it feels like for, feels like, I'm not saying that this is the case, but for the amount of token usage that happens, it's really feels like diminishing returns. Because it doesn't, it doesn't feel like Claude Design still fully understands how to product design. It understands how to web UI. It doesn't understand how to product design through, like, what a designer might do that is a workflow of, like, this is how you, you know, do your happy path. This is how you get from complete this whole task from A to...

Claude Design will make you a page that feels very static, but the amount of token usage, the amount of prompting you have to do to get something good out of it doesn't necessarily feel worth the return. So at the moment, I'm still working in Claude Code. There are still tons of tools that I need to work with, I, you know, and try out. But what I'm experiencing now is that because there's so much heavy token usage with diminishing returns, I'm now trying out Figma's MCP, which, which initially could only write to Claude Code, but now there's a capture to Figma that goes back and forth, and it It, instead of working in one particular tool, it now feels like there's a complete anatomy or suite of tools that the, that the real design work is learning when to hand off to each tool. Use your MCPs, export things as you need to, but learn to hand off between tools to know which tool does what better.

And equally, just from a personal perspective, token usage is something that has environmental impact, right? So if you wanna be conscientious about your workflow, your work environment, what, you know... Like, I don't wanna use 150,000 tokens to make a hero section, right? Like, I can do that pretty quickly in Figma. I can also do it at lower cost as well.

So I mean, the, there's just a lot to consider. It's not just spending tokens, it's, it's just how you're using your tools and the impact of those tools as well, and how much time it takes to wait for something to use 150,000 tokens versus just adjusting it on a screen. Why hire when you can partner? Concept Cloud's leading engineers build your startup's prototype without the overhead. Launch faster.

Conceptcloud. com. So we've discussed, uh, various aspects of using different parts of the tooling. We were just sort of getting into, um, Figma in the MCP world, and so like, and, and the benefit that you get from using different tooling for different purposes. Um, I do recall, uh, back when Figma first started the MCP, um, uh, add-on, that you didn't enjoy using it too much.

But has it changed, has it changed considerably since then, or is it just evolved a little bit in terms of the way that you can now interact with both cloud code and Figma in the same similar- That's a nice euphemistic way of saying, like, covering all the fuming that I've done about tooling. But yeah, so okay, so when Figma's MCP came out, you could only go from Figma to Claude Code. It's changed a lot, right? Like, now you can go back and forth, which I've said. And the thing about, like, experiencing frustration with any of these tools is that these, all of these tools are just in their infancy, right?

Like, that, that's, you know, like give credit where credit's due. Like, that's Figma adjusting from, you know, their box model of designing things. You've got Figma and Webflow and things like this to now working with AI. Um, and they're not, they're not companies that create LLMs, right? So that's a huge adaptation that they have to go through.

But the, the workflow has changed immensely. Like I, I think Figma released it, and I, I didn't even know until recently, but Figma I guess released their Capture to Figma back in February, or they s- they started to. And this is great, so I've tried it a little bit. Like when I start creating a, a platform or I start doing something in Claude Code, there are different tools I can use. I can use, you know, the brainstorms thing.

Like show me different versions of this, you know, before I commit to it, and let me select one. But equally, what's really nice is if I have it putting my screens out to Figma, I can go in and I can edit exactly what I need to edit and then send it back to Claude Code. And so this becomes important. Like Claude Code is great for prototyping, but I think when you really start to get into like the deeper principles of usability, of user design, of like color, of spacing, of things like that, that's what like designers, design systems, all that stuff exists for. And you, and you do need to go back to a fine-tuning model 'cause you can't do that with Claude Code.

You can't just say like... I mean, you can just say, but you can go in and say like, "I'm gonna hit inspect, and this line, I want you to change this value to this, and, and, and put this, put this in the, you know, in the final prototype or the final, the final version of something. " But if you, but if you're doing this in Figma, you send it back, you can fine-tune your design. You can make it actually usable. You can make it accessible.

You can make sure all your colors hit, you know, their accessibility guidelines and things like that. So, so this ability now to go back to Figma I think is immense, right? Because working in Claude Code, I loved it. Like I used it for months. I was like, "Oh my gosh, this is so great.

" And now I'm like, "Wait, this is so frustrating," 'cause now I'm at a point where I've, I've made so many things and I'm at the point where I really need to polish them. I'm like, "This takes so long. I wish I could just go back to Figma and work in it. " And you hear a lot of designers say, you know, th- there's a lot of polarity there. People are like, you know, "Build things in Claude Code," and that's great, and there are designers that are like, "Do it yourself.

Build, build it in Figma. " But it, but I think there's a marriage of the two that needs to happen, and it is this passing back and forth now that I think is very pivotal. It allows, you know, using Claude Code, you allow a designer to show their idea, but they can really put forth the, the usability principles that make a product successful by going back into Figma. And, and this is also important because by going back into Figma, and this is going back to this design to developer handoff, there are design systems in there. There are rules in there.

There are things that are invisible that Claude Code won't uphold. And so to go back and create all of the rules that you can hand off to a developer or team of developers, that's gonna make the work much faster downstream because those rules exist. And you know, you can have it in Figma. You can pass it off to Storybook. You can, you can...

Th- this, this ability to go between Claude Code and Figma allows you to, you know, uphold proper design system rules and the, the right constraints to get the product that you designed out the way it was intended to be. So yeah. I think, I think a lot of that, yeah, I think I was gonna say, I think a lot of that we also see from a development perspective as well. Because like obviously as a developer, if you're asking it to like, I don't know, write a line, some text or something, you might as well go and make a cup of coffee sometimes whilst it goes and tries to do that. Whereas I assume inside of Figma, once you've exported this stuff back out, you can start to drag the different elements around, and you still get that sort of layered view that you would get traditionally when you're doing Figma bits that you obviously don't get when you're working inside of a, inside of a web app, which is frustrating when you just wanna be able to tweak small bits to be able to just finish off the, the polish, the look and feel.

And that's not to say that you can't do any of this stuff in a web app, because of course the whole pro- premise of Figma and is to be able to build that stuff out. But it takes, takes those design systems and that knowledge, as you mentioned, just to be able to stick those bits in place, which is time-consuming, especially when you're doing it just from a design perspective. 'Cause of course you might get to a point where you then want, you go, "Actually, I've just spent three hours moving these bits around. Now I don't like it. " Yeah.

I mean, that, that's true, right? So, uh, well, that goes both ways, right? Like, let's just be real. Like, a designer's gonna spend three hours moving bits around in Figma, and they're gonna do it in Claude Code, and they're probably not gonna like it at the end of the day, and the next day they'll get a better idea. But, um, I do kinda wanna go back to, to, to one point that you brought up, which is about how long it takes.

Like, even from a development perspective, you can put in a line and you might as well go make a coffee. So I think this has an impact. When you're doing this as a designer, right, you're... Well, with anyone. Like, like while you wait for Claude Code to do whatever it does, you might as well go open up another project and work on that, right?

Whereas, whereas if you sent it back to Figma, it, it's like a cognitive context thing, right? So if you're back in Figma and you're moving the bits around, you're actively engaged with the product that you're building. You're not just waiting on something else. You haven't just turned your brain off from it. And that actually allows you to, like, mull over the product a little bit more, to be like, "Should this be here?

" There, there are those background processes going as opposed to, like, you know, uh, like Claude Code almost encourages ADHD with how long it takes to, like, process co- you know, process, like, one, one prompt or something like that, where you're like, "Okay, well, while this is running, I'm gonna go work on the other project. I'm gonna go work on the other project. I'm gonna go do the other one. " Like, and, and you just have this domino effect of this cycle of, like, projects that are going. But there is something to be said, and I, and I think particularly from a product perspective, the human insight that you have or the intuition of a product designer is really important, and that does take time.

And so when you go back into Figma and you're moving those pixels and boxes around, it gives you some space for those background processes that are in your mind to, to be working, to be like, "Oh, well, actually, maybe this screen that's in my periphery, um, should be moved over here," or, "Maybe this workflow should, should go there. " So while it, while it takes a long time and while both can take a long time, there's different engagement, mental engagement in how long, um, each one takes. Uh, so from Claude Code takes a long time, but there might not be any mental engagement while you're waiting. If you go back and work on another design tool, there is mental engagement with a product that may yield a better, a better product at the end of it. Yeah, so there is that cost, but there's definitely payoff to it as well, and I think that's very critical from a product design perspective.

M- dare I say more so than a here are the specs, build the thing perspective. Um, it has a lot of downstream impact for your customers, for your, you know, return on investment. That's cool. So, uh, we've looked at where you came from, what you're currently doing now, and what some of those processes look like. And I know no one can ever really hedge a bet because who knows what six months or 12 months or whatever it looks like down the line.

Of course, there is always, like, concern about jobs, job longevity, all that type of thing, but also, like, the different processes and the way that people are gonna work. So, like, if you, if you cast your, like, you know, uh, mind trying to, like, figure out what it's gonna look in 12 months' time, e- even if it was like, like, "This is what I would like to see happen" versus, uh, "This is what my guess would be," like, what do you, what do you think or where would you like this process to be able to go to be able to, like, aid you as a designer, um, in a world where, you know... And I think the other thing as well, just so that everyone is aware, is, like, LLMs learn by copying other people's stuff. So I think also from a design perspective, or my personal opinion on a design perspective, is that you still require designers and design people to do design work because the LLMs will see... You, you'll see a repeating pattern of things that have gone before as opposed to uniqueness going forward.

So, you know, from, from a, from a designer's perspective, from a product manager's perspective, what do you think that looks like? So I think there's a couple of different answers to that, right? So, so the LLMs are of course trained on, on what we've, what we've built. But now that we're able to build things quicker, what are the systemic changes that need to happen in the way that we design that an LLM will next learn, right? Like, do we create a design system every single time?

Are we copying a design system every single time? Do we need to have so many systems, right? Like, to... Can we, can we, can we unify the, like, empirical building blocks for how we build and how we design? So, so there's, there's...

That's the, uh, the toolkit version of it. So I think 12 months from now, you know, if I'm repeating the same process across a bunch of different agents, right? Like, like if I'm every project I'm building with an agent, but I'm doing the same things every time. I'm setting up the same things every time. There's gotta be a way to sort of look at that as a new user experience and say, "Okay, well, this is now the agentic pa- pain point.

" And so a year from now, I think, um, that will be addressed hopefully well. From the user research perspective, I think there are a lot of people that are like, "Well, we have LLMs now, and we have, like, Claude. We can sort of estimate, like, how people will use things. " But I think that that disregards that people continuously learn, they continuously adapt, they continuously move forward. And so now a lot of the tools that everyone is using, they're using with some agentic element to it, right?

There maybe it's a chatbot, maybe it, it gives you like, you know, summaries of things. But people are used to AI now, and so the way people use products is going to change. And I think user research, because Claude is trained off of existing material, you know, it's not, uh, the, it's not a body. It doesn't have a body. It's not going out and talking to people.

I think user research will actually be very important, and I think if you focus on user research and how people are experiencing their usage of the LLMs, uh, that is something that should inform, um, how we develop products going forward. And to, you know, for, for some devel- developers or designers, it's like, do we want to go in the direction, in certain directions, right? Are our LLMs and AI things making information too accessible? Like, are people not remembering things as well anymore? Like, what's really the way to ethically design things going forward for, um, the population, for those that are younger, so we're not short-changing people by just giving you know, shortcuts and answers.

So there, there's that thought too. But basically the, the sum of that is essentially user research I think will be more important because now we have a culture that is steeped in AI usage. And so getting feedback on that and how that affects design, how that affects user experience, how that affects how people want to engage with applications, their time to engage applications is going to change. And then, I mean, beyond that, from a technical perspective, I mean, if you'd asked me a year ago if I thought we would be here, I wouldn't have guessed it. So guessing a year out, I'm, I'm not quite sure.

Maybe in a year I just give it an idea, and it could actually do the workflow, right? I th- I think right now the restriction is creating screens to get from one process to the end of that process that feel robust, considerate, empathetic enough from a design perspective. Like, I don't think Claude can do that yet. There's a lot of training that goes into that. So maybe via every designer's iterations on Claude designs that they're doing, it will learn, um, and, and create more robust screens and, and platforms and digital experiences.

So I think in a year those are the things, more human interaction with user research, more systemic processes, uh, taken care of by Claude, and then also, um, just more robust products coming out when you have an idea that you set to prototype. And then of course, more interoperability between different applications. So that is my guess or my hope for the next year, but we'll see. So, I mean, I guess we're, we're, we're a little bit biased here at Concept to Cloud, but from what I can... What I'm, what I'm hearing is that product design, UX design and research is not going to go away.

Um, you know, I mean, 'cause also like there's, there's always concern, you know, people looking to get into the computing industry, the IT industry, the product industry. There's always concern about whether or not it's a viable path anymore. But of course, like from a, from a programmer's perspective, you can't become a senior programmer without being a junior programmer. And if, if all you need is senior programmers, then you're never gonna get them. And so that's, that's clearly not a viable solution for the tech industry.

I think it's the same for the product industry or product design industry as well, isn't it? Where you still require that human in the loop. You still require some critical thinking and thought that allows for that to happen. And so people looking to get into the industry, I think should still head down that path if that's what interests them. Absolutely.

And I th- and I think the, the expectation is, is a little bit different. Like, so, so I don't think AI is going to take away certain jobs. It will may redefine it as any technology does. And so, like I said earlier, you know, agentic workflows, the, the process was much slower. You might have a UX researcher, you might have a UI person, this and...

You know, and, and you may hand things off. Now someone getting into design, you know, because you've got PMs building from zero to one, you've got designers building from zero to... Like everybody's building from zero to one, right? But the difference is you still need the experience to develop your own skill of discernment of, of where something should go, of how someone experiences something, of how something might make them feel. So yeah, no, user research shouldn't go away because it's gonna inform that intuition.

It... You still need to train people to be at the forefront of the AI to tell it what to... [laughs] train it for what it needs to do next. It, you know? And so I think there is a concern here that people find that juniors aren't important or interns aren't important.

We just want somebody who builds. But what happens when all of that product knowledge and that intuition, you know, retires essentially? You've got no one who's built that intuition underneath them. So, so I think encouraging people to still go after that path is very important. But what they need to know is that they're not gonna be pigeonholed into like, "You're just doing research," or, "You're just doing UI.

" You have to have a lot more of a broader... You have to have a broader scope of what you're going to build, of who it serves. And, and in some way it becomes a little bit more rigorous of an activity to design a product, um, whereas UI design and UX flows are, are one part of it, but you need to really understand your stakeholders. You need to really understand everything from end to end, from who you're creating for, what constraints you have to create through, out to something that, uh, you know, pleases both your customers and your stakeholders. So I think there is breadth that will exist, a breadth of expectation that wasn't quite there before, but it doesn't take away jobs.

If anything, it creates, uh, higher value positions. Cool. There we go. Um, so I would like to take this opportunity to thank Amelia for joining us on the podcast. I believe it's her first podcast.

Mm. [laughs] And she has got from one end to the other. So thank you very much for taking the time. Thank you. And I think it's nice for someone to hear...

Well, people for, people to hear from, not just me, so that's, uh, that's always refreshing on Engineering Evolved. Um, so if you've got this far through the podcast, thank you very much for tuning in and having a listen. Hopefully there is some useful stuff in here that you can take away. If you would like to know more, then feel free to come and reach out to us. You will find us over at concepttocloud.

com and on LinkedIn and all the usual places. And so for now, that leaves me to say thank you once again to Amelia. You're very much. And thank you very much all for tu- tuning in, and we will see you all next time. Bye for now.

From idea to investor demo in weeks, not months. Concept to Cloud, world-class engineers accelerating startup success. Concepttocloud. com.