Related posts
See all
Over the last few months, design work has been changing in a very interesting way at Fieldguide. The design process used to feel fairly contained. Designers spent most of their time on discovery, ideation, and shaping solutions, then eventually handed things off to engineering. What happened after that was often a bit of a black box. We didn’t always have much visibility into implementation.
But with AI, the boundaries at the edges of these phases is starting to blur.
The early stages aren’t just for designers anymore
The first shift is happening at the beginning of the process.
In the past, early exploration such as thinking through concepts, sketching flows, building rough prototypes, etc. was mostly a designer’s responsibility. But today, thanks to AI tools, anyone on a team can generate prototypes or mockups using AI.
That’s mostly a good thing. It means ideas can be tested earlier and more often. Our partners can now visually convey their ideas, making discussions more concrete. The PRD comes to life, and we can react earlier as a team. Designers can explore more broadly, quickly validating assumptions. However, AI-generated prototypes often look nothing like the final product. They lack the broader product context, are difficult to validate with customers and struggle to consistently use established patterns.
This is why design judgement is even more valuable now. Designers are responsible for making sure the right interaction patterns are used, that systems stay consistent, and that the experience holds together as a whole. Those kinds of decisions rely on taste, pattern recognition, and context, all of which AI cannot do well just yet.
So while more people are participating in the early exploration, designers continue to step in to shape, refine, and bring coherence to what gets built.
Designers are also getting closer to code
There is also a shift on the opposite end of the process.
With tools like Claude Code and Cursor, designers can now generate working code! It’s suddenly possible to go from an idea to a real interface without always relying on engineers. Designers are now able to ship low-risk UI updates, fix UI bugs, and build design system components. But while these new opportunities are exciting, they also come with tradeoffs.
Engineers start to receive more pull requests from non-technical team members. These PRs may lack polish or fail to follow best practices, which means engineers will need to spend additional time reviewing and ensuring code quality. I myself am guilty of submitting a PR where Claude completely ignored established design system components, resulting in an extra review cycle on the engineering side (sorry Tim!).
So while the boundary between “design work” and “engineering work” is becoming much less rigid, it also means that implementation cannot just be engineering’s responsibility. Design needs to be aware and cognizant of the impact of our (or rather, Claude’s) code contributions.
The upside is that things move faster. More ideas actually make it into production, and the design team can start chipping away at the ever-growing backlog instead of watching it pile up.
But when to slow down?
Speed is only half the story. Because once you realize you can go from a half-formed idea to something real in just a couple of hours, it's hard not to just… keep going. But we are starting to discover that speed can hide the important questions or the difficult details we actually need to sit with.
So when should we question speed? For example, it might be worth slowing down to validate end-to-end experiences in flows that affect trust or compliance, because speed can hide important details. Complex system decisions also benefit from careful reasoning and critique because here the cost of a wrong decision could be high. And while AI can produce pixels or code quickly, without a clear problem statement and success criteria, it's easy to move fast in the wrong direction.
The designer’s role is shifting
Both ends of the traditional design process are opening up. More people can now explore ideas at the beginning, and designers can participate more directly in implementation.
As a result, the role of the designer becomes less about owning every stage of the process and more about shaping the quality of the whole system.
Most importantly, knowing when to take a shortcut and learn quickly, and when to rely on classic design processes, will be an essential skill for AI-native designers. Instead of leaning heavily on one approach over the other, perhaps we treat AI as a "design speed dial", turning it up to generate ideas quickly, and turning it down when the work demands depth, rigor, and end-to-end validation.
Vrunda Tambe
Senior Product Designer at Fieldguide
