top of page
Bringing reporting in line with how ownership groups actually operate.
Information architecture | Interaction design | Collaboration | UI
Overview
Agencies in Australia rarely operate as single offices. Most established agencies are part of an ownership group: a parent business with multiple offices underneath it, often sharing a brand and a leadership team. About 30% of REA's customer base operate this way.
For years, REA's products had treated these offices as standalone businesses. That created a problem on two fronts. On the consumer-facing side, multi-office agencies in the same ownership group appeared as competing entities in search and listing results. On the reporting side, the principals running these businesses had no way to see their performance across the whole ownership group, only as a collection of separate offices they had to mentally reassemble.
Understanding the problem
The consumer-facing inconsistency was addressed first. But that change opened a gap. The same agency was now represented one way externally (correctly, as a unified ownership group) and a different way in the reporting they relied on to run their business (still as separate competing offices). Agency Group Reporting set out to close that gap, so that principals could see and manage their group as the single business it actually is.
Q.
How might we help agencies get a full and accurate view of their reporting data so that they don't have to use manual workarounds?
The design hypothesis
If we introduce ownership-group-level reporting in Ignite, with the ability to flexibly combine offices and suburbs, and align rankings with how the group is represented on the consumer site, then ownership groups will feel REA reporting reflects how they actually operate.
Designing the changes
Because the case for ownership groups had already been made on the consumer side, this project didn't begin with a fresh discovery phase. The structural mismatch was visible in the existing product. The work began with a mapping exercise on a Miro board, where I worked with the product manager component by component through the existing reporting experience to identify which parts would be affected. That shared map became the working reference for the rest of the project.

The workplace selector pill and its default state
The existing component used to pick which office a user was viewing, had to be extended to handle ownership-group structure. Users now needed to select one office, several offices, or all offices in their ownership group at once. The structural change was the multi-select capability. The design decision underneath it was the default state. We set the default to "All agencies", framing the ownership-group view as the primary lens of the report and the office-level view as a way to focus in, rather than the other way around.

Market averages with no honest baseline
The performance graph included a market average comparison. At the office level this worked: each office has a defined geographic market it can be benchmarked against. At the all-agency view, that comparison didn't have a sensible baseline. An ownership group with offices in different geographies isn't competing in one market, it's a composite of several. There was no honest single number to show.
Working through this with my PM and design manager, we agreed the right move wasn't to hide the component (which would feel like something had broken) or to fabricate a blended baseline (which would look meaningful but mislead). We kept the component visible, replaced the numerical tile value with a dash, removed the baseline line from the graph itself, and added a note to the graph key explaining that the market average wasn't available when viewing all agencies. The dash and the note signalled this was a deliberate design choice, not a system gap.

The agency rankings table
The page included a rankings table showing how agencies were performing against one another. At the all-agency view, not every entry in the ranking was the same kind of thing: some agencies are single-office operations, others are ownership groups with multiple offices. The decision we made was to rank at the ownership-group level, so the comparison stayed apples-to-apples, while making the office-level breakdown available on demand.
I designed a nested accordion pattern: each multi-office agency appears as a single row showing its group-level performance, and opening the accordion reveals the offices within that group, ranked among themselves. Single-office agencies appear as flat rows with no expansion. On mobile, where affordances need more explicit signposting, each multi-office row carries a label reading "agency group with multiple offices".


The review process
REA runs design reviews at two milestones: 60%, when the design is far enough along to assess direction but still open to structural change, and 90%, when the design is ready for final endorsement before handover.
The 60% review brought a deliberately broad audience into the room: the Head of Product, cross-functional PMs from adjacent product areas, designers on the agent/agency facing platform, engineering, and my design manager.
By the 90% milestone, the structural questions were settled and the changes coming through were refinements rather than redirections. I ran 90% async: a video walkthrough of the design file sent to the stakeholder group via Slack with the supporting materials. My PM and design manager attended as proxies for the Head of Product, carrying her earlier endorsement forward into the final sign-off.
Outcomes
The final designs were endorsed by the Head of Product at 60%, refined through 90%, and handed over to engineering as development-ready, with the engineering manager (who'd been a periodic check-in throughout) confirming the file was ready for build. The work was paused before delivery due to a shift in the organisational structure. It sits on the roadmap for a future release.
bottom of page