Case study · Client Portal North Star · Australian financial advisory firm · 2024
Onboarding clients who would rather not be there.
A financial advisory firm wanted its clients off unsecured email. Only 17% of clients said they would prefer to manage their services online, and the easy read was that there was no appetite for a portal at all. I put that number against the diffusion of innovation curve and found something different. This client base is tech conservative, so its early adopters are a far smaller group than usual, which meant the portal had to be built for the least confident client rather than the most capable one. That reframing shaped the onboarding I designed, and the strategy and prototypes we put in front of executives to decide whether to build a new portal or extend the one they already had.
All interfaces below are recreations built for this case study. Branding & details changed; no client IP shown.
Context & stakes
There is a moment in our journey maps I kept coming back to. A client receives an invoice by email, and before they can pay it they have to work out whether it is real. They check the sender address. They squint at it. The question written on that journey map is “is this a scam?”
That question is the whole problem. The firm does accounting, tax, wealth, audit and advisory work for everyone from individual taxpayers through to enterprise clients, and a great deal of that work was arriving in people’s inboxes. Invoices, agreements, requests for documents. Meanwhile the fraud around it had become very good. The research I pulled together included a finance worker who paid out $25 million after a video call with a deepfake chief financial officer, and a father who heard his son’s cloned voice on the phone. When we mapped what clients told us trust actually meant, one of the things they said was that they needed to be able to verify their relationship with us by checking an email address. That is a fragile thing to hang trust on.
So the business goal was clear enough. Provide a secure digital touchpoint between staff and clients, reduce the risk of sharing data and files over unsecured email, and turn off email attachments altogether. The goal was never the hard part.
I need to trust you.
Client need, research synthesis
I need more convenience.
Client need, research synthesis
I’d like to do everything on my phone.
Client need, research synthesis
My role & ownership
I was one of the product designers on the Client Portal North Star. I led the research synthesis for the whole project, which meant pulling together the staff survey, client NPS data, a journey analysis, an industry and competitor teardown of four fintech players, and an analysis of the portal the firm already had, then turning all of it into a strategy the rest of the team could design from. I owned the onboarding flow end to end.
The companion piece I also owned, a 7-question Service Wizard that turns life context into service recommendations, has its own case study.
The central conflict
The tension sat between two facts that did not want to agree.
The business needed clients online, and it needed that soon, because every month on email was another month of exposure. The research said only about 17% of clients preferred to manage their services online.
There is a slide in my deck that says nothing except Business Goal ≠ User Goals, because I kept needing to say it out loud. Designing only against the compliance mandate would have built something clients had already told us they did not want, and adoption would have proved the point for us. Designing only against what clients said they wanted would have missed the risk entirely. The work was finding the version where both could be true.
I need to trust you.
Client interview, client research
I need more convenience.
Client interview, client research
I’d like to do everything on my phone.
Client interview, client research
What 17% actually meant
Everything turned on that 17%. It is an easy number to read as a verdict. Only 17% want this, so why are we building it?
I did not think that was what it said, so I put it against the diffusion of innovation curve. In a normal population, innovators and early adopters together are roughly 16% of people, which means a 17% appetite is about what you would expect for a product that does not exist yet. But this client base is not a normal population. It skews tech conservative, so the curve is negatively skewed. Its genuine innovators and early adopters are closer to 6%, and the group directly behind them is around 9%.
The 17% was never a ceiling on interest. It was the shape of the people we were designing for.
That changed the brief. It meant building for early adopters was a dead end, because there were barely any. Whatever we made had to work for someone who is not confident, is not curious about new software, and is not going to persevere when it gets hard. Build for them and the majority can follow. Build for the 6% and nobody does. Every decision after this one leans on it.
What clients told us they actually wanted
Alongside the numbers, the research kept returning three needs, and none of them were about software. Clients wanted to trust us, they wanted less work, and a good number of them wanted to do the whole thing from their phone.
So I reframed what we were measuring. Customer experience here comes down to three things. The level of trust, the quality of support, and the quality of the deliverable. A digital experience cannot improve the quality of the tax return itself, but it can absolutely move trust and support. That became the test I held every design decision against, rather than simply moving people off a channel.
There was one more thing clients said, and it turned out to be the hardest to design for.
I need financial help, but I don’t know what financial service I need.
Recurring client quote, client research
The fork in the road
The firm already had a portal. It was built around timelines, threads, posts and replies, which is to say it was built like Slack or Teams. Adoption had stalled. So the real question underneath “design the onboarding” was whether that shape was right at all, because onboarding people into the wrong product only gets them to the disappointment faster. I worked through it as a set of questions and answered them honestly.
Does a thread and post interface fit what we are actually selling?
It depends entirely on who the client is and what service they have bought. For most of them, no.
Is there a clear path from open chat to productised services?
Collaboration software is built to host unstructured conversation. A productised service needs structure and a well defined flow.
Do we want to encourage unstructured conversation?
Moderating hundreds of thousands of unstructured chats would be enormously labour intensive, and it hands the work back to the client. Less effort for the client, the better their experience.
Every answer pointed the same way, so I recommended we stop treating the portal as a conversation and start treating it as a set of structured services, where every interaction arrives already shaped as something to act on. That did not mean stripping the relationship out. The model I landed on separates the account, the entity, the service and the individual step, then places each interaction somewhere on a line between relational and transactional. Keep the highly relational interactions where they make sense, because that is what people are paying for. Complement them with transactional ones that make things more convenient for the client without adding work for the firm.
Two scenarios, one shared core
The firm acquires portal users through two distinct paths, and treating them as one flow would compromise both. So I designed a shared account creation core (verify identity, set password, confirm device) and bracketed it with scenario-specific entry and exit states.
Scenario 1. Existing client activates
The trigger is an invitation email. Given that the whole problem started with clients squinting at emails wondering whether they were real, this one had to work harder than most. I led it with the purpose rather than the credential, so the first thing you read is what you are being invited to do, not a password you have to use before it expires. Authentication then moves to phone verification and an optional device trust, which is passkey eligible. Passwords are easy to guess and easy to steal, and a passkey is both safer and faster for someone who does not want to think about it.
Your client portal is ready, Alex
Manage your services with us, online.
Your advisor has set up your secure portal account. See your documents, meetings and services in one place, without anything travelling over email.
Activate my account
This secure link is unique to you. No temporary password, nothing to expire.
Activation email · purpose-led, not credential-led. Recreation.
Scenario 2. New client signs up
A new client arrives and enters the account creation core. They confirm the details we already hold, create a password, verify their phone with a six digit code, and then choose whether to trust the device. Every step has one primary action and nothing competing with it. Help sits on every screen without shouting. Progress is visible the whole way, because for someone who is not confident with software, knowing how much is left is the single biggest thing you can do to lower the temperature.
Confirm these details
We’ve pre-filled some details for you. Please check that they’re correct.
First name
Last name
Email address
01 · Confirm details
Create your password
To get started, please create a secure password.
Password
At least 9 characters, containing a letter and a number.
02 · Create password
We just sent you a code via SMS
Enter the 6-digit security code we sent to +61 ••• 452.
Didn’t receive a code? Resend
03 · Verify via SMS
Do you trust this device and browser?
Plan on coming back regularly? If you choose to trust this device, you won’t be asked for a security code next time you sign in.
04 · Trust device, optional
myPortal
You’re all set up!
Your account has been created. There is a lot you can do to make the most of the portal:
- Manage files & documents in one place
- Instant notifications to keep on top of tasks
- Schedule one-off or ongoing meetings
- Find all your information in one place
05 · Safe landing
The four-step account creation core plus its landing state. Recreations.
A decision I changed
My first onboarding draft bundled service selection inside account creation as a single flow. An internal review surfaced the issue I’d missed. It conflated having an account with having a service. Clients with existing services who got pulled into a wizard felt like they were being re-sold to, and the advisor community flagged the same risk from their side of the room.
So we split the flows. Account creation completes at “You’re all set up.” The Service Wizard becomes a discoverable, optional next step. Not a gate. That separation is what gave the design somewhere to stand when it went back to the advisor community. Wizards that pressure-sell were a non-starter for them, and rightly so.
myPortal
Not sure which service fits?
Answer 7 quick questions about your goals and we’ll suggest services suited to you. Or browse the full catalogue any time.
Optional, never a gate
Detail decisions · Progress + reassurance
Progress bars on every screen. Help always visible. Trust-device offered as an optional passkey, not a forced setting. For a tech-conservative audience, knowing how much is left is the single biggest anxiety reducer.
Making the case without a villain
The honest version of this part is that nobody fought me on it.
The existing portal had been built a long time earlier, at a point when product design was not really consulted, and largely by designers who had since left. So there was nobody in the room defending it. That sounds easier than it was. When there is no one to argue with, there is also no one who owns the decision, and it becomes very easy for a recommendation like mine to be heard as criticism of work the business had already paid for and was actively rolling out.
So I did not frame it as criticism. I framed it as a decision. The deck ends with the choices set out as questions for the sponsors rather than conclusions from me. Do we stop rolling out the existing portal, or roll it out knowing a replacement is coming? Do we build something new, or extend what we have? For each option I laid out what it would cost, what it would risk, and what it would mean for staff who would otherwise have to learn two portals at once.
I also put a disclaimer on the prototypes, in writing, saying they were not definitive visions of the product and that any real build would need the business and the engineering team in the room to work out what was viable and feasible. That was not hedging. It is the difference between a designer handing down an answer and a designer handing over a decision.
What came of it
The work produced a UX strategy, a set of design recommendations, and four prototype explorations covering account creation, the Service Wizard, the service interface, and billing and payments. We took it to executives and the board as the basis for a real decision about whether to build a new portal or extend the existing one.
I want to be straight about what this case study is and is not. There is no adoption chart at the end of it. This was a strategy and design engagement, and what it produced was direction and a decision point, not a shipped product with a metric attached. The value was in what it made possible to decide, and in the fact that the decision got made on evidence rather than on momentum.
What didn’t work
The vision we were designing towards had an asterisk on it. It said the specific target demographic and market segment still needed to be clearly defined by the business, and while I was on this project that never got resolved.
I kept going anyway. Designing for the least confident client was the right instinct and the diffusion curve gave me enough to work with, but tech conservative is a description of a population, not a decision about who we are for. The two segments we mapped wanted genuinely different things. Consumer clients wanted a personal relationship supported by self service. Corporate clients wanted professional relationships supported by self service and collaboration. Without the business committing to which came first, some decisions stayed softer than they should have been, and prioritisation questions I thought were settled kept reopening.
What I would do differently is refuse to carry that ambiguity quietly. Not by stalling the work, but by putting the question in front of sponsors as its own decision, exactly the way I did with build versus update, instead of absorbing it and designing around it. I was comfortable making the portal decision explicit. I should have been just as comfortable making that one explicit too.
Reflection
The thing I carry forward is what happened with the 17%. A low number is not automatically a verdict. Sometimes it is just the shape of the people you are designing for, and once you understand the shape, the number stops being discouraging and starts being instructive. It told us exactly where to start.
The other lesson was about the difference between being right and being useful. I could have written a deck that said the existing portal was the wrong shape and left it there. That would have been correct, and it would have gone nowhere. Turning it into a set of decisions, with the costs and the risks of each option laid out honestly, is what gave the work somewhere to land.
Mostly this project taught me that the research is not the deliverable and neither is the prototype. The deliverable is a room full of people who can now make a decision they could not make before. Everything I did here, the reframing, the questions, the prototypes, was in service of that.