Seamless workflow between API Design and Test

Goal

Improve collaboration between Engineers and QAs by introducing synchronised API status updates between the API Design and API Test solutions — so each team always knows when an API is ready to test.

Challenge

In many API development workflows there's a disconnect between the design and testing phases, leading to delays, miscommunication, and inefficiencies. Developers and architects often lack a structured way to signal when an API is ready for testing — so QA teams either test incomplete APIs or wait unnecessarily for confirmation. This lack of visibility slows development cycles, increases the risk of defects, and creates bottlenecks in the release process.

My role

• Collaborated with fellow product designers on cross-product workflow design
• Worked with the PM to translate functional feature requirements into defined user workflow steps
• Uncovered and designed additional workflow corner cases, drawing on existing knowledge of user needs and expectations

The solution

A cross-tool workflow: API developers label an API as “ready for testing,” and that status syncs automatically into the API Test product, so QA can prepare and run tests against the same API.

As we worked through the PRD, a sharper insight reshaped the concept: users see more value in granular, endpoint-level status labelling than in a single whole-API status — because they tend to test specific endpoints, not the entire API at once. We built the workflow around that more useful model.

What it took — the tradeoffs

Because the workflow spans two tools, I partnered with the designer responsible for the API Design side. In different time zones, we worked async — each owning the piece of the workflow inside our own tool, syncing via Figma comments, then assembling both halves into a single connected prototype.

We then tested two versions with users: the original PRD workflow and our insight-driven one. Validation confirmed the granular approach — but it also exposed that the underlying technical PoC was more complex than its value justified, forcing a hard call about whether to keep building it.

Outcome

• Research redirected the build before it shipped. Validation surfaced that the original technical PoC would underdeliver — prompting Product and Engineering to deliberately pivot the approach (toward a more optimised, agentic-AI implementation) rather than build the wrong thing.
• Reframed the value proposition from whole-API status sync to the granular, endpoint-level model users actually wanted.
• Validated direction with real users before committing engineering effort — saving the team time and resources.

What I'd do differently

I'd surface the endpoint-level insight earlier. We reached it through the PRD and validated it well, but getting there sooner — before so much technical PoC effort — would have spared work the team ultimately set aside. The broader lesson: think beyond the PRD and raise refinements as early as possible.