A real world example of how I use Claude practically in Product Design…I’ve used AI prototype tools for over a year now but they all seemed like half the solution – all front end. (designing software of a complex enterprise platform is NOT the same as designing a quick one off website with no existing structure or code) When you have an existing and complex platform
So last week I took on a new challenge, how to make a working prototype in our platform (A salesforce enterprise platform) with real code based off of a concept.
Here is how we did it (so far)
1. I designed it all in figma as a classic linear prototype using our combination Salesforce Design Library and Custom Patterns Library (the old “last year” way)
2. I did a recorded demo of the prototype narrating
3. One of our team members fed that video into Claude Code Fable 5 (before it was taken away the first time) and created a new branch via GitHub off of the products master branch and built the working demo in a Salesforce scratch org with little direction.
4. I then spent time exploring and comparing the Claude Code created version (that at the time had no access to the Figma files) and treated it like a QA site I received. I wrote a detailed google doc breaking down every where that was off (mostly because Claude didn’t have access to the source and only created what I showed in the video with fake content). The document I wrote was design and ux direction and had screenshots as well as direct links to the Actual Figma Design files and Prototype link
5. Then at the start of last week I spun up a new test Org via Github off the prototype branch and fed that document into Claude. I asked it to do 2 things to start.. 1. treat me like I have no idea what I’m doing and walk me through small changes in a full loop from fix to commit to push back up to the origin branch…. 2. Give me a full break down of my list ranking each issue in complexity and do a full automated test of the prototype to tell me what I missed and help me develop a plan of attack.
6. We picked the easiest item – a button had the wrong color background. Claude made the change, and set in Accept mode asked me at every step to approve things (many of which as a designer not a developer I admit I didn’t understand at first), committed the change, asked me to hard refresh the logged in org in a browser to confirm the change, then asked me to manually push the change to the original Prototype branch in Github using the GitHub Desktop app with a button click.
7. the longer we went on that first day the more confident I got working with it to do batches of changes and commit/push less often. I started asking for advice not on just making my changes but suggestions on if I was making the right call or if there was a better way to do something.
8. By the end of day 1 I had also connected the actual figma design files, given Claude Chrome Control access to auto open pages for me to review and to auto open and test. We ended with the same list I started with but appended to show what was done, partially done or would require more discussion.
9. By the end of day 2 we were getting serious. I moved beyond the easy wins and into the complex UX issues in the prototype from my list, as well as adding a new found issue that I would not have found without a functional prototype. I ended day 2 giving claude planning control with less accepting from my side on every step. I even started to let it auto commit and push to origin without me manually doing it on the GitHub Desktop app.
10. By day 3 I was in the zone. MCIM is a complex platform with over a decade of Salesforce object structure and schema. What I was working on was a new refactoring of one of our core features with a ton of existing data. I started to ask Claude much deeper questions and giving it much deeper tasks. As designers we’ll often do 1 or 2 layouts and say “the rest will follow a similar structure with the new fields or requirements.” that laziness is often what leads us to redesign it later when a developer puts it together without direction.
11. I noticed the dummy data didn’t make sense…(likely because it grabbed it from my design originally and just made up the rest with no context) so I asked it to review the actual object structure and data and rework part of my designs creation step forms to create realistic data and commit it to the database on the test site. We moved paste a click through to a working prototype that would create not only the clean data but data that matched our existing feature.
12. By the end of the week I had a fully functional feature that covered global administration, local user administration, and individual user execution all working together including approval flows, creation flows and more. ALL of this was in my head from the first Figma prototype. But it would be a talk track and a carefully mapped out linear click path.
13. I even had Claude running its own flow tests with Chrome Control to test the UX as I was doing it manually and then had it build a demo script for me that I can use when I shared the experience.
All that means a few very interesting things…
- I’m using the real structure of our existing platform and its code in a native Salesforce environment that is actually creating and working.
- I am able to repeat the install for others on the Product team to spin up and test and more importantly to give to our clients a safe test experience that is functional for real feedback before it moves to production
- I am still using design and Figma – but I am using it more akin to how I designed UIs 15-20 years ago. When I would make key frame and spend more time on understanding the UX and user with boxes and arrows and wireframes and then sit next to a developer to build…but I’m doing it all early to make sure its even worth truly developing at all and then giving them a very clear UX and UI with less grey space for gaps or confusion
- and it took 4 days.
This gave me a way to truly test my vision out and work out a lot of the questions I would have had come back in development or worse after when a client lived with a real build after months of work in a matter of days.
That is where a designer can thrive with these new tools. It gives us a real opportunity to learn and refine and ensure a UX solves real problems and doesn’t create more well before we develop and release it. And because we are designers, if we are frustrated or don’t like something we can also hop back into pixels and create what we want to ensure the AI gets it right and in that way we create polish and not slop from thin air.
***************
About the Author:
Todd Lawson is a Design Executive, Creative Director, and Principal Product Designer with more than 20 years of experience helping organizations create better products, stronger brands, and more meaningful customer experiences. His career spans enterprise software, SaaS platforms, UX strategy, customer experience design, digital transformation, branding, advertising, and innovation.
Currently leading product design for enterprise software serving many of the world’s largest financial institutions and data center operators, Todd has also spent more than 15 years in creative leadership roles at agencies including Grey Canada, Blink Creative Agency, Dashboard, and Vicimus. His work has earned recognition from Cannes Lions, One Show, Cassies, Marketing Awards, ADCC, Applied Arts, and numerous international award programs.
Todd specializes in connecting business strategy, customer insight, and emerging technologies—including AI-assisted design workflows—to build scalable products, design systems, and high-performing creative organizations. He writes about product design, user experience, creative leadership, AI in design, digital transformation, and the evolving relationship between technology, business, and human-centered design.