Spreadsheet Human UX

View saved version →

---
name: spreadsheet-human-ux
description: Design or review human-facing spreadsheets, Google Sheets, workbooks, dashboards, trackers, models, simulators, and decision tools so they are easy to understand, operate, resume, and trust. Use when spreadsheet usability, navigation, input safety, visual hierarchy, accessibility, cognitive load, or decision clarity materially affects whether people can use the artifact correctly; pair with technical spreadsheet/formula skills rather than replacing them.
---

# Spreadsheet Human UX

Design the **human interaction layer** of a spreadsheet. Preserve analytical correctness, formulas, provenance, and auditability; do not trade them away for visual polish.

This skill complements spreadsheet execution, data-quality, financial-modeling, and domain-verification skills. It does not own those concerns.

## 1. Preflight the human task

Before changing tabs, cells, or styling, identify:

- **User:** who operates or reads the workbook, and what expertise can be assumed?
- **Task:** what recurring job or decision must they complete?
- **Context:** desktop/mobile, shared/solo, time-pressured/exploratory?
- **Frequency:** one-off, frequent, periodic, or resumed after long gaps?
- **Risk:** what happens if a value is misunderstood or the wrong cell is edited?
- **Complexity:** which inputs, scenarios, calculations, outputs, and evidence are materially necessary?
- **Success:** what should the user be able to answer or do without help?

Treat the user model as runtime context. Never hard-code a named person or Project unless that identity is the actual purpose of the artifact.

## 2. Decide whether a UX layer is warranted

Use this skill when human interaction matters. Do not polish a raw evidence table, archival registry, or machine-oriented dataset merely because it is a spreadsheet.

When a structured backend table must also support frequent human use, preserve the data layer and add a user-facing surface instead of weakening the underlying structure.

## 3. Design the common path first

Optimize the first view and normal workflow for the 80% task. Keep advanced assumptions, calculations, evidence, and audit detail accessible through progressive disclosure.

Prefer the smallest visible information architecture that works. A decision-facing workbook often benefits from a path such as:

**START / DASHBOARD → INPUTS → SCENARIOS / DECISION → DETAIL / MODEL → EVIDENCE / SOURCES**

This is a pattern, not a mandatory template. Read `references/design-patterns.md` when designing or materially restructuring the workbook.

## 4. Make inputs safe and obvious

For every material editable input, make visible:

- human-readable label;
- current value;
- unit/format;
- status or source when material;
- short clarification where ambiguity is likely.

Prefer prevention over warning-after-the-fact: controlled dropdowns, validation bounds, protected formula regions, safe defaults, explicit required fields, and checks for impossible combinations.

Group inputs by **user intent**, not by formula dependency. Reduce typing when options are known, while preserving spreadsheet flexibility where exploration is valuable.

## 5. Make outputs interpretable

A key result should carry enough context to stand on its own: value, unit, relevant period, active scenario/baseline, and a concise interpretation when useful.

Expose the variables that can change the decision. Prefer sensitivities, ranges, or breakevens to false precision when uncertainty is material.

Charts are optional. Use them only when a relationship, trend, sensitivity, or composition is faster to understand visually than as a number or table.

## 6. Reduce cognitive load without hiding logic

Use recognition over recall: visible labels, units, edit conventions, scenario indicators, legends, and nearby explanations.

Use consistent visual semantics for the same kinds of things across the workbook. Favor spacing, alignment, hierarchy, and restrained emphasis over d

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 6 — file references are metadata, not package contents.