Evan Dunkel

Relay is a concept for small creative teams reviewing work asynchronously. I made a fixed version, a clear request, and an explicit decision the unit of review. The intended outcome is a handoff where the author and reviewer can both identify which work was approved.

Role: Independent product designer. Team: Solo concept. Timeline: October 2026. Platform: Web. Status: Concept; not shipped.

I owned the problem framing, the comparison of directions, and the interaction specification. Collaboration and measurement plans are proposed; there is no adoption data or shipped result. The photos in this case study are placeholders.

Small creative teams can share a draft through a file and discuss it in chat. In this scenario, a reviewer approves yesterday’s image while the designer is already revising today’s. The cost is uncertainty about which work can move forward, followed by another round of clarification.

The starting brief was to put project feedback in one dashboard. I reframed it around making every review decision refer to a specific version. A central inbox could gather the messages while still mixing comments on old work with decisions on new work.

This is a design hypothesis, not a finding from team interviews. I would examine real review threads and ask authors and reviewers to identify the approved artifact independently. That would show whether version ambiguity is the main problem or whether unclear decision authority matters more.

Constraints: Existing file storage; asynchronous review; no replacement for the design editor. Principles: Specific requests over open-ended threads; visible decisions over silent progress.

I compared three directions against the need to preserve context when an author and reviewer are working at different times.

Project chat: Familiar and easy to start. It accommodates discussion, but leaves the version, the question, and the approval buried among other messages.

Live review room: The boldest direction, with a shared canvas for working through feedback together. It could support richer collaboration, but requires people to meet at the same time and expands the product toward an editor.

Versioned request: My chosen direction. It packages one draft with the question the reviewer needs to answer, then keeps the decision with that artifact. The author does more preparation in exchange for a review that remains understandable later.

The live room could become useful for a different task. I left it out of this concept because synchronous collaboration would not resolve the asynchronous handoff on its own.

A request would point to a fixed version even when the working file changes. I chose a new request for a revised draft over silently updating the preview. Earlier comments should remain intelligible when someone returns to the conversation.

This creates an extra step for the author. The benefit is that a reviewer’s decision cannot quietly change its meaning because the underlying artifact was replaced.

The version reference is therefore a product rule as well as an interface label. Before implementation, I would work with engineering to establish how snapshots are stored, how replacement requests link back, and what remains readable when a source file is unavailable.

Comments can explore an idea; “Approve” and “Request changes” explicitly close the review. I placed those actions beside the version title instead of at the end of a long thread. The decision should name the same artifact the reviewer has been evaluating.

Approval would belong to that version and would not carry forward automatically. A replacement draft starts a new review, even if the author believes the changes are minor. That favors a clear history over a faster but ambiguous approval flow.

Who can approve remains an open product question. I would align with PM on that authority before adding multiple reviewers, so the interface does not make a team’s decision rules appear simpler than they are.

Ambient AI