Expert Excel · Interactive lesson 1 of 12
Solution architecture & requirements
"Can you make me a dashboard?" is not a specification. Before a formula gets written, an expert-level build starts by turning a vague request into a design: who's deciding what, how often it refreshes, and what "done" actually means.
Screens shown: Excel for Microsoft 365 for Windows. Practice works in any browser.
Written tutorialPlanning an Excel Solution: Requirements and DesignSkill check
Try these first:
- Name the decision a workbook needs to support before opening Excel.
- Sketch a workbook map — source, staging, model, report, QA, and notes.
- Draft an assumptions register entry and name a maintenance owner.
- Write acceptance criteria that are actually testable, not just "looks good."
Comfortable already? Skip ahead to E2 — Advanced Dynamic Array Systems.
Concept teach
What you're learning
- Business question & decision owner
- Every solution answers one question for one named person — "is each region on pace" for the regional VP, not "here's some sales data" for whoever opens it.
- Inputs, outputs & refresh cadence
- What goes in, what comes out, and how often it needs to be current — a daily ops report and an annual board deck have completely different builds even with the same data.
- Workbook map
- Source (untouched raw data) → Staging (cleaned, not yet modeled) → Model (relationships and calculations) → Report (what a reader sees) → QA (proof it's right) → Notes (how to run it).
- Assumptions register
- Every rate, cutoff, or judgment call gets one visible cell, a name, and a one-line reason — not buried in a formula where the next editor will never find it.
- Source-to-output lineage
- Being able to point at any number in the final report and trace it back to the exact source row it came from — the difference between a report you can defend and one you're hoping is right.
- Maintenance owner
- A named person who refreshes it, fixes it when it breaks, and knows who to call if they leave — a workbook with no owner is a workbook nobody will trust in six months.
- Acceptance criteria
- Written before you build, not after: specific, checkable statements ("ties to source within $1") rather than vague ones ("looks professional").
Where to find it in Excel
README sheet›Workbook map in the tabs›Review › Notes
| A | B | C | D | ||
|---|---|---|---|---|---|
| 1 | README — Weekly Operations Model | ||||
| 2 | Decision it supports | Weekly staffing by region | |||
| 3 | Decision owner | Ops Director (Maria Lopez) | |||
| 4 | Refresh | Mondays 8:00, Data › Refresh All | |||
| 5 | Sources | Sales export, Targets file, Region table | |||
| 6 | Maintainer | Analytics team | |||
| 7 | Accepted when | QA sheet shows 0 failed checks | |||
| 8 | |||||
Swipe sideways to see the whole window.
- 1Start with a README: the business question, the decision owner and how to refresh.
- 2The tabs are the workbook map: inputs → staging → model → output, plus QA and a change log.
- 3Acceptance criteria you can test.
- 4Review › Notes documents an assumption right on its cell.
Rendered view of Excel for Microsoft 365 (Windows). Ribbon layout can differ slightly on Mac, Excel for the web or a narrow window.
Guided build
The request was: "Can you make me a monthly dashboard of sales?" Turn it into a real design brief.
Independent extension
Write a real design brief
Take a vague request you've actually received — "can you clean this up," "can we track this" — and write a one-page design brief: the decision it supports, its refresh cadence, a workbook map, one assumption worth naming, a maintenance owner, and three testable acceptance criteria. Show it to whoever asked before you build anything.
Spot a mistake or have an idea for this lesson? Send feedback