# Cape

> A clearer way to work with AI.

- Role: Designer & Lead Frontend Engineer
- Focus: Product design & frontend engineering
- Product: AI-powered workspace
- Interfaces: Assistant, dashboards & review tools

At Cape, I was both the designer and the lead frontend engineer. I designed the interfaces and led their frontend development, bringing conversation, data-heavy dashboards, and document review into one coherent workspace.

Cover image — Cape Assistant showing the same conversation in a full desktop workspace and a compact side panel, with navigation, message history, and a composer.

## The shared thread

My role connected product design with frontend delivery. Across a chat thread, a customer dashboard, and a document review, the design problem was the same — helping people understand where they are, what they’re looking at, and what they can do next.

## 01 / Assistant — One conversation. More than one way in.

The assistant screenshot shows both a full-page view and a narrow companion panel. History and navigation support the larger workspace; the compact view puts the exchange and the composer first. Both retain the model label, message hierarchy, and a recognizable place to respond.

- **A place in the product.** The main rail keeps Assistant alongside Apps and Workflows, while the second column provides conversation history.
- **A readable exchange.** Sender and model labels distinguish the prompt from the response without competing with the conversation itself.
- **A smaller footprint.** The companion panel preserves the core interaction in a narrower space, with its composer anchored below the exchange.

## 02 / Structured work — Make the overview useful. Keep the detail close.

The dashboard brings customer context, ownership, risk categories, and review information into one view. Its hierarchy makes the summary easy to locate, while grouped sections and expandable rows leave room for supporting detail.

Screenshot — Cape’s customer dashboard with an overview, risk summary, ownership information, expandable news rows, and review sections.

- **Summary before detail.** The customer overview and headline risk indicator establish the subject before the denser review sections begin.
- **Grouped, not flattened.** Ownership, news, and individual risk categories retain their own headings and visual boundaries.
- **Depth when it is needed.** Expandable news rows show how a compact list can reveal the detail behind a particular item.

## 03 / Document review — Keep the source in sight.

The review workspace places a document beside a list of control objectives. A reviewer can keep the source material in view while moving through the structured list, with distinct visual indicators for different review states.

Screenshot — Cape’s control-objectives workspace with a document viewer on the left and a list of objectives with check, cross, and neutral status indicators on the right.

- **Context on both sides.** The split view gives the source document and the review list their own space within one task.
- **More than a color.** Checkmarks, crosses, and neutral marks distinguish the visible states alongside their color treatments.
- **Tools near the work.** Page navigation and zoom sit with the document; filters and item menus sit with the review list.

## Principles

- **Orientation** Help people understand where they are, whether they are navigating a conversation, an app, or a document.
- **Continuity** Preserve familiar interaction patterns as the available space and the shape of the task change.
- **Reviewability** Keep the information behind a summary or a decision within reach, rather than making the output the end of the experience.

## What I carry forward

These screens tell a story about context as much as capability. An assistant needs a readable conversation. A dashboard needs hierarchy. A review tool needs room for the source. The frontend is where those needs become a product someone can actually work with.
## Notes

As the designer and frontend lead, I worked across both the visual experience and its implementation. That meant carrying the intent of the interface into frontend development, rather than treating the design and the code as separate concerns.

The challenge across these screens was not simply fitting more information onto the page. It was choosing what deserved attention, what should remain available, and how to preserve context as the task changed.

---

Source: https://devinschulz.com/work/cape/