Hi folks, welcome to Engineering Evolved.
My name is Tom and we are here today with Amelia, who is the Director of Product
Management here at Concept to Cloud.
And we're going to discuss her work and how it's changed in the era of AI, how we've gone
from a very manual process to something that's more automated, the pros, the cons, the
good, the bad.
all that type of stuff.
So before we dig in, I will let Amelia introduce herself and she can tell us a little bit
about what she does.
Hi, Amelia, uh director product at Concept of Cloud.
I've worked with Tom for, I don't know, a couple years now.
Um and so I started out in the sciences and I moved to uh in academia and then I moved to
product.
Um I do can we redo this whole part?
Like you're just gonna cut it out.
I'll just restart it then.
Um
isn't
You just go for it.
It does not matter.
I will do the intro for a third time and we'll try again.
have to do the interview for a third time.
You could just cut that bit out.
And then then this is where I can just say, like, I'm director product at Concept to
Cloud.
Um, I helped create some products, I helped build zero to one products.
I use primarily cloud code.
Um before being a UX designer, I was um I worked in astrophysics and climate science.
and I moved from academia to product design to work on mission related products.
Is that it?
Yeah, that's it.
How much more do you want?
Well, no, but you sort of rolled from talking about not it into it.
So don't know if we can cut that together.
We will do it again.
We will do the whole thing again.
The whole thing again.
if what do I actually want to say?
What should I say that's helpful for us?
It's just a little, you know, how you would introduce yourself to anybody.
self-deprecating, obviously.
Go ahead.
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.
we're going to 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 going to let Amelia introduce herself properly.
to you, Amelia.
Okay, so uh as you've said, I'm director at Concept of Cloud.
I've spent my career building zero-to-one products, usually in mission-oriented work, um,
heavily focused on regulated data-heavy environments.
Um before I worked in product, I worked in astrophysics and climate science.
and so I've always sort of kept a focus on mission-focused work.
Um
Yeah, and so now I build with you at Concept to Cloud and deliver an array of products
from anything from health to care, fintech, or just fun stuff.
So yeah.
We do like the fun stuff.
That's cool.
Okay.
So as we sort of look at how the, the, the processes have changed over the years, can you
give me a little bit of insight into what like sort of pre-clawed pre LLMs, like what your
workflow looked like from a, from a UX design and research and a product build out
perspective.
yeah.
So before Claude, you know, you could put in a prompt and you could get uh 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.
And then you would have to do everything in like a rigid order.
And, you know, to some extent that's still true.
Um, but you would have to look at, you know, uh competitive analysis, like what else was
out there, and you'd have to go through a lot of this 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 would just wouldn't be auto auto populated like it is with Claude.
And so the workflow would end up being um, you know, you do the manual research, you draw
up the wireframes, 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.
Um, because the design aspect would take a lot of time.
And so you wanted to get it right.
Um 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, prior to the way that you work now, we're talking an awful lot of note taking,
human-based research, I guess, is a lot of what was going on.
Still is to a degree, I guess, but allowing for that to happen.
And then what tooling did you use outside of a notebook to be able to build out these
product designs?
Um yeah, so you you'd use like a mix of things.
I mean, primarily obviously for design, like you'd use Figmar or Sketch or Adobe XD if you
were feeling um daring.
Uh, but you would have to use like Miro, you would use things like maze, you'd compile
your research, you would use a lot of sticky notes, like whiteboarding things.
There's 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 uh
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.
Um so yeah, and in that regard, the tooling, uh, you know, in terms of software, like yes,
there's Figma, yes, there's note taking, you people are using Google Docs, they're
compiling their notes from interviews, they're using Miro.
uh
And I'm sure a myriad of others that have maybe fallen to the wayside now, both in um use
and in memory, but um a lot of pen and paper.
yeah.
So when it came to working with customers, working with clients and that type of thing,
like pre-LLMs, be a lot of 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 notebooks for rough mock-ups?
How did that look?
If you're doing rough mockups, and I and I feel like this is sort of a lost art form,
there is a lot of value to back in the napkin uh drawings and paper mockups, right?
Before, like really before you invested any of this time in sort of drawing boxes and
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.
Um, before you would go into any sort of sketching or um any kind of programmatic
environment, just because of how much time it it used to take, 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 wireframing 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.
Um so yeah.
Okay, that's cool.
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.
And I think that's sort of where we both got our first uh insight into LLM usage and how
it can tweak change stuff.
And this is well before Claude code and codecs and all that type of stuff existed on the
market.
um
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, in your mind and the way that it worked for you, that transition from back
of the napkin stuff through to where we are today, what's changed, I guess, 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 cloud code to what you have today, where you put
in a prompt and all of a sudden you can get an application.
Um, 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 um take my notes and have like ChatGPT or Cloud Code like disseminate,
you know, what the notes were, or early versions of Mira, like how could I cluster my
affinity maps, things like this.
so like the the the progression really in the last year, 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 um
with the help of the engineering team was a note taker.
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 be present to
the person that you're speaking with.
And so on this project at Princeton, I'm speaking with researchers that know um topics uh
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 note taker that I could just tap a little
button during my interviews and say, okay, take note of this, take note of this.
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.
and so it it um AI started to treat different areas of UX design before, you know, Claud
Code or
Chat GPT or whatever you use, um, 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 note taking tooling and what have you.
You know, moving on now to something from a workflow perspective, 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 called Cloud Code work, which came out of that because they realized
people were using it on the desktop processes and not just backend stuff.
you know, as when, when you made the switch from using just the Cloud Web App chatbot
thing um to Cloud Code, yeah, I suspect that was, that was a step into the unknown again.
yeah, absolutely.
So I'm not a developer in any uh in any measure or knew a lot less about development at
that time.
Right.
And so using Cloud Code, I heavily relied on you, I heavily relied on members of the team.
Like I didn't even know what GitHub was, I didn't know how to like subdu version control,
any of this.
So um stepping into Cloud Code, it was just like A, I had to learn a little bit of how um
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?
Because now you have a designer that's like, well, I want to 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, blinted?
You know, I still don't use the terms properly.
but yeah, like I it it it was a huge thing.
Um 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.
Do you need to understand things, not from 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 um how to build
what you're about to build.
And and in that regard, like uh 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 a few different aspects to this, isn't there?
Because there's the positive aspect in a small team, especially.
I think 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 going to be, then that gives that team the
ability to 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 he's going to tear it down and start again anyways.
So I think on a small team, there's an awful lot of ability for a designer to just hand
over code that can be tuned up, tweaked, improved.
But we also, I feel like we've found with some of the stuff that we're building out, that
you also hit the limits of what the designer can do inside of cloud 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 mockup anymore.
But at the same time, Claude isn't necessarily clever enough to be able to discern whether
or not to do something and what knock-on impact it's going to have.
And of course, in various contexts we've had, we've seen that happening with developers,
let alone designers.
so there's definitely 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 uh 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 cloud 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 six thousand 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's 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, um, it's a it's a twofold thing.
It 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.
Um, and then yeah, like it just um
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 are 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 that 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, you know, this isn't
great.
It doesn't build things exactly like how we want it to.
Um
And they would aired they would prefer to stay with something that they could build very
specifically.
But it 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.
Um to be able to uh create a visual of those ideas for developers to build off of, you
know, uh 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 clawed code
thing.
This is just a universal designer to developer handoff issue that's always existed.
Um
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.
Um whereas if you know we were a larger team, like I could have done smaller pieces at a
time, you know, smaller pieces.
Um but so in that regard, um in that regard, cloud 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's always been different options there, haven't there?
Because on the market up until, well, on the market still, clearly, are uh apps like
Lovable, which give you the ability to knock up full applications, but without having to
understand all the bits that go on under the hood.
Did you try experimenting with Lovable or any of the other adjacent apps, and what did you
find there?
I did.
I did 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 well not danger, but the drawback was those
apps were basically just built on top of Chat GPT.
They were built on top of Claude Code.
And what they did was they created a UI that was more digestible for it.
Like this goes back to the other question.
They 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 cloud 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 um to
write lovable, but um you got this.
middle ground that was always gonna be a step behind whatever uh Cloud Code Cloud Code or
Anthropic or 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, firsthand information versus playing telephone and um 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.
Um there is a lot of rate limiting that didn't exist if you worked in the um direct cloud
code environment.
But that is a big ask for some, you know, it is a big ask for designers.
It you it's always a big ask for someone to switch their entire work environment at the
speed that, you know, GenTic workflow has developed.
Um
Which was very quickly, and to go from, you know, drawing things in boxes and 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, um, particularly at that time.
So yeah, using things like levelable, using third-party apps, my experience with those.
Uh not great overall at the time.
Just just not great.
It was just like getting um watered down watered down ab ability.
So you talk about being rate limited and that type of stuff using Lovable uh as an
application build out.
obviously now there's Claude Design or Claude Design or whatever they call it, because
I've seen it 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 build out what you needed to be able to build out?
So I've tried I tried Cloud Design when it came out.
I'm sure it's great.
I think with Claude Design.
So so this is where I'm at now.
Um 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, um
that happens, it's really feels like diminishing returns because it doesn't it doesn't
feel like cloud 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 a workflow of like this is how you um you know do your happy path.
This is how you get from complete this whole task from A Z.
Um
Claud design will make you a page that feels very static, uh but the amount of token
usage, the amount of prompting you have to do to get something good out of it, uh doesn't
necessarily feel worth the return.
So at the moment, I'm still working in Cloud 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 two cloud 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.
Um, and equally just from a personal perspective, um, token usage is something that uh has
environmental impact, right?
So if you want to be conscientious about your workflow, your work environment, um, what
you know, like I don't want to use a hundred and fifty thousand 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, th 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.
Um, and how much time it takes to wait for something to use 150,000 tokens versus just
adjusting it on a screen.
Fair enough.
Do want me to let the cat out?
Is he quite loud?
uh
Feed you.
out it's over here somewhere Rowena does not look impressed.
I'm sure she's not impressed.
I'm doing lots of long run on sentences, but hopefully I'm saying something of value.
I've no idea.
I'm so nervous right now.
This is still doing great.
no one won't remember this.
This is great.
I could do this again all the time.
I'm not gonna remember it.
This feels like being punched in the face.
Anyway.
Come on then.
So we've discussed various aspects of using different parts of the tooling.
We were just sort of getting into Figma and the MCP world and so like and the benefit that
you get from using different tooling for different purposes.
I do recall back when Figma first started the MCP add-on that you didn't enjoy using it
too much but has it changed?
Has it changed considerably since then or has it just uh evolved a little bit in terms of
the way that you can now interact with both VodCode and Figma in the same, tooling?
That's a nice euphemistic way of saying like covering all the fuming that I've done about
tooling.
But um 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.
um working with AI.
and they're not they're not companies that create LLMs, right?
So that's a huge adaptation that they have to go through.
Um 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 um
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 Cloud Code.
And so this becomes important.
Like Cloud Code is great for prototyping.
but I think when you really started 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 Clot 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 Cloud Code, I loved it.
Like I used it for months.
It's like, 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, the there's a lot of polarity there.
People are like, you know, build things in Cloud Code and that's great.
And there are designers that are like, do it yourself, build build it in a Figma.
But 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.
Uh
It allows, you know, using Cloud 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, 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.
Um 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 going
to make the work much faster uh downstream.
uh Because those rules exist.
And you know, you can have it in Figma, you can pass it off to Storybook.
You can, you can the this this ability to go between Cloud 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 don't know if that answers
a lot of that we also see from a development perspective as well, because obviously as a
developer, if you're asking it to 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.
uh view that you would get traditionally when you're doing Figma bits m that you obviously
don't get when you're working inside of a web app, which is um frustrating when you just
want to be able to tweak small bits to be able to just finish off 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 premise of Figma is to be able to build that stuff out, but it 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.
Because 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, th 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 cloud 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 kind of 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 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 are those background processes going as opposed to like you know, so like cloud code
almost encourages ADHD with how long it takes to like process co you know, the 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 the cycle of like projects that are
going.
But there is something to be said, and 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, well, actually, maybe this screen that's in my periphery should be
moved over here, or maybe this workflow should should go there.
Um
So while it while it takes a long time and while both can take a long time, there's
different engagement, mental engagement and how long each one takes.
so from quad 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 um at the end of it.
Yeah.
So um 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.
Mm dare I say more so than a here are the specs, build the thing perspective.
Um yeah, it has a lot of downstream impact for your customers, for your um, you know,
return on investment.
That's cool.
So we've looked at where you came from, what you're currently doing now and what some of
those processes look like.
um 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.
um But also like the different processes and the way that people are gonna work.
So like if you cast your
like, you know, mine, try and like figure out what it's going to look in 12 months time.
Even if it was like, like, this is what I would like to see happen versus 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 in a world where, you know, and the other thing
as well, just so that everyone is aware is like LLM's
learn by copying other people's stuff.
So I think also from a design perspective, or my personal opinion on design perspective,
is that you still require designers and design people to do design work because the LLMs
will see, you'll see a repeating pattern of things that have gone before as opposed to
uniqueness going forward.
um So, you know, from a designer's perspective, from a product manager's perspective, what
do 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 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 pain pain point.
And so a year from now, I think
um that will be addressed hopefully well.
Um 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 chat bot, maybe it it gives you like, you know, summaries of things,
but people are used to AI now.
Um, and so the way people use products is going to change.
And I think user research, uh because Claude is strained off of existing material, you
know, it's not it's not a bot, it doesn't have a body, it's not going out and talking to
people.
I think user research will actually um be very important.
And I think if you focus on user research and how people are experiencing their usage of
LLMs,
that is something that should inform how we develop products going forward.
Um, and to, you know, for for some develop 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 the population,
for those that are younger?
so we're not
shortchanging 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.
em And then I mean beyond that, from a technical perspective, I mean if you'd asked me a
year ago if I thought we'd 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 um creating screens to get from one process to
the end of that process that feel um 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 um
via every designer's iterations on Claude designs that they're doing, it will learn and
and create more robust screens and and platforms and digital experiences.
Um so I think in a year, those are the things, more human interaction with user research,
uh more systemic processes 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 uh interoperability between um 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 a little bit biased here at Concept to Cloud.
But from what I'm hearing is that product design, UX design and research is not going to
go away.
Because also there's always concern, 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, from a programmer's perspective, you can't become a senior programmer.
without being a junior programmer and if all you need is senior programmers, then you're
never going to get them.
And so that's clearly not a viable solution for the tech industry.
I think it's the same for the product industry, 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 think 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, pre 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.
Um
It you still need to train people to be at the forefront of the AI to tell it what to
train it to for what it needs to do next.
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 going to 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, um
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, um,
what constraints you have to create through out to something that I you know pleases both
your customers and your stakeholders.
So I think there is breadth that will exist, uh a breadth of expectation that wasn't quite
there before, but it doesn't take away jobs.
If anything, it creates uh higher value.
Physicians.
Cool.
There we go.
So I would like to take this opportunity to thank Amelia for joining us on the podcast.
I believe it's her first podcast and she has got from one end to the other.
So thank you very much for taking the time.
I think it's nice for someone to hear, well, people to hear from, not just me.
So that's, it's always refreshing on Engineering Evolved.
So if you've got this far through the podcast,
Thank you very much for tuning in and having a listen.
Hopefully there was 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 conceptocloud.com and on LinkedIn and all the usual places.
And so for now, that leaves me to say thank you once again to Amelia and thank you very
much all for tuning in and we will see you all next time.
Bye for now.