Salesforce and AI: When Mastery Becomes Personal

Understanding How Designers Master AI

Mastering an AI tool is not just about learning how to use it correctly. It’s about learning to adapt it to your way of thinking — and this type of mastery is personal, divergent, and never complete.

Every designer receives instructions on how to use AI tools. Few truly understand what it means to master such a tool. And underlying this is a question that almost no one dares to voice during the integration of these tools: if these tools become sufficiently powerful, what will happen to jobs?

Most organizations attempt to solve these three problems with a single training plan. This does not work. The designers I work with feel an equal mix of excitement and anxiety, often at the same moment. They have in their hands a category of tools that do not behave like the software they are used to, and the conventional response — giving a presentation, organizing a workshop, declaring mastery — continues to produce the same result: a room full of people who feel behind, even as they try to catch up.

This essay discusses what happened when my team stopped trying to solve the problem in this way. And it addresses the word mastery itself — which I do not want to abandon. I want to redefine it.

A New Approach

On October 1, 2025, eighteen people were on a video call, just minutes before nine AM PST. I want to start here because what Fatimah Richmond opened during this session did something I had been waiting for almost a year.

She said, “I am not an expert.”

She is, of course. Just not in the sense that matters here. No one is. That’s the whole point. Fatimah — a UX researcher, published poet, twenty years in the valley, with DeepMind on her resume — had joined the Salesforce UX Service team earlier that year, coming from a world where Gemini was the default tool for almost everything. She brought the instinct of a researcher for knowledge management and a territorial storytelling relationship with the voices of participants. She was exactly the right person to kick off our series — not because she had answers, but because she had quietly built a personal practice that no one else on the team had yet.

The tool she was about to show us was NotebookLM, a Google product for synthesizing large amounts of documents. She had used it to extract insights from years of accumulated research at Salesforce — studies conducted by people who had since left, knowledge residing in documents that no one opens anymore. She called it “the smart notebook.” That was not Google’s name. It was hers. A mental model she had developed herself, from her particular perspective.

This was the first session of a co-learning series that would last six months for the UX Service team at Salesforce — forty-six designers in the U.S., India, and Israel, all trying to understand the same thing: what to do with these tools that are arriving faster than we can assimilate them?

Ningdan Zhang — senior product designer and my co-facilitator — and I designed the series together. This shift in perspective is important from the outset, as it changes what this essay is about. We created the structure together, the scaffolding session by session, the instinct of what the team needed week after week. We brought the hypothesis and the narrative arc. Neither of us knew if it would work. This is not a retrospective. It’s a design case study — which began with a shared question, lasted six months, and produced a discovery I did not expect.

A Paradox to Solve

The problem we were designing for had a specific shape. The designers on the team felt a paradox: genuine excitement for AI tools, accompanied by significant anxiety about which ones to use, when, and how. Beneath that lay the more discreet question of which jobs might not exist in two years. Announcements were coming quickly. Structured guidance was overwhelming or missing. Everyone was trying to figure it out independently — duplicated efforts, inconsistent workflows, pressure to have a coded prototype to show without any shared foundation on how to build it.

Our hypothesis was simple, perhaps naive: what if we simply learned from each other? Two thirty-minute sessions per month. One tool, one task to accomplish, an in-depth initiation session on a tool, one person ready to share what they had actually understood — imperfectly, along the way, without needing to have the answer. We covered everything the team asked for: NotebookLM, Slack AI, Cursor, project spaces (Claude, Gemini Gems, OpenAI), Salesforce design system tools, Figma Make, Wispr Flow.

What we did not anticipate was what the format would reveal about the nature of the tools themselves — and what it truly means to master them.

A Category Error

There is a category error that occurs when organizations try to teach AI tools in the same way they teach other software. Traditional software training works because the tools are deterministic. You learn where the buttons are, what the shortcuts do, how the system behaves when you click something. Mastery, in this world, converges — everyone reaches roughly the same level of competence, following roughly the same path, and you can write a presentation for that. Mastery means knowing the correct use of the tool.

AI tools break this definition. Maggie Appleton — designer and anthropologist, now at GitHub Next — gave a talk in 2023 titled “Squish Meets Structure” on designing products with language models, and the phrase I love is her description of the magic inbox: it has “no affordance,” “no button or doorknob.” The interface, she writes, “offloads a ton of cognitive work onto the user.” There is no correct use to learn. The tool meets you where you are. What you bring — your instincts, your mental models, your accumulated taste, your willingness to iterate, your custom files claude.md — is part of the tool, just as much as the model.

Thus, mastery has not disappeared. It has changed. With deterministic software, mastering the tool meant converging on its logic. With AI tools, mastering a tool means the opposite: learning to adapt it to your logic. Adapting it to the way you already want to work. Mastering an AI tool is the art of making it amplify the specific strengths and experiences you bring — so that the work produced is more precise and undeniably yours. This type of mastery is real, difficult to acquire, and worthy of being taught. It is simply personal rather than universal. Divergent rather than convergent. Each person's version should be different, as each person's version is built from a different individual.

This is where most training plans go wrong. They aim designers toward the old form of mastery — a single skill, ratified by a curriculum — while what is truly worth achieving is the new form. And the new form cannot be transferred through a presentation. Top-down mandates fail not because designers are resistant, but because you cannot give someone a good relationship with an AI tool. You can only create conditions in which they build their own.

This does not undermine institutional support. It is an argument for two layers working in tandem. The Salesforce UX Ops team does essential work that a peer series like ours could never do: approving tools, managing governance, deploying learning modules and hackathons, navigating token budgets, unlocking access. They have built the necessary infrastructure — the scaffolding that makes scale possible. Without that, individual experiences remain isolated. But the type of knowledge that Fatimah was about to share — which lives in a thirty-minute session where a colleague shows you their real notebooks, their workarounds, their personal information architectures, the thing they tried that didn’t work — cannot live in a module. The peer layer is where mastery, the personal type, is truly transmitted. Both are necessary. Neither replaces the other.

Back to Fatimah

What made her session noteworthy was not the tool. It was the mastery she had built around it — exactly the personal type. She had learned, through trial and error, that it is not enough to throw everything in — the notebook requires curation, sources speaking the same language, aligned topics so that the reasoning engine does not “speak to someone who is wandering off.” She had added summary tabs to the participants' transcripts, not because a tutorial told her to do so, but because the raw transcript was too messy, too human. She had discovered that the audio feature was unreliable for her use case — research synthesis where tone matters, where the exact words of a participant carry weight — but could work well for integrating a new partner into three years of accumulated knowledge.

None of this came from documentation. It came from her — from twenty years of research practice, from the instinct of a storyteller to protect the voices of participants, from a researcher’s need to curate before analyzing. The tool was the same as everyone had at their disposal. What she had built with it was her own. She had taken a generic instrument and adapted it, precisely, to refine the work she already knew how to do.

Aditi Sharma, a senior product designer on the team, named what we were all looking at without really seeing. In the post-mortem survey, she wrote that what she appreciated about these sessions was “a window into someone’s thinking.” This phrase is the whole discovery. When everyone uses the same buttons, watching a colleague work is informative but not revealing. When mastery is personal — when the same tool produces radically different work depending on who wields it — watching someone use it well becomes a window into their way of thinking.