I’m a product designer, and I’ve started to prototype with Claude pretty frequently in my role, as have many non-designers at my company, for better or worse. How I use it Usually, when I use it,...
I’m a product designer, and I’ve started to prototype with Claude pretty frequently in my role, as have many non-designers at my company, for better or worse.
How I use it
Usually, when I use it, I have a clear idea of something to float with the team or put in front of customers to assess a premise. I keep the scope contained, don’t hand-wave any details, and make sure that what I’m suggesting doesn’t require anything technically difficult or access to data that’s not already baked into the product.
I also built a skill in Claude to clearly mark the level of “done” at the top of each prototype and adjust the visual fidelity accordingly. Am I in the early days of thinking through the problem (30%)? Am I validating whether I’ve hit the mark with more clearly defined problems to solve (60%)? Am I looking for feedback on interaction nuances and more or less ready to finalize (90%)?
I go screen-by-screen, using voice dictation to get something representative of what’s in my head, until the premise is adequately captured and ready to share — usually takes anywhere from 15 minutes to a couple hours depending on the complexity. And in all quite a bit faster / less mentally taxing than building screens by hand in Figma and wiring together a prototype with complex interactions. It also results in a more dynamic prototype where most interactions are properly functional, which makes it easier to put in front of people without needing to explain the limitations.
How others use it
People in roles across my company have taken to producing prototypes with Claude as a way of telling our product team, “if we could just build THIS, all of the problems I’ve been hearing from [insert customer] would be solved.” These prototypes are typically no more useful than a simple list of those problems (and in many ways less useful since they carry so much LLM-generated specificity that didn’t come from the brain of the person carrying that context).
The biggest issue I observe is that it’s easy to mistake LLMs’ ability to produce visually passable interface design for substitute for the thinking required to arrive at why / whether the solution is correct for the product as it exists today, if it would make sense for the other customers we serve, accounts for our technical capacity, etc.
I’ve seen lots of beautiful customer dashboards and impressive simulated chatbots, each of which precisely targets a customer problem or business goal, and would more often than not be incredibly effective if implemented exactly as presented.
The unfortunate downside is that these solutions almost always each require a massive roadmap of pre-work in defining various systems, new primitives, and data flows — each of which would carry huge, uncertain product and experience implications to make it tenable in the first place.
Whenever a prototype like this is sent my way, I give a “woah, this is so cool” type of response, and keep the core problem they cared enough to try to solve in the back of my head, but don’t often find the prototype itself terribly enlightening.
The outcome of all of this is that there’s a new artifact floating around of what I’ll call “experience slop” that can be hard to differentiate, at a glance, from work that has had adequate thought and proper product context applied to it.
I (and probably many people here) can skim a comment on the web and immediately clock it as LLM-generated or -edited, and feel some discomfort with the idea that a person had an idea they wanted to communicate badly enough to post it, but not enough confidence or enthusiasm to decide how exactly they wanted to communicate it.
I’m now in an odd position of feeling the same way about interactive prototypes in my day-to-day work, trying to puzzle together how much of what I’m seeing is a direct reflection of what the sender is trying to communicate vs an LLM filling in the gaps where the sender couldn’t be bothered to think through whether what they’re proposing makes any sense at all.
At this point, others on my team can pretty easily detect experience slop when we see it, but I do worry that it trivializes the work we do when it’s not always easily differentiable to the untrained eye.
It’s interesting to experience firsthand a threshold being passed where people in my profession are joining the company of artists and writers whose craft has already been comprehensively undermined by LLMs — and I know for all my misgivings about the lack of fidelity of thought used to create experience slop, it’s probably only a matter of time before that won’t really matter anyway.
It is almost as if real industry practices from lessons learned still apply to LLM involved development ;) I have been experimenting with claude code in the past weeks. Mostly to see where things...
It is almost as if real industry practices from lessons learned still apply to LLM involved development ;)
I have been experimenting with claude code in the past weeks. Mostly to see where things stand and found there is a plugin called "superpowers" which heavily leans into good development practices but also good debugging skills. It still doesn't fix some fundamental issues with llms. But it does help a ton with having them follow structured process from start to finish.
Having said that. Even with superpowers it still very much feels like cat herding at times. With prototypes and other green field projects the results can be impressive. But even at that stage I do find having to constantly be on my guard for them drifting away from requirements and jumping to conclusions exhausting to deal with.
Edit:
Long day and I was on my phone so I forgot to include about half of what I wanted to mention. One of the things is that the only reason I am able to use LLMs like this is because of decades of experience and working in the field. I am slightly worried that we are now speedrunning to a world where a lot of that institutional knowledge and experience is simply lost. A lot of it does exists on paper but clearly not present enough in the training data to surface as a default (which does say something about the fragile state of software development before the hype imho, but that is a tangent) or is explicitly not valued by these companies training these models (also a possibility in my mind).
Also, forgot to link to the superpowers repo, here it is. And a selection of the skills it comes with:
brainstorming
executing-plans
receiving-code-review
requesting-code-review
systematic-debugging
test-driven-development
verification-before-completion
writing-plans
All of them involving elements from red/green, TDD, DRY principles, etc. I can't stress enough that it doesn't make Claude (or other models as the skills work with other harnesses as well) perfect, but it helps a lot with the whole "distracted assistent with short term memory loss going on tangents" behavior you otherwise encounter.
That's quite the bible quote. I had to look it up to see if it was real :) It's a bit unclear what they mean by "sketch," though. Literally draw a picture?
That's quite the bible quote. I had to look it up to see if it was real :)
It's a bit unclear what they mean by "sketch," though. Literally draw a picture?
It's an interesting counterpoint to Genesis 11, where people carefully architect and plan the construction of a tower, only for God to hit them all with aphasia, thus forcing the project to be...
It's an interesting counterpoint to Genesis 11, where people carefully architect and plan the construction of a tower, only for God to hit them all with aphasia, thus forcing the project to be abandoned.
Good advice. Along the same lines, I enjoyed having Claude help me build out a design doc for a tool I needed. It was helpful just working through the whole thing in text, organizing thoughts and...
Good advice. Along the same lines, I enjoyed having Claude help me build out a design doc for a tool I needed. It was helpful just working through the whole thing in text, organizing thoughts and working i more detail, before having to deal with compile errors, library version conflicts, etc etc.
I've only had the opportunity to do it once, but I like how it helped the rest of the process.
On my personal link-sharing website, the bot and I have written 80 design docs so far. It works fairly well, but doesn't keep me from over-engineering things. :) Before that I would only write...
On my personal link-sharing website, the bot and I have written 80 design docs so far. It works fairly well, but doesn't keep me from over-engineering things. :)
Before that I would only write design docs at work, not for my hobby projects.
I’m a product designer, and I’ve started to prototype with Claude pretty frequently in my role, as have many non-designers at my company, for better or worse.
How I use it
Usually, when I use it, I have a clear idea of something to float with the team or put in front of customers to assess a premise. I keep the scope contained, don’t hand-wave any details, and make sure that what I’m suggesting doesn’t require anything technically difficult or access to data that’s not already baked into the product.
I also built a skill in Claude to clearly mark the level of “done” at the top of each prototype and adjust the visual fidelity accordingly. Am I in the early days of thinking through the problem (30%)? Am I validating whether I’ve hit the mark with more clearly defined problems to solve (60%)? Am I looking for feedback on interaction nuances and more or less ready to finalize (90%)?
I go screen-by-screen, using voice dictation to get something representative of what’s in my head, until the premise is adequately captured and ready to share — usually takes anywhere from 15 minutes to a couple hours depending on the complexity. And in all quite a bit faster / less mentally taxing than building screens by hand in Figma and wiring together a prototype with complex interactions. It also results in a more dynamic prototype where most interactions are properly functional, which makes it easier to put in front of people without needing to explain the limitations.
How others use it
People in roles across my company have taken to producing prototypes with Claude as a way of telling our product team, “if we could just build THIS, all of the problems I’ve been hearing from [insert customer] would be solved.” These prototypes are typically no more useful than a simple list of those problems (and in many ways less useful since they carry so much LLM-generated specificity that didn’t come from the brain of the person carrying that context).
The biggest issue I observe is that it’s easy to mistake LLMs’ ability to produce visually passable interface design for substitute for the thinking required to arrive at why / whether the solution is correct for the product as it exists today, if it would make sense for the other customers we serve, accounts for our technical capacity, etc.
I’ve seen lots of beautiful customer dashboards and impressive simulated chatbots, each of which precisely targets a customer problem or business goal, and would more often than not be incredibly effective if implemented exactly as presented.
The unfortunate downside is that these solutions almost always each require a massive roadmap of pre-work in defining various systems, new primitives, and data flows — each of which would carry huge, uncertain product and experience implications to make it tenable in the first place.
Whenever a prototype like this is sent my way, I give a “woah, this is so cool” type of response, and keep the core problem they cared enough to try to solve in the back of my head, but don’t often find the prototype itself terribly enlightening.
The outcome of all of this is that there’s a new artifact floating around of what I’ll call “experience slop” that can be hard to differentiate, at a glance, from work that has had adequate thought and proper product context applied to it.
I (and probably many people here) can skim a comment on the web and immediately clock it as LLM-generated or -edited, and feel some discomfort with the idea that a person had an idea they wanted to communicate badly enough to post it, but not enough confidence or enthusiasm to decide how exactly they wanted to communicate it.
I’m now in an odd position of feeling the same way about interactive prototypes in my day-to-day work, trying to puzzle together how much of what I’m seeing is a direct reflection of what the sender is trying to communicate vs an LLM filling in the gaps where the sender couldn’t be bothered to think through whether what they’re proposing makes any sense at all.
At this point, others on my team can pretty easily detect experience slop when we see it, but I do worry that it trivializes the work we do when it’s not always easily differentiable to the untrained eye.
It’s interesting to experience firsthand a threshold being passed where people in my profession are joining the company of artists and writers whose craft has already been comprehensively undermined by LLMs — and I know for all my misgivings about the lack of fidelity of thought used to create experience slop, it’s probably only a matter of time before that won’t really matter anyway.
It is almost as if real industry practices from lessons learned still apply to LLM involved development ;)
I have been experimenting with claude code in the past weeks. Mostly to see where things stand and found there is a plugin called "superpowers" which heavily leans into good development practices but also good debugging skills. It still doesn't fix some fundamental issues with llms. But it does help a ton with having them follow structured process from start to finish.
Having said that. Even with superpowers it still very much feels like cat herding at times. With prototypes and other green field projects the results can be impressive. But even at that stage I do find having to constantly be on my guard for them drifting away from requirements and jumping to conclusions exhausting to deal with.
Edit:
Long day and I was on my phone so I forgot to include about half of what I wanted to mention. One of the things is that the only reason I am able to use LLMs like this is because of decades of experience and working in the field. I am slightly worried that we are now speedrunning to a world where a lot of that institutional knowledge and experience is simply lost. A lot of it does exists on paper but clearly not present enough in the training data to surface as a default (which does say something about the fragile state of software development before the hype imho, but that is a tangent) or is explicitly not valued by these companies training these models (also a possibility in my mind).
Also, forgot to link to the superpowers repo, here it is. And a selection of the skills it comes with:
All of them involving elements from red/green, TDD, DRY principles, etc. I can't stress enough that it doesn't make Claude (or other models as the skills work with other harnesses as well) perfect, but it helps a lot with the whole "distracted assistent with short term memory loss going on tangents" behavior you otherwise encounter.
I've been referring to 'vibe coding' or AI-assisted code as 'code wrangling', like wrangling a herd of cattle.
That's quite the bible quote. I had to look it up to see if it was real :)
It's a bit unclear what they mean by "sketch," though. Literally draw a picture?
It's an interesting counterpoint to Genesis 11, where people carefully architect and plan the construction of a tower, only for God to hit them all with aphasia, thus forcing the project to be abandoned.
Yeah - Jim is a designer first, so I’m pretty sure he literally means a rough drawing.
Good advice. Along the same lines, I enjoyed having Claude help me build out a design doc for a tool I needed. It was helpful just working through the whole thing in text, organizing thoughts and working i more detail, before having to deal with compile errors, library version conflicts, etc etc.
I've only had the opportunity to do it once, but I like how it helped the rest of the process.
On my personal link-sharing website, the bot and I have written 80 design docs so far. It works fairly well, but doesn't keep me from over-engineering things. :)
Before that I would only write design docs at work, not for my hobby projects.