Turning a support-dependent financial platform into a self-service experience that gave contractors real-time visibility, clarity, and control over their own money.
Part of a Larger Ecosystem
ProSector provides accountancy, tax, and payroll services to self-employed contractors. Umbrella is where that relationship becomes transactional. As ProSector's umbrella company service, it manages the financial and administrative processes between contractors, their agencies, and ProSector. It's the platform contractors use to submit timesheets, claim expenses, and track payments.
Following the launch of ProSector's Contractor Portal, a unified entry point across the company's multiple services . Umbrella was the first individual service to be redesigned in depth. Where the Portal solved navigation and identity across products, Umbrella owned something more specific: whether a contractor could look at their own account and understand their financial position without picking up the phone.
Above: Ecosystem After redesign
My Role
UX Designer
Over 6–7 months, I collaborated with design leadership, customer experience teams, account managers, and engineering teams to:
Lead stakeholder discovery and workflow mapping
Redesign onboarding architecture across services
Define navigation and information architecture
Establish reusable UX patterns and platform principles
Design responsive experiences across web and mobile
Support implementation, testing, and iteration
The Challenge
Umbrella portal was ProSector's most heavily used product, and it had grown the way most heavily used products do. One feature at a time, with little regard for how they'd fit together later. Menus were disconnected, terminology was inconsistent, and workflows assumed a familiarity most users didn't have.
Most Umbrella users were experienced contractors in their 30s to 60s, working primarily in IT and healthcare professionals who were highly competent in their fields but not necessarily comfortable navigating financial software. Rather than working through the platform's ambiguity, they called their account managers.
The questions were almost always the same:
Have I been paid yet?
When will I receive payment?
Is my timesheet approved?
What expenses can I claim?
Why has my payslip changed this month?
How much have I earned and saved so far?
Every one of these answers already existed inside the product. They were just buried behind unclear navigation, inconsistent language, and a system that had never been designed to answer questions, only to record transactions.
Research & Discovery
We ran stakeholder workshops with the founder, the Client Relationship Director, and account managers to map internal goals against the frustrations they heard every day. In parallel, we fielded an online survey to existing Umbrella users, covering timesheet ease of use, understanding of expenses, the metrics people actually cared about, and what they wished the dashboard showed them.
Going in, we expected to find a usability problem: confusing flows, bad labels, too many clicks. We found something underneath that.
What We Learned
Visibility mattered more than analytics
Users weren't logging in to analyze their finances. They wanted fast answers to a small set of recurring questions like paid or not, approved or not, earned how much and had no interest in dashboards that made them work for it.
The real friction in expense claims happened before submission, not during it
We assumed users were abandoning a clunky submission flow. Instead, most never reached submission at all. They couldn't quickly tell whether something was claimable, and the information that would have told them was a few navigation layers too deep. The cost of finding out outweighed the benefit of claiming.
Timesheets were simple in theory and fragile in practice
Multiple hourly rates, multiple contracts, recurring entries. The underlying work was more varied than the form allowed for, and because timesheets fed directly into payment, any hesitation here escalated into a support call fast.
None of this was really about capability
Contractors weren't confused because the tasks were hard. They were hesitant because they weren't sure they were doing them right. So, account managers had become the only reliable source of that reassurance.
Design Principles
Four principles came out of the research and shaped every decision that followed:
Make financial information understandable
Reduce reliance on specialist terminology; say what things mean, not just what they're called.
Surface actionable information first
Lead with answers and next steps, not navigation.
Build confidence through transparency
Show what happened, what's happening now, and what happens next.
Reduce reliance on human support
Design so the product itself can carry the weight account managers were carrying.
Designing the Solution
A Dashboard Built for Answers, Not Analytics
We consolidated Umbrella around three core modules: Timesheets, Expenses, and Payments, with a dashboard that leads with status, not data. It surfaces payment status, timesheet approval state, year to date earnings and savings, and anything pending the user's attention.
The one exception to "no charts" was deliberate: a simple graph comparing a user's claimed expenses against the industry average. It wasn't there to inform, it was there to nudge, using benchmarking rather than instruction to prompt a specific behaviour.
Turning Expense Claims From Guesswork Into a Habit
Since the drop-off happened before submission, that's where we designed. A Claimable Expense Library made eligible categories searchable and self-explanatory. Users could add multiple expenses in one pass, upload receipts inline, and see status at a glance through color-coded labels.
We also moved guidance out of documentation and into the moment it mattered. contextual nudges like a reminder that a user's typical travel and food claims for the month hadn't been submitted yet. The goal was to close the gap between "this might be claimable" and "I'm confident enough to submit it," without requiring the user to go looking for that confidence themselves.
Making a High-Frequency Workflow Feel Effortless
Timesheets were submitted more often than anything else in the product, so small friction here had an outsized cost. The redesign supported multiple hourly rates within a single contract, multiple timesheets under one engagement, and a simplified way to repeat recurring entries, matching the form to how contractors actually worked, rather than the reverse.
A key tradeoff: flexibility vs simplicity
The more we accommodated real-world contract variation, the easier it became to overwhelm someone who only touched this flow once a week. Early testing surfaced this directly: participants stumbled on actions labeled "Repeat" and "Duplicate". Not because the functionality was wrong, but because the words didn't match their mental model. The fix wasn't simplifying the underlying flexibility; it was being far more deliberate about labelling, hierarchy, and which options surfaced by default versus on demand.
Embedding Guidance Into the Product, Not Around It
Across every workflow, the same pattern kept surfacing: people didn't need help because they couldn't do the task. They needed reassurance they were doing it correctly. We addressed that with contextual onboarding, interactive tutorials calibrated to different comfort levels with technology, and clearer empty states that told users what action was expected rather than just that nothing was there yet.
On mobile, this took the shape of a compact dashboard, bottom navigation for the core modules, and tutorials built directly into the flows they applied to, rather than a separate help section. Payments were split cleanly into Invoices and Payslips, with a "sneak peek" preview showing key figures before a full download. A small change that removed one more moment of uncertainty from the experience.
Before & After
Before
After
Payment and timesheet status are inside specific modules and not readily understandable.
Status visible on the dashboard at a glance
Expense eligibility buried behind navigation and jargon
Searchable Claimable Expense Library with plain-language categories
One rigid timesheet flow, regardless of contract structure
Flexible entry for multiple rates, contracts, and recurring patterns
Legacy Page Designs
Mobile app designs
Validating With Real Users
We tested across contractors with varying tenure and comfort with the platform, focused less on "can they complete the task" and more on "do they feel sure they did it right."
Status visibility needed to be stronger than we assumed. Participants repeatedly asked whether an action had actually gone through and when something last updated. We added clearer status indicators, timestamps, and activity history in response.
Wording carried more weight than the underlying logic. The "Repeat" vs. "Duplicate" confusion on timesheets was a good example of functionally correct design failing on language alone. We rewrote labels and section headers around how contractors actually described the task, not how the system modeled it.
First-time and infrequent users needed more scaffolding than frequent users.
Because many contractors only touched certain flows occasionally, they'd forget the process between sessions. We layered in contextual onboarding and progressive disclosure rather than expecting a one-time tutorial to stick.
Outcomes
20% reduction in support calls.
Once payment status, timesheet approval, and earnings were visible without navigating away, the routine questions that used to go to account managers mostly answered themselves.
30% increase in expense claim submissions.
Making eligibility legible earlier in the journey, rather than fixing the submission form. I moved the number that actually mattered.
SUS score of 73.9
It is above the industry average, with participants consistently describing the redesigned experience as easier to understand and trust than what came before.
Reflection
Going in, this looked like a usability problem: fragmented navigation, outdated interactions, workflows nobody had rationalized in years. The deeper problem was confidence. Nobody using Umbrella was trying to do sophisticated financial analysis. They were trying to answer a handful of plain questions about their own money and the product wasn't built to answer them without help.
Designing for confidence turned out to be a different discipline than designing for efficiency. It meant fewer features, not more. Putting more care into whether the right answer was easy to find, easy to trust and available exactly when someone needed it.
Transparency isn't a supporting feature in a financial product. It is the product.
