Concept
MOBILE · Enterprise SaaS · AI-Powered CRM Feature
A solo concept for turning a fading moment of context into a next step a rep can act on.
Quick facts
Company
Salesforce Sales Cloud
a concept AI feature designed for Salesforce’s existing mobile app
My role
Full concept-to-prototype
identified the user need and product opportunity, designed and prototyped the mobile screens
Team
Solo project
Timeframe
5 weeks
(open prompt: add a feature to an existing mobile app)
Status
Concept project
Not shipped
The problem
A CRM that captures data well, but doesn’t help anyone decide what to do with it.
Business problem
Salesforce already captures customer data well, but it doesn’t help reps decide what to do with it. That can contribute to slower follow-up, less reliable forecasts, and deals losing momentum between meetings.
User problem
Reps leave customer meetings with the clearest understanding of a deal they’ll ever have, then lose most of it to delayed CRM updates and scattered notes before the next meeting on their calendar.
Constraints
3-week solo concept sprint
No access to real enterprise Sales or Delivery teams
Needed to define a focused MVP within a broad problem space
How I got there
Starting from evidence, not an idea I already liked.
Secondary research
I started by looking for evidence that this was a real problem rather than an interesting idea. App Store reviews, Reddit discussions, and product demos all pointed to the same pattern: reps relied on Salesforce to store information, but much of the work surrounding a customer meeting happened elsewhere.
Synthetic research, verified
Because I couldn’t recruit Salesforce users during the sprint, I used synthetic research to explore possible interview responses based on recurring themes from public sources. I treated those findings as hypotheses and checked them against interviews and moderated usability testing before they influenced the design.
Enterprise CRM has no shortage of good ideas competing for the same screen (opportunity scoring, forecasting integration, analytics dashboards). I cut all of them. They help people understand the business; they don’t help a rep act in the two minutes after a meeting.
Before committing to the concept, I discussed it with a Salesforce UX designer to test whether the opportunity felt realistic. The conversation gave me confidence that the direction aligned with real challenges inside enterprise CRM.
Interactive Prototype
Experience the after-meeting mode yourself.
The decisions
Three decisions, each with a real trade-off attached.
01
Designed within the existing workflow
Rather than building a separate AI destination, I embedded the assistant into Salesforce’s Opportunity page, designing within Salesforce’s existing Lightning Design System (publicly available on Salesforce’s Figma) instead of inventing new visual patterns.
Since I didn’t have access to the live Salesforce mobile app, I had to use my own judgment on how desktop Lightning patterns should translate to a mobile. The feature itself is a net-new flow, so I took creative license there while staying as close as possible to existing conventions elsewhere.
02
Turned fragmented signals into a decision, not more fields
Instead of asking reps to fill in more of the CRM, the assistant generates a concise deal narrative, one prioritized next step, and risk flags, each with its reasoning shown, not just a confidence score.
03
Built trust through human oversight
This one started as a hypothesis from my own professional experience working inside a CRM, not from testing: I suspected reps would want risk flags private by default rather than automatically visible to their manager. Real interviews and moderated testing confirmed it. Every AI-generated item in the final design is reviewed, edited, or dismissed before it touches the record.
AI as a research tool, not the story
Used to fill a real access gap, not to design the screens.
I used ChatGPT and Gemini for research synthesis, most directly to turn real public sentiment patterns (App Store complaints, Reddit threads, YouTube demos) into a synthetic focus group grounded in those patterns, since I had no access to real Salesforce mobile users.
I treated that synthetic round as directional and checked it against real human interviews and moderated testing before it shaped final decisions. The actual screens and interactions weren’t AI-generated; they came from my own design judgment, working as closely as possible within Salesforce’s public Lightning Design System.
Measuring success
I wanted to measure not only whether people used the feature, but whether they trusted it enough to improve CRM data over time.
Reflection
Designing modern enterprise software reinforced that AI alone doesn’t create value unless it fits naturally into the way people already work. Adoption depends on fitting existing workflows, explaining its reasoning, and keeping real decisions in human hands. This project shifted how I think about design: less about shipping features, more about shaping the decisions a product helps someone make.
What I’d do differently
The biggest gap in this project is real Salesforce mobile access. I did my best to translate Lightning’s desktop patterns to a mobile surface using judgment and public design system documentation. In the future, I’d want actual usage data or a session with a Salesforce mobile PM to confirm those translation decisions hold up, especially anything involving gestures, offline states, or notification timing that a desktop-first design system doesn’t fully specify.
I’d also want to test with real field reps beyond the moderated round I was able to run, since the risk-flag-privacy finding in particular deserves more than one validation pass before I’d trust it in a real product decision.
© 2026 · Michael Cowen · Product Designer