Integrating UX into Salesforce Delivery — Case Study
OpenAI brought me in as a Salesforce UX expert to answer one question: how do you build UX and UI into a Salesforce project from the start? This is the delivery and staffing model I gave them. It’s built on a decade of Salesforce programs, and the call was extended past its scheduled time.
ROLE:
Salesforce UX/UI subject-matter expert (consulting call)
CLIENT:
OpenAI
YEAR:
DELIVERABLE:
Recommendations on process, staffing and effort, later turned into an 11-slide reference deck
The question
OpenAI was planning Salesforce work and wanted to get UX right from the beginning. They asked three things:
1. When should designers join the project pipeline?
2. How much of their time goes into the project’s deliverables?
3. Who should be staffed, and for how long?
Why it matters: the cost of bringing UX in late
I’ve been called into many Salesforce projects after development had already started. The pattern is usually the same:
1. UX isn’t in the project’s scope, so development starts without it.
2. Deliverables reach the client, and the client asks, “Where’s the UX thinking?”
3. I’m brought in to fix it, which means reworking screens and code that already exist.
Rework at that stage costs far more than designing up front. My answer to OpenAI was built to prevent that situation.
Where the model comes from
The model started on the Entergy program, where I set up a sign-off pipeline from wireframe to code to get a stalled project back on schedule (see the Entergy case study). I refined it over later projects at TCS and Deloitte.
What those projects taught me is that this is a foundation, not a formula. Every client differs in timeline, budget and team, so the stages stay the same but the staffing and durations change.
The model: five stages, one track
I described the process as a train: five cars on one track. Each car has its own specialists and hands a concrete deliverable to the next. The track is the Salesforce platform itself (SLDS, Lightning components and org governance), which limits what every car can deliver.
| Stage | Who's involved | Handoff to the next stage |
|---|---|---|
| 1. Discovery | Stakeholders, users, business analyst, technical analyst, systems analyst; UX designer optional to sketch live | Prioritized requirements |
| 2. Story definition | Business, technical and systems analysts | Approved epics and stories in Jira |
| 3. Design | Lo-fi UX designer, hi-fi UX designer, UI front-end developer | Signed-off designs plus a built UI framework |
| 4. Build | Scrum master, developers | A working feature in the dev sandbox |
| 5. QA & validation | QA team, user testing | Validated feature promoted to production |
The key step is in Design. A UI front-end developer builds the layout and styling in Salesforce before Build starts, so backend developers only have to connect data and functionality. That separation is what prevents the late-UX rework described above.
Staffing and effort
The main staffing principle: staff to the work, not the calendar. Roles join when there is real work for them and leave when their stage is done.
| Stage | Who's involved | Handoff to the next stage |
|---|---|---|
| 1. Discovery | Stakeholders, users, business analyst, technical analyst, systems analyst; UX designer optional to sketch live | Prioritized requirements |
| 2. Story definition | Business, technical and systems analysts | Approved epics and stories in Jira |
| 3. Design | Lo-fi UX designer, hi-fi UX designer, UI front-end developer | Signed-off designs plus a built UI framework |
| 4. Build | Scrum master, developers | A working feature in the dev sandbox |
| 5. QA & validation | QA team, user testing | Validated feature promoted to production |
On a tight budget, one designer can cover both lo-fi and hi-fi work. Effort by stage. A typical design-to-production cycle takes 6–8 weeks. The share of effort for each stage:
| Discovery | Story definition | Design | Build | QA & validation |
|---|---|---|---|---|
| 15%1–2 wks | 10%0.5–1 wk | 30%2–3 wks | 30%2–3 wks | 15%1–2 wks |
Design gets the same share as Build. That’s the answer to OpenAI’s “how much” question: UX is as large a part of the work as development, not a small add-on.
How users shape the work
In this model, user research happens in the Discovery workshops, where stakeholders and users set priorities together. From then on, every stage has a sign-off, so requirements, stories and designs are all approved before anything gets built.
User testing comes in QA, on the working feature. Because each stage was already signed off, QA feedback goes one of two ways: it’s fixed now as rework, or it’s added to the backlog for the next release. That keeps a release on schedule without losing what users said.
Reflection: a foundation, not a formula
If I built this for a specific company, three things would change it most:
• Timeline. Shorter projects overlap the stages more and run discovery in parallel with story writing.
• Budget. Smaller budgets combine roles, for example one designer covering lo-fi and hi-fi work.
• Skills. The right person for each role depends on the platform (Experience Cloud and Service Cloud need different skills) and on what the budget can pay for.
The five stages and their handoffs stay the same. Who rides in each car, and for how long, is what gets tailored.