Eight steps stoodbetween a developerand a trustworthy answer.

Five demos moved. The decisions did not. I rebuilt the playground around the moment a developer asks whether an API deserves to enter the stack.

Client
Precisely
Role
Product design, systems
Scope
5 location API demos
Timeline
Designed Aug-Oct 2025 · live Feb 2026
Emergency Info API old portal map demo

Emergency Info API (Old Portal)

Emergency Info API old portal fixed input state

Fixed inputs, disabled fields

The old demos appeared interactive while fixed inputs and disabled fields kept evaluation shallow.
Eight-step Precisely API evaluation flow crossing documentation, specification download, external tooling, setup, request, and result interpretationEight-step Precisely API evaluation flow crossing documentation, specification download, external tooling, setup, request, and result interpretation
The old path crossed documentation, a downloaded specification, an external tool, setup, and interpretation before a developer could judge one result.

60-second brief · Decision record

From an eight-step workaround to a three-step live evaluation

Developers could see examples, but they could not test their own data or judge fit inside the portal.

Five demos looked like five opportunities. The audit revealed one fragmented evaluation problem.

EvidenceA configurable workspace made real inputs, maps, and responses inspectable in one place.

Ownership

Audit, interaction system, prototype, and front-end design.

Constraint

Three months, five different APIs, one cloud migration.

Design call

One configurable workspace for real inputs and responses.

Evidence

Path reduction, N=8 evaluation, and production launch.

Chapter 01 · Audit

The interface moved. The data did not.

Inputs were fixed. Fields were locked. One API call took eight steps across docs, an external tool, and a separate result.

  • The cloud migration created a clean moment to replace the old demo model
  • One API call took eight steps across docs, a downloaded spec, and an external tool
  • Fixed inputs, separate maps, and raw responses made product fit hard to judge
Emergency Info API old portal map demo

Emergency Info API (Old Portal)

Emergency Info API old portal fixed input state

Fixed inputs, disabled fields

The old demo looked interactive, but inputs were fixed and fields were locked.
Open the source materialThe platform migration and the cheaper path not taken
Old Precisely APIs portal showing an Explore APIs grid

Old portal (https://developer.precisely.com/apis)

Cloud Precisely Developer Portal showing the Address Autocomplete demo

Cloud portal (https://developer.cloud.precisely.com/)

Porting the old demos forward was the cheaper, unquestioned answer.
Chapter 02 · System decision

Stop rebuilding the demo. Build the system.

One tryout pattern could now bend to the needs of every API without forcing developers to relearn the experience.

  • Keep context, inputs, map, and result in one workspace
  • Let developers try their own coordinates and filters, not fixed examples
  • Show advanced controls only when an API actually needs them

Before and after

The unit of work changed.

BeforeEvery API needed a fresh demo
AfterNew APIs reuse the pattern
A new API becomes a configuration of the pattern rather than a redesign.
Precisely Developer Portal showing the shared API workspace at a readable scale
The shared API workspace: discovery, documentation, inputs, and results in one place.
Decision cost

No API could fully custom-design its own demo.

Proof

One page logic carried all five shipped demos.

Chapter 03 · Working behavior

Put real data on trial.

Developers could judge coverage first, change a real request, and witness the consequence without leaving the portal.

  • Categories and availability replaced a blank input box
  • A developer's own coordinates now drove the response, not a canned sample
  • Reverse Geocode proved the shape first: one input, one map, one legible result
Precisely Developer Portal Features page showing datasets, category tabs, and availability table
Datasets, categories, and availability appear before a request is sent.
Setup, data choices, inputs, and the response preview stay together.
Decision cost

Real inputs exposed real edge cases during evaluation.

Proof

The response now reflects the developer's own address or coordinates.

Enter the director's notesThe simplest shipped proof and the decision behind findability
One input, one map, one result: the simplest proof the pattern held.
SupersededTwo-way door

I designed the tryout, not API findability

Decision

I concentrated on evaluation inside each API and left the names and grouping that led people there unchanged.

Outcome

The tryout direction was approved. API discovery remains a named boundary of the work rather than an implied success.

Tradeoff

The design optimized the second decision before validating the first. A developer could move efficiently in the wrong direction.

Inspect the full decision recordContext, drivers, consequences, alternatives
Context and problem statement

The workspace helped once a developer reached an API page. Developers who did not already understand names such as Reverse Geocode or GeoTAX could still choose the wrong starting point.

Decision drivers
  • Make API value tangible
  • Reduce setup before a first request
  • Reuse the existing catalog structure
Positive consequences

The selected API became easier to test with real inputs and outputs.

Negative consequences

The design optimized the second decision before validating the first. A developer could move efficiently in the wrong direction.

Kill criterion

If first-click testing showed developers choosing the wrong API for a task, catalog language and grouping would take priority over workspace polish.

Chapter 04 · Scale test

One system. Five levels of complexity.

Time Zone and Wi-Fi needed a light map. GeoTAX carried denser setup. The same pattern had to survive both without forking.

  • Advanced controls appeared only when an API needed them
  • The workspace flexed from a two-field lookup to GeoTAX's denser setup
  • Maps and responses stayed legible without changing the core flow
A light map, quiet and useful, without the weight of a full workflow.
Denser setup and results that need more explaining.
Decision cost

Supporting GeoTAX without burdening simpler demos required progressive disclosure.

Proof

GeoTAX fit the same workspace without a separate interaction model.

Flow redesign

Trying an API became a three-step product flow.

Choose an API, enter real data, and judge the result without leaving the portal.

Before · 8 steps
  1. Find docs
  2. Download spec
  3. Open tool
  4. Import spec
  5. Configure auth
  6. Set inputs
  7. Send
  8. Interpret
After · 3 steps
  1. Choose API
  2. Enter real input
  3. Read result
The designed path removed five setup and handoff steps.

The workaround disappeared. The pattern survived.

My interaction result sits beside wider program validation and delivery evidence.

8 to 3

Designed path steps

Removed spec download, external-tool import, and authentication setup.

8 people

Evaluation sample

Developers, product managers, and sales engineers tested the wider Tryout program.

Live

Production capability

API Tryout replaced the earlier proof of concept in February 2026.

7

Sample APIs demonstrated

A later delivery team extended the wider portal pattern.

Evidence noteEvidence combines my five-demo design scope with wider program results. Read the full retrospective

View the live Developer Portal
SupersededTwo-way door

I counted APIs shipped, not decision speed

Decision

I used APIs covered as the primary proof that the pattern worked.

Outcome

The pattern scaled. The case study no longer presents coverage counts as evidence of developer impact.

Tradeoff

The metric proved what I built, not whether one developer reached a confident decision faster.

Inspect the full decision recordContext, drivers, consequences, alternatives
Context and problem statement

The new tryout pattern covered five APIs and mapped three more, but the user's job was deciding whether an API fit, not watching the team scale a component.

Decision drivers
  • Prove the pattern generalized
  • Create momentum for adoption
  • Show delivery scope
Positive consequences

Coverage showed the system could handle different inputs and response types.

Negative consequences

The metric proved what I built, not whether one developer reached a confident decision faster.

Kill criterion

If a first-time developer could not reach and explain a trustworthy result faster than on the old portal, coverage would not count as success.

Scope

I led the audit, shared tryout pattern, prototype, and front-end design across five location demos.

Engineering led production delivery; product led the API roadmap. I also contributed reusable components to the Precisely Design System.

The portal went on to win two 2026 Global AI Awards, in Agentic AI and Conversational AI. The award recognizes Precisely's product; several designers, including me, contributed. See the winners list (opens in new tab).

Work nobody asked for

The hardest call wasn't a screen. It was proving the idea on real data before anyone asked me to.

  1. I prototyped against live APIs instead of drawing them

    Why it mattered

    A static flow could not expose the states that make or break the experience, so I built a working prototype in Figma Make and GitHub Copilot, wired to live APIs. The direction was approved on real responses, not mockups.

    Evidence boundary

    This moved the decision from presentation preference to working product behavior before engineering delivery.

In hindsight

What I would do differently

The platform is live, validated, and reusable. These are the two measurement layers I would add next.

  1. The next question is sustained adoption

    When the Metric Becomes the Target
    What I shipped

    The program completed usability validation with eight product managers, developers, and sales engineers, then moved API Tryout into production.

    What I would do now

    Add a durable activation signal: the share of developers who reach a trusted result and return to evaluate another API.

  2. The strongest next metric is time to a trusted result

    The First Five Minutes
    What I shipped

    The designed path reduced validation from eight setup steps to three in-portal steps and kept inputs, request, map, and response in one workspace.

    What I would do now

    Instrument time to a first successful request. Watch new developers reach it, then cut or reorder whatever step doesn't help them get there.

They came to see what the API could do.They left knowing what their data would do.

Five shipped demos. One shared system. Three steps from question to evidence.

Enter the live portal