---
title: Design document
summary: Problem, audience, action map, objectives, design decisions and the measurement plan, written for the Storyline plan.
---

# Design document: One Task, Start to Finish

**Written for the Storyline plan.** This was written on 2026-10-12, before the course was built in Rise instead (Storyline runs only on Windows). The Rise script lists what changed.

**Everything in the practice is fictional.** Cedar Row Architects and its clients, fees and notes are made up. There are no learner results yet.

## 1. The problem

Small business owners are told AI can take work off their plate. Most have tried it, or plan to. The how-to content is everywhere: videos, threads, courses, tool docs.

The gap is focus. An owner sits down at night with an hour to spare and a dozen places to start. They watch and read, and the proposal they promised that afternoon is still unwritten. Nothing tells them what to do first, and nothing checks that they did it.

- **Dean's read:** owners don't know where to begin, and there's too much to focus on. What helps is a framework they have to follow, with progress that's tracked and judged. Dean learned the five steps by making the mistakes first, so learners don't have to.
- **The research agrees on the first half.** Most small-business owners in recent surveys say they need more AI training, and most learn it from YouTube and social media. Few hire anyone to set it up.

So the course supplies what free content can't: one path, in order, on one task of the owner's own, with a check before each step opens.

## 2. Audience

- **Who:** owners of small businesses anywhere in the US, from one person to about twenty. Local versions come later.
- **What they know:** their business, cold. Many have used a chat AI like ChatGPT or Claude. Claude Code is new to them.
- **What they don't want:** a coding lesson or a tour of every feature.
- **Constraints:** short sittings, often at night. Some find the terminal intimidating, so the course starts in the Claude desktop app and offers the terminal as an option.
- **What they need to bring:** a task they do over and over. Also a paid Claude plan, on a computer that runs the desktop app.

## 3. Action map

**Business goal:** owners who finish the course hand off a repeating task to Claude Code and are still running it a month later.

| Measure | How |
|---|---|
| Primary | Share of finishers whose saved task is still running 30 days later, from a short follow-up |
| Leading | Share of learners who complete all five "Do it for real" checklists |
| Baseline and target | **None yet.** Set both from the first group of learners. No number is claimed here. |

**Behaviors, practice and minimum information.** Each behavior is one of Dean's five steps.

| Behavior (what the owner does on the job) | Minimum information (taught) | Practice (mock Claude Code) | Do it for real | Tested |
|---|---|---|---|---|
| **B1. Picks one task that repeats** and that they see before a customer does | The four marks of a good first task (2.1) | Sort a bakery's tasks into "Good first task" and "Later" (2.2) | Name their task and how often it comes up (2.3) | Gate 2.4; bank Q1, Q2 |
| **B2. Gives Claude the details of the task** in a CLAUDE.md, sharing what the task needs | Claude Code works in a folder; CLAUDE.md is read every time; let Claude interview you (3.1) | Choose what to share with Claude; finish the firm's CLAUDE.md (3.2) | Have Claude interview them and write their CLAUDE.md (3.3) | Gate 3.4; bank Q3, Q4 |
| **B3. Runs the task and checks the result**, reading every permission prompt and every line before approving | Ask plainly; read the prompts; compare every number, then look for promises and additions (4.1) | Pick a request, handle two permission prompts (4.2), find and fix three problems in a draft proposal (4.3) | Run their task once and note what was off (4.4) | Gate 4.5; bank Q5, Q6 |
| **B4. Updates the instructions** when a result is off, with a specific rule, and runs it again | A hand fix stays in one draft; CLAUDE.md loads every session; vague vs specific rules (5.1) | Choose a fix for each of the three problems (5.2); see which come back on the next project (6.3, 6.4) | Add a rule for what was off in their run (5.3) | Gate 5.4; bank Q7, Q8 |
| **B5. Saves the task for next time** and approves each result | A skill is a saved set of steps with a short name; the owner's approval stays (6.1) | Save the firm's skill (6.2); run it on the next project and approve the draft (6.3) | Save their skill, run it, and set when they'll run it (6.5) | Gate 6.6; bank Q9, Q10 |

**Coverage check.** Every behavior has a lesson, practice in the mock screen, a real step in the learner's own Claude Code, a gate question and two bank questions. Every lesson slide serves a behavior.

**What the owner needs that training can't supply.** A paid Claude plan. A task whose rules they can explain. Time between steps to do the real work. A reminder in their calendar, which the course asks them to set in 6.5.

## 4. Objectives

By the end of the course, the owner can:

1. Name one task from their own business that repeats daily or weekly and passes their desk before a customer sees it.
2. Set up a task folder in Claude Code with a CLAUDE.md that holds the task's steps and rules, plus an example, sharing what the task needs.
3. Given a draft from Claude, find every line that differs from their source details, including added services and promised dates, and approve the draft once those are fixed. In practice: 3 of 3 problems found.
4. When a result is off, write a rule specific enough that the problem stays fixed on the next run. In practice: the next project's draft comes back clean.
5. Save the task as a skill, run it by name, and approve the result.

## 5. Design decisions

**1. A locked path with a check at every step.** *Rejected: an open menu where learners jump to any topic.* Dean's read of the market is that owners have plenty of content and no order to it. A fixed path, with a gate question and a real-work checklist before each step opens, is the product. The section bar shows the route, what's done and what's next.

**2. Practice in a mock screen, then the real thing.** *Rejected: screen-recorded video tutorials.* A recording dates as fast as Claude Code changes, and it can't judge anything the learner does. The mock screen is built from Storyline shapes and real text, so screen readers can read it and the course can score every choice. The "Do it for real" step then moves the habit into the learner's own Claude Code.

**3. Consequences that show up a project later.** *Rejected: right-or-wrong feedback on each fix in step 4.* The lesson of step 4 is that a fix carries forward only when it's in the instructions. Immediate feedback can't show that. So the learner's three choices in 5.2 drive the next project's draft in 6.3, where every problem without a specific rule comes back.

**4. One practice business from start to finish.** *Rejected: a different example in every step.* One firm lets a problem found in step 3 come back in step 5, and the learner already knows its fees and notes. An architecture firm turning intake notes into fee proposals has rates, totals and promises to check, and it reads as any small office. The learner's own business enters through the five "Do it for real" steps.

**5. Storyline for the course, Rise for the refresher.** *Rejected: building it all in Rise.* The course depends on variables carried across scenes, locked steps and draft lines whose state depends on earlier choices. Rise can't do those. Rise suits the five-minute refresher owners come back to before a step, and it embeds the Storyline practice from 4.2 and 4.3.

**The tradeoff I made:** the "Do it for real" checklists run on trust. The course can't see the learner's own Claude Code, so a learner can tick the boxes without doing the work, and a reviewer can click through in seconds. The checklists still ask for typed answers, which come back in the printable plan at the end. Verifying the real work would mean connecting to the learner's computer, which is out of scope for a course that runs in any LMS.

## 6. Measurement

| Level | What we'd look at | When | Status |
|---|---|---|---|
| 1. Reaction | Two survey questions after the plan slide: was it worth the time, and which step was hardest (8.2, 8.3) | At the end | Built into the storyboard |
| 2. Learning | Gate questions answered right, final check score (90% to pass), reported through SCORM | During the course | Built into the storyboard |
| 3. Behavior | Is the saved task still running? How often? | Follow-up at 30 days | Planned |
| 4. Results | Time the owner gets back each week, in their own words | Follow-up at 30 days | Planned |

**Results: none yet.** No learners have taken the course. Every number on the case study will be labeled Real, Pilot, Projected or Simulated.

## 7. Accessibility

WCAG 2.1 AA. The details are on every storyboard slide and in its build list. In short: every interaction works by keyboard, focus order is set slide by slide, every status pairs an icon with a word, every text color passes 4.5:1, captions come from the text-to-speech, there are no timers, and the mock screens are real text a screen reader can read. A one-page conformance note follows the accessibility check. For the Rise build, see the accessibility report.

## 8. Known limits

- **Claude Code changes often.** The mock screens look like it without copying it, and the wording needs a check against the current app before each build.
- **Self-reported real work.** See the tradeoff above.
- **One task.** The course takes an owner through one task. A second one is up to them, with the same five steps.
- **One industry in the practice.** The firm stands in for any small office. Local and industry versions come later.

## 9. AI use

Claude drafted this document, the storyboard and the question bank from Dean's framework and direction, and wrote tests that check the storyboard's math, branches and wording. Dean reviewed both and changed the framework wording, the audience and the practice business. Those changes start the AI-use log for the case study.