A portal people actually use

A lot of my work is portals. Intake forms, referral pages, places where a childcare provider keeps a license current or a partner organization checks where it stands. Many of them run on Salesforce Experience Cloud. The platform is capable. That's rarely the problem.

The problem is that a portal can launch, work exactly as specified, and still not get used. People call instead. They email the PDF. They keep the spreadsheet. On paper the portal is live. In practice it isn't. If the designs we make aren't used, then they don't exist.

Here's what I've learned about building the other kind.

Picture the person, not "the user"

The people on the other side of a portal are usually tired, usually mid-task, and never reading the manual.

At Pacific Clinics, the portal is the front door to a behavioral-health program. A referral isn't an enrollment. Between the two sit a form, a phone tree and a wait. And the people being referred are the ones least able to absorb friction: someone in crisis, someone without stable housing, someone on a phone with a cracked screen.

The enrollment page, which I built from a design partner's design, handles that well. One card. Two sentences that say what the program gives you and that it's free. Then two ways forward, the same size, side by side: chat now, or schedule a call. A person who wants a human never has to get through the chat to reach one. Everything else lives behind the buttons, because the person reading may have thirty seconds of attention. The page also says, at the top and the bottom, that these channels are for non-urgent needs, and to call 988 if you need help now. On a phone, that notice stays on screen.

None of that is decoration. Each choice is about someone's worst day.

Ask who's there before you ask anything else

Portals often fail by asking everyone the same questions. Inglis, a disability-services organization, runs six programs and takes referrals from hospitals, nursing homes, assisted-living facilities, family members and prospective residents. Five kinds of person, each with different information on hand.

So the first question on the intake form I designed isn't a name. It's "Who is filling out this form?" Everything after that branches on the answer. That adds a step before anyone sees a field they recognize, and it's real friction for someone filling the form out in a hard moment. It's worth it. The alternative is a hospital referrer being asked a family member's questions and giving up halfway.

The same form lets someone pick more than one program, so a person who needs housing and employment support says so once instead of filing twice. Another team built it from my wireframes.

Put what they came for where they can see it

Providers come back to the Child Action portal for a handful of reasons. Find a training. Register. Check their hours. Keep their license current. The license date is the one that can shut them down, so it sits on the profile, visible without a click, next to a note when something needs renewal. Nobody has to go looking for it.

The events calendar filters six ways, including "open seats only." It's the filter people actually need, and the one most calendars bury.

Make the first release boring

The temptation with a portal is to launch everything at once. I'd rather the first release be boring and shippable.

For Changent, the first phase of the partner portal I mapped gives each partner organization a dashboard of what's due, what's overdue and what changed, plus what they need to see about their own standing. Anything that depended on data the new system hadn't produced yet was left out. At Zero To Three, an organization running 42 systems, the portal I designed starts the same way: my work, due soon, overdue. The bigger features wait for later phases, when the data underneath can be trusted.

A small portal that works on day one earns the trust a big one needs.

Required isn't the same as used

You can make people log in. You can't make them use it.

At Mattress Firm, sales associates were required to use their tablet app. The notes screen was so cramped that they chose not to use the notes. The app was in use. One of its features wasn't. A login count wouldn't show that. The interviews did.

So measure adoption, and measure it honestly. Not just logins. Count whether people finish the thing they came to do. Count how many still call, email or use the old way. Count the support tickets about the portal itself.

At NASA, I studied why scientists weren't moving from an old data-search tool to its replacement. The analytics showed the old tool still carried 58.6% of users, and almost two-thirds of its users used nothing else. That's an adoption number. Watching people do their own real work showed why: the new tool made them add files one at a time. The findings went into the backlog and were worked. When the old tool retired, its users moved over.

Take your measures before launch, and again a month after. Then you know whether the portal is being used, and where it isn't.

The short version

Design for the tired person mid-task. Ask who they are before you ask anything else. Put what they came for in plain sight. Launch something small that works. Then count whether they came back, and go and watch the ones who didn't.

If that sounds like your situation, let's talk.