Drive User Adoption Through Architecture Decisions

I’ve seen it more times than I can count: a worker filling out spreadsheets, using sticky notes and a shared inbox, with a tailored org open in the background, waiting silently. The system works. The automations fire. The integrations sync. And yet the users have quietly routed around every piece of it. Not because they don’t care, but because the org was never really built for the way they work.

That gap doesn’t open at launch. It opens the moment I make my first architectural decision without asking how a real user will actually move through it: a required field added “just in case,” a page layout built for the edge case instead of the common one, a process that mirrors business logic but ignores the rhythm of someone’s actual day. Users never see the data model, the permission design, or the rollout plan. They feel them in every page, field, and step.

The good news: you can close that gap before a single line of configuration is written. Here’s how.

Set adoption criteria before you design

Adoption problems surface after launch, but the decisions behind them are made weeks earlier, on the whiteboard. Define what “adoptable” means up front, and review against it at the same points where you already review security, integration patterns, and data models.

Add these to your design exit criteria, and don’t move a design into build until it meets them:

• The primary persona for each key object is identified, and the layout supports their most frequent task.
• Required fields are limited to what the user knows at the point of entry.
• Critical actions are reachable in three clicks or fewer from the user’s starting point.
• At least one representative end user has completed the most common task in the design without help.
• Any remaining friction is resolved or explicitly accepted with a documented rationale.

That last criterion matters. Some friction is the right call, such as a compliance field that must be captured early. The updated Salesforce Well-Architected Framework puts new emphasis on making trade-offs visible so architects make them intentionally.

Make the rationale visible to users too. Use field-level help text, Guidance for Success on Path, and validation rule error messages that explain why a field is needed, not just that it’s missing. Users are more willing to accept friction they understand.

Design for the path of least resistance

Adoption rarely fails because users resist change. It fails because the system makes the right action harder than the workaround.

Every user follows a path of least resistance: the sequence of actions they take when nobody is watching. If your design makes the wrong action easier than the right one, users will take it. Not out of malice. Out of efficiency. Your job is to make that path and the designed path the same.

Spot what pushes users off the designed path

• Too many stakeholders on one layout. An Account layout that serves Marketing, Sales, and Operations buries the two fields a sales rep needs to qualify an Opportunity. Give each primary persona its own view instead: use Dynamic Forms with visibility rules, or assign different Lightning record pages by app, record type, and profile.
• Required fields at the wrong stage. When a field is required before users can fill it in accurately, they guess or enter a placeholder. Users get frustrated, and reports fill up with bad data. Require the field at the stage where users actually have the answer, using a stage-based validation rule, rather than making it required everywhere.
• Processes that mirror the org chart. For example, an Opportunity can’t move forward until a separate pricing team approves it from their queue. The rep waits, the deal stalls, and the real negotiation moves into email and spreadsheets. Route only the decisions that truly need another team, and don’t block the rep from progressing in the meantime.

Training won’t close these gaps. It teaches users what they should do, not what they will do when nobody is watching. The Salesforce Adoption Strategies Trailhead module covers the human side of change; your design decisions have to cover the rest.

Walk the process as the user you are targeting

Before you touch configuration, walk through the most common task as the user, not the admin. Then ask:

• What is the most common action? Put it first on the page, with zero navigation.
• What does the user actually know at creation time? Only those fields belong there. Capture the rest later, in context.
• Who uses this page most? Design layouts, Lightning apps, and record types around that primary persona, not the occasional reviewer.
• Where else do users keep this information? If the answer is a spreadsheet, an email thread, or a notebook, find out what that tool gives them that the org doesn’t, usually speed or flexibility. Then build that into the design, or remove the step that sends them there.

The updated Salesforce Well-Architected Framework reinforces this through its Fairness pillar, which asks architects to design systems that are accessible and equitable. Designing for the everyday user, not the power user, is where that starts.

Test the design with a real user before sign-off

Sit down with a real user (not a power user or a UAT volunteer with admin access) and ask them to complete the most common task cold. Treat every hesitation, wrong first click, and detour as an architectural signal that the path of least resistance and the designed path have diverged.

Fix it now. Moving a field during design takes minutes. After go-live, it means retraining users and rebuilding trust.

Build feedback loops into the solution

Adoption doesn’t end at go-live, so design shouldn’t either. Apply the Well-Architected Operational Excellence pillar to adoption: observe how people use the system, and continuously improve it. Failing adoption leaves signals you can detect:

• Fields the process depends on are left blank. They aren’t required in the system, so users skip them, and later stages become harder to complete. Detect it with a report on field completion by stage.
• Records stall in a stage. Detect it with field history tracking on stage and status fields, and reports on time in stage.
• Usage drops off after the first few weeks. Detect it with weekly counts of records created and updated by role, and with the Lightning Usage App for active users and page views.

Design for these signals before you finalize the data model: field history tracking on key fields, timestamps on key objects, and activity data structured for reporting. A dashboard can only show what the system was designed to capture. Ship the adoption dashboard on day one, and agree before go-live on who reviews it, how often, and what triggers action.

The loop closes only when an insight changes the system. If completion of a field drops, check whether users can fill it in at that stage, and move it later if they can’t. If records stall at a stage that waits on another team, revisit the handoff. Then measure again.

Design for phased rollout, not big bang

Big bang launches often fail not because the system isn’t ready, but because the organization isn’t. Every team is affected on the same day, the support queue overflows, and one bad experience erodes confidence in the entire platform.

Treat phased rollout as an architectural decision, not a training strategy. It limits the blast radius, creates feedback loops between phases, and contains adoption problems before the next wave goes live. It also supports the Well-Architected Reliability pillar: a system that can roll back one feature for one group recovers gracefully when something fails.

• Keep each phase independent. Phase one should still make sense if phase two never ships. For example, if phase two introduces a Contract object, don’t make phase one’s Opportunity depend on a required lookup to it, and don’t build a phase one flow that expects contract records to exist. Add the relationship when phase two arrives.
• Use permission sets to switch features on per group. Give users a minimum-access profile and grant each feature through its own permission set group. Roll a new capability out to a pilot group first. Each user absorbs a smaller change at a time, and pilot feedback shapes the feature before everyone sees it. If it creates friction, remove access for that group without affecting anyone else.
• Show each wave only what it uses. Don’t show tabs for features a user’s wave hasn’t received yet. Add them to the Lightning app as each feature goes live. A focused navigation bar keeps early users confident, and it isolates adoption signals so you can tell whether friction comes from the new process or from unrelated features. It takes ten minutes to add a tab. It takes much longer to win back a user who decided in week one that Salesforce wasn’t for them.

Design like someone’s job depends on it. Because it does.

“What does this look like for the person who has to work with it every day?” Asked early and consistently, that question changes every decision that follows: which fields are required and when, how pages are laid out for each role, and whether an approval step blocks a rep or lets the deal keep moving.

Put it into practice in four steps:

• Plan: define adoption criteria before design begins.
• Design: build for the path of least resistance, and test it with a real user.
• Measure: build feedback loops that turn usage data into design changes.
• Roll out: release in phases, so each wave’s lessons shape the next.

The same question applies as you add agents. The framework’s new Agentic Enterprise lens brings agent-driven experiences into scope: when an agent hands work to a person, pass along the context (what the customer asked and what the agent already tried) so the person picking it up doesn’t start from scratch.

Adoption isn’t won at go-live. It’s designed from the first whiteboard session.