One platform, two users who wanted opposite things

Context

Trees That Count is a New Zealand conservation platform that connects people funding native tree planting with the planters doing the work. I was an in-house Product Designer there from January 2024 to June 2025.

The platform had a single dashboard trying to serve two groups whose goals pulled in different directions. Planters needed structured tools to manage the lifecycle of a planting project and stay compliant. Funders needed visibility: a way to see and report on the impact of what they'd paid for. One screen was trying to be both things and doing neither well.

The problem

The two sides were failing in different ways. Planters were abandoning required lifecycle-management tasks at a 73% completion rate, which meant a quarter of necessary work wasn't getting done in the tool. Funders had no self-service way to get at their impact data for ESG and stakeholder reporting. So they kept asking the team for manual reports, which ate team capacity every time.

There was also a subtler problem underneath the usability ones. The two groups thought about the same underlying data in different ways. Planters framed everything in terms of project milestones and compliance steps, the operational reality of getting trees in the ground. Funders framed the same activity as impact they could communicate, the metrics they needed to tell a credible story to their own stakeholders. It was the same data with two mental models and two vocabularies. A single dashboard built around one of those framings would always alienate the other group.

My role

I led the redesign end-to-end as the in-house designer: research, strategy, design, and delivery. Some parts were shared. The research participants and the operational knowledge came from real planters and funders. Delivery ran in close collaboration with a Senior Software Developer, who I worked through handoff, QA, and launch with. The competing priorities I had to reconcile came from multiple internal teams.

The decisions I'd point to as mine were the central one (shared data with divergent presentation, instead of two separate products) and the delivery approach (incremental release over a big-bang launch).

Approach

I ran clickthrough prototype testing and talk-aloud sessions with 12 participants, a mix of planters and funders. I wanted to understand two things: why planters were walking away from required tasks, and what impact metrics funders needed (as opposed to what we assumed they needed).

The main decision came out of that research. The obvious response to two groups with conflicting needs is to build two separate solutions. I didn't do that. The data underneath was the same data, and the problem was in the presentation. So I designed connected dashboards that drew from one shared source but surfaced it differently for each group. Planters saw their world as milestones and compliance. Funders saw theirs as reportable impact. That kept one source of truth while letting each group work in its own language.

I also designed the planter workflow with future gated stages in mind, so the structure could absorb more complex compliance requirements as the platform grew, without needing a rebuild later.

Collaboration & method

The hardest non-design part was stakeholder management. Different internal teams had different views on what the dashboard should prioritise, and a lot of the work was realigning those competing priorities enough to move. I had to balance the immediate usability fixes the teams wanted now against the longer-term structural decisions that would stop us fixing the same problem again in six months.

On delivery, I worked closely with a Senior Software Developer and chose to ship incrementally instead of in one big release. I built the prototypes and tested the more complex metrics specifically for whether people could digest them. Then I delivered in stages to keep regression testing contained and de-risk each step. For a product with this many moving parts and this many stakeholders, incremental delivery mattered more than any single screen design.

Constraints & tradeoffs

• I resolved the conflicting-needs problem in the information architecture instead of forking the product: one shared data source with two presentations. It took more careful design to keep the two views coherent against shared data. Two separate products would have doubled the maintenance and split the source of truth, so that was the better cost to carry.
• I had to design around planting-status automation that didn't exist yet, while still solving the usability problems in front of us. That meant extra structural thinking up front, so the solution wouldn't break when the automated workflows arrived.
• We shipped in stages instead of all at once. It was slower to reach a single "done" moment, but it contained regression risk and let the competing teams see progress without waiting for everything.

What shipped

Two connected dashboards over a shared data layer. The planter view organised lifecycle management around milestones and compliance, structured to take on gated stages as requirements grew. The funder view translated the same underlying activity into the impact metrics funders needed for ESG and stakeholder reporting. It was self-serve, so they no longer had to request manual reports.

Outcome

The numbers moved on both sides:

• Planter task completion went from 73% to 96%.
• Funder engagement increased 115%, with average session duration growing from about 30 seconds to 1 minute 30 seconds.
• The self-serve funder view removed the recurring manual impact-report requests, giving the team back that capacity.

Beyond the metrics, post-launch feedback was that funders were able to see their impact clearly, and planters found the workflow much more intuitive than the one they'd been abandoning. The result I'm most satisfied with is the structural one. Two groups with apparently conflicting requirements didn't need two separate products. With the right information architecture the same data served both, and that was cheaper to build and maintain than the obvious fork.

Reflection

What I took from this is that when two user groups share data but clash, splitting them into separate products is usually the wrong call, and an expensive one. The work is in the information architecture and, specifically, in the language. The groups were framing the same data differently, and design's job was to honour both framings over one source of truth.

If I were doing it again I'd capture the vocabulary differences between the groups much more rigorously and early, as concrete artefacts. That language gap was the core insight, and I was working more from a felt sense of it than from documented examples. Naming it clearly would have made the design decisions sharper and easier to defend to stakeholders.