A Second Voice in the Room

Recently I was handed an enterprise product, a desktop app where portfolio managers oversee thousands of buildings. The existing software in this space is mostly dinosaurs, which rules out the usual “look at the competition” move. What does a property owner running 5,000 buildings actually do at 9am on a Tuesday? A hundred-page product overview later, one thing had landed: fleet management for buildings looks less like a BMS and more like a developer tool. Developer tools I know, so that was the relief.

How I usually collect inspiration

I use Dribbble for taste, collect screenshots from products I admire, and pin everything to Pinterest. For this project I wanted to try AI, both to automate the capture and to see if it could add insights I would miss on my own.

This project was a crossbreed: dev-tool dashboards (Vercel, Stripe, Linear) for visual calm and hierarchy, fleet observability (Datadog, Samsara) for “thousands of things, which are sick,” and service catalogs (Stripe Marketplace) for third-party services per building. The question was how to combine all three inside a building management product, where I have almost zero experience.

Principles as a compass

Before clicking around I wrote down the product principles. Two were load-bearing.

The first: this is a service platform, not a dashboard that monitors individual sensors. That rules out BMS reference UIs and points at developer-tool dashboards (Vercel, Stripe). The second: portfolio scale. The product is designed for thousands of buildings, not four or five, and that has to be the mindset from day one. A UI that works for five buildings looks nothing like a UI that works for five thousand. That single shift changed almost every screen.

Each principle implies a category of reference. Service platform → Stripe, Vercel. Portfolio scale → Datadog, Samsara.

I handed Claude the principles. It suggested which platforms solve the closest problem for each. I was not browsing randomly and I was not copying the obvious peer. I was studying specific platforms for specific principles.

The workflow, in one skill

I wrote a screenshot skill that turns a study session into a structured artifact. Three modes:

• Solo: I drive; Claude captures and logs my note verbatim.
• Copilot: I drive; Claude captures, logs my note, and adds its own perspective under an Auto: prefix.
• Auto: I hand over a target and Claude drives the browser.

I live in copilot mode. I know what I am trying to build. I do not know the domain, and I do not know what I am not seeing. A second voice, one that has read the principles and looked at a lot of dashboards, catches what I miss.

A session starts with me telling Claude “let’s study Vercel.” Claude sets up the folder. I browse Vercel in Chrome, dictating through Wispr Flow instead of typing. When something catches my eye I say “add this, clean sidebar nav with inline filter.” A shell script grabs the screenshot, Claude names the file from my note, drops it in the right folder, appends my words to vivians-notes.md, and adds its own take under Auto:. I keep browsing. Capture and filing happen while I am still looking at the page.

Everything lands in the same shape. One folder per platform, screens inside, notes next to them:

├── screenshots/
│   ├── vercel/
│   ├── stripe/
│   ├── datadog/
│   ├── samsara/
│   ├── linear/
│   ├── kiona/
│   ├── schneider/
│   └── ...
├── vivians-notes.md
└── open-questions.md

Every platform gets its own folder under screenshots/. My notes and open questions live at the root so I can scan them across platforms. vivians-notes.md holds my words on one line and Claude’s on the next. The raw capture is the research.

A page of vivians-notes.md looks like this:

**Project view: not sure how it translates.** (Vivian) Vercel
shows projects as cards. Not entirely clear how this maps to a
portfolio of buildings.

> **Claude's take:** Cards work for Vercel because users have 5
> to 20 projects each. At 5,000 buildings, cards do not scale.
> This is where Vercel stops being the right reference and
> Samsara or Linear's list view becomes more relevant: dense,
> scannable rows with sortable columns (name, city, health,
> active services, last event). Portfolio overview should be a
> table, not cards.

One sentence from me, a paragraph back from Claude. That is the pattern across all sixteen platforms.

A session, step by step

Subject: Vercel. Mode: copilot.

The screenshots for these sessions live on my personal Vercel deployment, so I have omitted them here. The notes below are what the copilot produced.

1. Deployments overview

**Deployments overview: filterable table.** (Vivian) Date range,
search, status dropdown. Color-coded status badges. Each row: hash,
status, project, branch, commit, timestamp.

> **Claude's take:** Three filters carry most of the load: status,
> search, and date range. Together they answer "what had alarms
> this week?" and "what is still onboarding?" without a custom
> report. The color-coded status badges are what make the table
> scannable at 500 rows. A table without them is a wall of text.
> This is the shape a portfolio list should take, not the
> dashboard home.

2. The inbox

**Inbox: actionable notifications.** (Vivian) Clean split-pane.
List of notifications on the left, each archivable; detail on
the right.

> **Claude's take:** Critical pattern. Property owners managing
> 5,000 buildings will have a stream of events: alarms, status
> changes, SLA breaches. The inbox replaces the traditional alarm
> list in BMS systems but feels like email, not a SCADA panel.

I had flagged the inbox as pleasant. Claude flagged it as the replacement for the SCADA alarm panel every incumbent uses. That is not something I would have written, because I did not know what a SCADA panel looked like. One line shifted the inbox from “nice to have” to “load-bearing pattern.”

What came out of it

Sixteen platforms, eighty-six screenshots, two thousand lines of notes, seventeen cross-cutting patterns. They distilled into a design reference:

## Cross-cutting patterns

**4. Progressive exploration**
Not tabs-vs-panels, but a layered approach to depth. Three
layers: summary, alert detail with threshold viz, diagnostics
workbench.

**16. Activity feed as timeline**
Entity as a living timeline. Events, status changes, notes in
chronological order. The building is a conversation, not a
static record.

... and fifteen others.

I reviewed it row by row. Claude would propose a pattern, I would ask what problem it solved and whether it made sense for this product, and the proposal either held or got rewritten. Nothing landed without that exchange.

But the real output is a design partner. Someone with the domain knowledge I do not have, who translates what I notice into the domain: SCADA alarm panel replacement, cards do not scale to 5,000 buildings, use a table. The automation happens in the background. Screenshots, notes, filenames, folders. I look and talk.

Without this workflow the same study would have taken days, plus many meetings with engineers and business managers. Even then I would have leaned too hard on the energy incumbents and shipped something visually dated.

The reframe

The current AI story is about whose job it is taking. That was not my experience. The design decisions stayed mine: the inbox as the SCADA panel’s replacement, the table instead of cards at 5,000 buildings. Claude carried the capture, filing, and second voice.

The question is not whether AI takes your job. It is whether you let it make you better at it.