Looking beyond navigation to rethink the developer integration journey

01 — The decision we needed to make

The team was deciding between two initial information architecture directions for the Developer Portal, while foundational pages were already moving into development. We needed to understand which structure better supported self-service integration before committing further design and engineering effort.

But choosing a “winning” tree alone wouldn’t tell us why users navigated the way they did. I designed the research to evaluate how well each direction supported navigation while also identifying where behavior diverged from the team’s assumptions about the integration process.

02 — The headline metric hid the real problem

I started with behavior, not preference

I used comparative tree testing to evaluate how people navigated the two proposed structures without visual design influencing their choices. Across 69 participants, I looked beyond task success to first clicks, direct vs. indirect success, and backtracking.

Tree A vs. Tree B

But “success” was masking uncertainty

On one key task, the headline result initially looked reasonable:

The headline result suggested most participants could eventually find the content. Their paths told a different story: finding it eventually wasn’t the same as knowing where to go.

I followed the signal into targeted interviews

Rather than treating the tree test as the conclusion, I used these behavioral patterns to shape the qualitative follow-up. I selected 7 participants directly from the tree-test pool, sampling across navigation behavior, role, and integration experience. I intentionally included both participants who showed friction and successful counterexamples to understand why the same structure worked for some users but broke expectations for others.

Participant sampling matrix

Because I already knew how each participant had navigated, I could replay specific behaviors during the interview and probe the reasoning behind them.

Two anonymized replay examples

Connecting observed behavior with participants’ reasoning revealed that the problem went beyond where content lived. People entered the portal at different stages of the integration journey, and what they expected to find depended on the job they were trying to accomplish.

03 — Following the signal changed the product question

What looked like inconsistent navigation reflected different jobs in the integration journey

Tree-test behavior showed that participants did not consistently begin in the same place. While some started with Getting Started, others went directly toward implementation or the Implementation Planner.

“Getting started” meant different things for different jobs

The interviews helped explain why. What felt like a natural starting point depended on what someone was trying to accomplish and where they were in the integration journey.

For someone evaluating the SDK, getting started meant understanding whether the product was feasible for their organization: what it would require, how much effort and resourcing it would take, and which technical decisions needed to be made upfront.

For someone implementing it, the questions became more granular: Which implementation approach should I use? What are the prerequisites? What decisions do I need to make before I begin? How many steps are involved, and what will each require?

Because these SDK integrations could require significant technical and organizational investment, evaluation was not simply a precursor to the developer experience. It was part of the experience the portal needed to support.

Evaluator / Implementer JTBD model

The IA needed to support different jobs and entry points

There wasn’t one universal way users expected the portal to be organized. Their expectations changed depending on the job they were trying to accomplish and where they entered the integration journey.

The IA therefore needed to support progression across different jobs and entry points, rather than simply organizing documentation into a logical taxonomy.

The question changed

04 — Research changed where the team invested

The answer wasn’t simply A or B

The study started with two competing IA directions, but the evidence didn’t support simply choosing a winner. Each structure worked for parts of the journey, while neither fully supported the different jobs, entry points, and upfront decisions we had uncovered.

The research informed 7 product and design decisions, including:

Research-to-decision map

These decisions became inputs into the next round of design. The team began developing a third IA direction, retaining what worked from both original structures while addressing the gaps surfaced through research.

We kept engineering moving without locking in the wrong experience

Engineering was already preparing to build foundational pages when the research surfaced changes to the broader journey. Pausing everything would have unnecessarily slowed development; continuing everything risked building pages we already knew were likely to change.

In working sessions with Design, Product, and Engineering leads, we separated the roadmap into work that was modular enough to proceed and pages whose structure depended on unresolved experience decisions. Engineering continued on the former while we deliberately delayed the latter.

~6 months

This sequencing helped avoid ~6 months of estimated premature engineering effort across 3 engineers, while keeping development moving on work unlikely to be invalidated.

Some findings became decisions. Others became new questions.

I used an activation workshop to move the research into action. Areas with sufficient evidence became product and design decisions; unresolved questions became targeted follow-up rather than assumptions the team would build around.

The work moved 3 concepts into exploration and initiated 2 follow-up research streams where we needed more evidence before committing further investment.

What started as an IA comparison ultimately helped the team decide not just how to organize the portal, but what was ready to build, what needed to wait, and what we still needed to learn.

Reflection

The harder judgment in this project came after the research surfaced a bigger problem. With engineering already moving, the goal wasn’t to eliminate uncertainty before building. It was to distinguish which uncertainties could materially change the experience from which ones we could safely design around.

That distinction let us keep modular work moving while delaying decisions that would have been expensive to unwind later. It’s a balance I’ve become increasingly deliberate about:

using research to reduce the uncertainty that matters, without making certainty a prerequisite for progress.