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 in 2023.

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, meanwhile, 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.

Underneath the usability problems was a subtler one. The two groups thought about the same underlying data in completely 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. Same data, two mental models, 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. I want to be calibrated about the parts that 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, not from me alone.

The decisions I'd point to as mine were the central one (shared data, divergent presentation rather than 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, to understand two specific things: why planters were walking away from required tasks, and what impact metrics funders actually needed rather than what we assumed they needed.

The pivotal call came out of that research. The obvious response to "two groups with conflicting needs" is to build two separate solutions. I didn't. The data underneath was the same data; the problem was presentation, not architecture. So I designed connected dashboards that drew from one shared source but surfaced it differently for each group, planters seeing their world as milestones and compliance, funders seeing 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, rather than needing a rebuild later.

Collaboration & method

The hardest non-design part was stakeholder management. Different internal teams had genuinely 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 hold the line between immediate usability fixes the teams wanted now and the longer-term structural decisions that would stop us repainting the same problem in six months.

On delivery, I worked closely with a Senior Software Developer and chose to ship incrementally rather than in one big release. I built the prototypes, tested the more complex metrics specifically for whether people could actually digest them, then 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 turned out to matter more than any single screen design.

Constraints & tradeoffs

• One shared data source, two presentations, not two products. I resolved the conflicting-needs problem in information architecture rather than by forking the product. Trade-off: more careful design to keep the two views coherent against shared data, accepted because two separate products would have doubled the maintenance and split the source of truth.
• Design for future automation now. I had to design around planting-status automation that didn't exist yet while still solving today's usability problems. Trade-off: extra structural thinking up front, accepted so the solution wouldn't break when automated workflows arrived.
• Incremental delivery over big-bang. Shipped in stages rather than all at once. Trade-off: slower to a single dramatic "done" moment, accepted because it contained regression risk and let 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, available 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 finally able to see their impact clearly, and planters found the workflow much more intuitive than the thing they'd been abandoning. The result I'm most satisfied with is the structural one: it showed that two groups with apparently conflicting requirements didn't need two separate products. Get the information architecture right and the same data can serve both, which is cheaper to build and cheaper to maintain than the obvious fork.

Reflection

The lesson I carried out of this is that when two user groups share data but clash, the instinct to split them into separate products is usually the expensive wrong answer. The real work is in the information architecture and, specifically, in the language. The groups weren't fighting over data, they were framing it 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, because that language gap was the core insight and I was working more from a felt sense of it than from documented examples. Naming it precisely would have made the design decisions even sharper and easier to defend to stakeholders.

What this proves

I can take a product serving two groups who want opposite things and resolve it in information architecture instead of brute-forcing two builds. I research to find the real divergence rather than the surface complaint, I hold competing stakeholder priorities together long enough to ship, and I de-risk complex delivery by going incremental. And the outcomes moved on both sides of the platform at once, not one at the other's expense.