Moving the yearly reporting setup from consultants to customers. What was pitched as a one-week clickthrough turned into a four-month project, and I made the case to stakeholders for doing it properly.
My roleProduct designer, and acting PM for stretches: scope, roadmap and stakeholders as well as design.
What this shows Service designScoping & roadmapStakeholder alignmentCross-team work: ops, legal, engineeringSystems thinkingInternal toolsPart one fixed what was broken inside the app. But the research showed most of the consultants' hours went on work that had never been in the product at all: onboarding, account setup and the yearly rollover, all run on calls, spreadsheets and documents.
Onboarding was the clearest case of work that had never been in the product. Every kind of setup ran on calls, spreadsheets and documents, handled by the consulting team one client at a time.
Journey board from contract handover to onboarding, each stage with its pain points on sticky notes: manual data entry, delays, off-platform consulting, lost activation links, confusion over credentials
Pain points along the onboarding journey, from the signed deal to the customer's first login
Mapped end to end, almost every stage was manual, off-platform and waiting on someone. So before any screens we agreed what onboarding should do instead:
Value propositionIn just a few guided steps, new users, from ESG novices to multi-fund managers, set up their accounts, import or collect the data they need, invite their teams and see a clear path to compliance. Early wins and personalised guidance mean less confusion, fewer support tickets and a faster time to value.
→ Less manual work for the ESG and customer success teams
From there I sketched the full flow, step by step, and checked each step against products that already onboard people well.
Onboarding flow from account creation to company account, personalisation, integrations, inviting collaborators and a success screen, each step with its fields and a reference screen from another product
Onboarding flow, benchmarked: each step with what it asks, next to how 15Five, monday.com, Airtable and others handle the same moment
We picked the new reporting year first because it looked like the quickest win. These are existing customers who are already set up. Nothing new to configure, just roll the previous year forward. It also came round for everyone at once, so automating it would take a predictable, repeating load off the team.
I was the designer on this, and for stretches of it the PM as well. The interface turned out to be the last problem, not the first.
It was scoped as a straightforward piece of design. A week, roughly. The estimate came off a clickthrough someone had generated with AI: real-looking screens, a flow that ran end to end, dropdowns full of plausible options. Take the steps a consultant already followed and put them on screen.
AI-generated clickthrough prototype of the organization mapping step
AI-generated prototype
Discovery killed that. To let a customer set up their own reporting year, the product needs to know what that customer actually has: which frameworks they report against, which funds, which features they pay for. None of that existed in a form the product could read. Contracts weren't standardised, and what had been agreed was recorded nowhere except in PDFs.
Service and contract configuration table mapping service types, metrics, and required platform features and modules
Contract terms, mapped to services, metrics, and the platform features and modules each one requires
So the real first task wasn't the flow. It was getting to a standardised backend representation of every customer's setup, so the product could tell each one what applied to them and what didn't. That's the cost of moving work that was never designed to live in software: before you can build the screen, you have to make the thing behind it legible.
A week had become months, and that needed a decision from the stakeholders. We put every obstacle on the table: contracts that weren't standardised, setups recorded nowhere the product could read, rights and ownership still to work out with legal. Then we showed what doing it properly would buy: customers setting up their own reporting year, consultants out of the yearly setup crunch, and a structure every later feature could build on.
The alternative was shipping the clickthrough and patching it later, another half-baked onboarding. We'd lived with one of those already, and we weren't going to ship a second. They agreed and gave us the time we asked for.
It took closer to four months, build included.
Four steps: org structure, reporting setup, data requirements, submit. It carries the customer's existing configuration forward and asks them to confirm what changed. Behind each step sat a problem the screen doesn't show.
Org structure had a database already, but every entity in it had been added by hand. Letting customers build their own meant representing a tree the product had never had to hold, and the hard part wasn't the shape. It was rights and ownership: who can see which branch, who can edit it, what a group-level user is entitled to across entities they don't directly own. That took a few rounds with legal on GDPR.
Planning notes, Slack thread, and diagram mapping org tree requirements and permission cascades
Working out the org tree structure and permission cascade
Reporting setup was where the contract problem surfaced for the user. Once entitlements were standardised, we could show them plainly: this is what you're reporting on, this is what your contract covers, this is what the platform does that you're not currently buying. That last line was a side effect worth keeping: a customer showing interest in a module they didn't have now had somewhere obvious to be noticed and passed to sales.
Specification mapping network standards to data requirements per reporting level, with options, tooltips and edge cases per standard
Mapping every reporting standard to what it requires at GP, fund and portfolio level
Data requirements falls out of the step before it. Once the reporting setup is machine readable, the required data points are derivable rather than assembled by a consultant. That screen is mostly a consequence.
Reports setup screen listing frameworks with configuration status, next to fund-level reporting requirement selection
Reports setup with data requirements configuration
Submit isn't the end. The flow is self-serve, but the output wasn't trusted enough yet to go straight through, so the last step is a person. The ESG team needs to see what changed, not re-read the whole configuration, just the delta. A reviewer who has to reconstruct the change from scratch stops reviewing within a month.
Internal admin screen showing reporting setup changes for a customer, with a diff between the previous and new year's values and an approve or reject action
The backend admin screen, where the ESG team reviews the delta before approving
Making that check intelligent enough to disappear is phase two. The first release had enough in it: a structure builder, a contract model, a derived requirements layer.
The year setup moved from the consulting team to the customer. Consultants now review the result and pick up anything a customer has flagged, rather than working through every account by hand. Still work, but a fraction of it, and it stopped landing on the whole team in the same few weeks.
Atlas home with a What's next list
Part one Inside the app Research that reframed the problem, then a home, data collection and framework dashboards rebuilt around what to do next. Read case study Overview Atlas Metrics Back to the full project: design system, product chapters and impact. Back to Atlas
Angelo Wellens, Product Designer
Builds from first idea to launched product
