Product Designer · B2B SaaS · Developer Tools
A clearer workspace for working with APIs.
Designing Sparrow, a developer-focused API platform built around hubs, workspaces and a marketplace for reusable API resources.
- Role
- Product Designer
- Company
- Sparrow, via Techdome
- Year
- 2025
- Built with
- Figma
- Claude
- ChatGPT
The problem
API tools are powerful.
Their complexity isn’t.
- Requests leads to Too much to manage
- Collections leads to Too much to manage
- Environments leads to Too much to manage
- Variables leads to Too much to manage
- Workspaces leads to Too much to manage
- Hubs leads to Too much to manage
- Test flows leads to Too much to manage
- Teams leads to Too much to manage
Developers don’t just send requests. They manage environments, collections, reusable configurations and shared workflows — and every one of those is a place work can get lost.
The design challenge
How do you organise complexity without hiding power?
- More features leads to More menus
- More menus leads to More hierarchy
- More hierarchy leads to More to hold in mind
- Clear structure leads to Focused workspace
- Focused workspace leads to Reusable resources
- Reusable resources leads to Faster workflow
The goal was never to remove functionality. It was to make the functionality easier to navigate.
The product model
One place for the ecosystem, one for the work.
Sparrow separates the broader API ecosystem — hubs, members, public workspaces — from the individual workspace where a developer actually does the work.
- Hub leads to Workspace
- Workspace leads to Collection
- Collection leads to Request
- Request leads to Test
Workspaces, members and settings for an organisation.
The focused environment where API work happens.
The workspace
The one screen that has to stay calm.
Workspace
The primary environment for API testing.
Organisation
Related API work stays grouped together.
Reusability
Start from an existing resource, not a blank request.
Collaboration
Shared API work is discoverable and continuable.
Hubs and workspaces
A predictable place for every kind of API work.
The hierarchy gives high-level API resources and day-to-day testing work each a predictable home, so neither has to live inside the other.
- Payments hub leads to Payment Gateway
- Payment Gateway leads to Create Payment
- Payment Gateway leads to Refund Payment
- Payment Gateway leads to Get Transaction
Access lives at the hub, not per workspace.
Created inside a hub, so it starts with a place to belong.
Discoverability
Don’t rebuild what already exists.
The marketplace is a discovery layer over public workspaces — a payment gateway collection someone has already built and documented, copied into your own workspace rather than rebuilt in it.
- Discover leads to Select
- Select leads to Add to workspace
- Add to workspace leads to Use
Reuse
From blank workspace to ready-to-test.
A workspace made public becomes a resource other teams can start from.
Test against a collection before a live service exists.
Reuse works in both directions: pull a public workspace in, or publish your own for the next team. It cuts the repetitive setup that otherwise precedes every first request.
Fast access
Keep active work one click away.
Recent APIs and recent workspaces sit permanently in the sidebar, and the marketplace keeps its own list of recently visited workspaces. Returning to live work does not mean walking the hierarchy again.
Key design decisions
Structure before features
- Problem
- API tooling turns into a pile of disconnected features fast.
- Decision
- Establish one hierarchy — hubs, then workspaces — and hang everything off it.
- Result
- Developers get a predictable answer to where a piece of API work belongs.
Reuse instead of rebuild
- Problem
- Developers keep solving the same setup problem in different workspaces.
- Decision
- Make reusable resources first-class: public workspaces, a marketplace to find them, mock collections to work before a service exists.
- Result
- Common API work starts from an existing foundation instead of an empty request.
Fast access to active work
- Problem
- The work you are actually doing gets buried by the structure that organises it.
- Decision
- Keep recent APIs and recent workspaces permanently in reach, outside the tree.
- Result
- Getting back into live work costs one click, not a navigation.
The system
One system, many dense surfaces.
Request panels, collection trees, workspace cards, tables, tabs, status pills and modals are the same components everywhere, which is what let new workflows land without the product drifting.
- Tokens leads to Components
- Components leads to API patterns
- API patterns leads to Workspace
- API patterns leads to Hub
- API patterns leads to Marketplace
- API patterns leads to Admin
Complexity to clarity
Complex software doesn’t need less information. It needs better hierarchy.
Navigation
Where things live. Left rail and tree, always in the same place.
Context
Which hub, workspace and environment you are in.
Primary task
The request. Centre, widest, unobstructed.
Supporting
Params, headers, scripts, assertions — tabbed, not stacked.
Status
Response, method and state, read without leaving the task.
The product
Delivered
- Workspace architecture
- Hub-based organisation
- Marketplace for reusable API resources
- Public workspace publishing
- Recent APIs and workspaces
- Test flows and mock collections
- Scalable product patterns
- Consistent design system
Sparrow turned a set of powerful API capabilities into a workspace model you can hold in your head.
Reflection
The hard part wasn’t simplifying the product. It was simplifying how people understood it.
Sparrow reinforced the lesson I keep relearning in B2B: complexity is usually not optional. What design decides is whether it feels structured and predictable, or whether it feels like a pile.
Next case study
11 steps to 4, conversion doubled