One dashboard. Two ways to understand an order.

01Overview

Any app could become a place to shop.

Rye’s core innovation was an API that let developers build shopping experiences inside their own apps. They could sell products from across the internet directly, making commerce part of the experience they were already building.

That opened up new possibilities for where and how people shop. Our goal was to help developers turn those possibilities into products. The dashboard was one part of making that infrastructure easier to understand and use.

02The challenge

The dashboard had two jobs, but one starting point.

Nontechnical teammates needed to manage orders. Developers needed to understand the integration, including API responses and timing. At some customers, one person did both jobs.

The main dashboard needed to stay focused on order management and control. Developers could already access much of the underlying information through the API, so the dashboard did not need to display every field by default.

03Two audiences

The same data had to answer different questions.

Operations and development are two tasks someone might switch between. Separating them into rigid user types would make that switch harder for customers where the same person did both.

The design direction is a shared order view with technical depth available on demand. Visibility of detail and permission to change an order are separate decisions.

04Information design

Deciding what to show, explain, and keep within reach.

I worked through the gap between what the API returned and what the dashboard should display. The decisions were about selection, labels, grouping, and depth: which information answered the immediate question, and which became useful only when someone needed to investigate?

An order-first view would prioritize the item, buyer, total, status, and anything needing attention. The order detail would add a timeline and available controls. Raw responses, IDs, and request diagnostics could sit one level deeper, attached to the same order.

Translate the state, not just the field name.

In the current API, a completed checkout means the merchant confirmed the purchase. I would label that “Order placed” and show shipping separately. A successful API request also does not mean the purchase itself succeeded.

Reference: Checkout lifecycle and response schema.

Separate three kinds of time.

A request can return quickly while Rye is still retrieving an offer or placing an order. The technical view should distinguish API request duration, offer retrieval time, and order placement time. These require separate instrumentation; they are not interchangeable response fields.

05Dashboard & API

Showing information and giving control are different decisions.

Deciding what a person could see also raised a second question: what should they be able to change through the dashboard? A visual control can make a task accessible without code, but it also introduces a decision that needs to be understood.

Controls also need to respect the order’s state and the merchant’s capabilities. The current API accepts cancellation requests, but a request can be denied. I would show “Cancellation requested” while it is pending and explain why an action is unavailable.

Tracking is available for some supported marketplace integrations, while agentic orders may receive updates directly from the merchant. Missing tracking data should not look like a delayed shipment.

Current API references: cancellation and merchant limitations. Availability depends on the integration.

06Reflection

Make the infrastructure easier to build with.

Rye’s API opened up a new way to bring shopping into apps. The dashboard supported that ambition by helping people understand the system they were building on. Its value depended on the decisions between the raw response and the screen.

1. 01

   Start with the user’s question.

   The API’s structure does not have to be the interface’s structure.

2. 02

   Make depth a choice.

   A clear overview and useful technical detail can support each other.

3. 03

   Let the task set the boundary.

   A dashboard control earns its place when it makes the work easier to understand and complete.

What I’d validate

Can an operator identify the next action without opening technical details? Can a developer trace the same order back to the response and timing? Can a person doing both jobs move between those views without losing context?