# Cape > A clearer way to work with AI. - Role: Designer & Lead Frontend Engineer - Period: 2020-2025 - 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. The job was to bring a chat assistant, data-heavy dashboards and document review into one workspace that felt like a single product. ![Cape Assistant showing the same conversation in a full desktop workspace and a compact side panel, with navigation, message history, and a composer.](https://devinschulz.com/images/cape/slide-1_hu_49803d41cfb977db.webp) The assistant: a full workspace and a compact panel, with a familiar conversation structure in both. I worked on both the design and the frontend. A chat thread, a customer dashboard and a document review look very different, but they had the same design problem: people need to know where they are, what they’re looking at and what they can do next. ## 01 / Assistant: The same conversation, in two sizes. The screenshot shows the assistant as a full page and as a narrow side panel. The full page has room for history and navigation. The panel drops those and leads with the conversation and the message box. Both keep the model label, the same message layout and the same place to type a reply. - **Part of the product.** Assistant sits in the main rail next to Apps and Workflows, and a second column holds past conversations. - **A readable exchange.** Sender and model labels separate the prompt from the response without getting in the way of the text. - **A narrower version.** The side panel keeps the conversation in a much narrower space, with the message box fixed below it. ## 02 / Structured work: A useful overview, with the detail close by. The dashboard puts customer context, ownership, risk categories and review information on one page. The summary sits at the top where it’s easy to find, and grouped sections with expandable rows hold the detail underneath. ![Cape’s customer dashboard with an overview, risk summary, ownership information, expandable news rows, and review sections.](https://devinschulz.com/images/cape/slide-2_hu_3f67b35c01d8aa4e.webp) The customer review dashboard, with the summary at the top and the detail below it. - **Summary before detail.** The customer overview and the headline risk indicator come first, before the denser review sections. - **Sections keep their shape.** Ownership, news, and individual risk categories retain their own headings and visual boundaries. - **Rows that open.** News items stay compact until you expand one to read the detail. ## 03 / Document review: Keep the source in sight. The review workspace puts a document next to a list of control objectives, so a reviewer can keep the source open while working down the list. Each review state has its own marker. ![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.](https://devinschulz.com/images/cape/slide-3_hu_bded2814388c5d9f.webp) The source document and the review objectives, side by side. - **Side by side.** The document and the review list each get their own pane in the same view. - **Shape as well as color.** Checkmarks, crosses and neutral marks show each state, so color is never the only signal. - **Tools near the work.** Page navigation and zoom sit with the document; filters and item menus sit with the review list. ## 04 / Administration: The settings around the work. People open team management, integrations, API keys and usage reports less often than the assistant or the dashboard, but the same rules apply: say what state something is in, say what an action will do before it happens, and never show a number without the date range it covers. ![Six Cape administration screens, including an invite dialog, a Settings members table listing names, roles, and last-active dates, an integrations list with GitHub and JIRA connected and Gmail and Notion offering a connect action, a New API Key form with naming and expiry fields, a redaction-metrics view with entity counts and a timeline chart, and a usage analytics view with token and API-call charts.](https://devinschulz.com/images/cape/slide-4_hu_4d1bf5b96bfc548c.webp) Admin screens for the team, integrations, API keys and usage. - **Status first.** A connected integration shows its status. Only the integrations that aren’t set up yet offer a way to connect. - **Say what will happen.** While you fill in the API key form, it shows the name of the key it will create and the date it expires. - **Numbers with dates.** Redaction totals and usage figures always show the date range they cover. ## Designing it and building it. As the designer and the frontend lead, I worked on how the interface looked and how it was built. Doing both meant the reasons behind a design carried through into the code. The hard part was deciding what deserved attention, what could sit a click away, and how to keep people oriented as the task changed. The full assistant and the side panel are a good example. The full workspace has room for conversation history and navigation. In the panel, those would take space away from the conversation itself. Keeping the message layout and composer familiar gave the smaller view continuity without trying to squeeze in the entire workspace. Document review involved a different trade-off. A compact summary is useful until someone needs to check the source. Keeping the document beside the objectives meant the evidence stayed available while a reviewer worked through the list. Page navigation and zoom belonged with the document; filters and review actions belonged with the objectives. The administration screens needed the same care around state. A connected integration and one that still needs setup should offer different actions. An API key form should make its expiry clear before the key is created. These are small decisions individually, but they determine whether a complicated product feels predictable. ## Principles - **Orientation** Help people see where they are, whether that’s in a conversation, an app or a document. - **Continuity** Keep familiar patterns in place when the screen gets smaller or the task changes. - **Reviewability** Keep the information behind a summary or a decision within reach, so people can check it. ## What the screens have in common. Looking back, these screens are mostly about context. An assistant needs a readable conversation, a dashboard needs a clear hierarchy, and a review tool needs room for the source document. The frontend is where that turns into something people can use. Product screenshots from Cape. This case study covers my part: designing the interfaces and leading the frontend work. [Next case study: Warranties](https://devinschulz.com/work/warranties/index.md) --- Source: https://devinschulz.com/work/cape/