I'm a Salesforce consultant. Every project I've worked on started the same way: a Figma or grey-box wireframe that the client signs off, then a build that surprises them, because a picture of a Lightning page is not a Lightning page. Hover cards, path chevrons, related lists, the way a quick action opens: none of it is in the mock-up, and the review meeting turns into "is this what Salesforce looks like?" instead of "is this the requirement?".
What I've been doing instead is building the page itself in the real Lightning Design System from the user story, in both the SLDS 1 and SLDS 2 looks, then clicking through it with the client and reading the acceptance criteria back off the page. It has changed our review meetings, but I'd like to know what others in this group use:
Do you prototype in the SLDS Figma kit, or straight in App Builder in a sandbox?
How do you show interaction (quick actions, screen flows, popups) without building it for real?
How do you handle the SLDS 2 transition when the client's org still shows the classic look?
Full disclosure: I built the tool I use for this (
sfproto.com, free to try, nothing connects to an org). That's not the point of the question, but I'd rather say so than not.That's the pattern exactly, and "last-minute rework because something changed by the time developers started building" is the cost nobody puts on the estimate. The look gets signed off, the behaviour gets discovered, and the rework lands in the sprint that had no room for it.
What I've found is that the behaviour is the cheap part to show early if the prototype actually runs: the quick action opens, the flow branches, the toast fires. Once the client has clicked through it, "what happens when I press this?" gets answered in the review instead of in UAT, and the acceptance criteria can be written from what they clicked rather than from what they imagined.
Thanks for the detail on the GIS case, that's a useful one. Anyone else here found a way to get interaction into the review without building it for real?
