Allie K. Miller: Write the Workflow Before Automating It
How can I turn a repeated task into instructions someone else can follow?
Choose, practice, reflectA practical learning exercise
The Lesson
You finish a familiar task almost without thinking. Someone asks you to explain it, and your instructions become “check the request, make the changes, then send it back.” The missing details are the decisions you have learned to make along the way. An assistant, a colleague or a future client cannot reliably infer them from that sentence.
In a public post about her no-code AI workflow, Allie K. Miller starts with work she has done repeatedly. She gathers examples of inputs and outputs, describes the procedure, and uses that material to guide subsequent drafts and edits. Her official website identifies her work teaching and advising on AI in business.
That sequence offers a useful starting point: document the work you understand before trying to automate it. A procedure should explain the decisions between the input and the result. Examples then show what those decisions look like in an ordinary case and in a case that needs clarification.
Consider a fictional flyer-editing service. A request arrives: “Please fix the event flyer and have it ready Friday.” Before editing, you need to know which file is current, which changes are requested and whether Friday is a requested deadline or an agreed one. A procedure that skips those questions may turn an uncertain request into an invented commitment.
Describe each step with an input, an action and a visible result. “Review the request” becomes: read the supplied message, identify the current file and requested edits, then create a brief with unresolved questions in a separate section. “Send it back” becomes: prepare the draft and review note for the named approver. Who approves the work matters as much as who prepares it.
Keep examples distinct from rules. One client requesting a blue heading does not establish that every heading should be blue. The reusable rule might be “preserve the supplied style unless the request explicitly changes it.” The example illustrates that rule; it does not replace it.
Current Anthropic prompting guidance recommends explicit output constraints and ordered steps when sequence matters. Those are useful drafting choices, but clear instructions still need checking on your task. A procedure is ready for another trial when someone can follow it and show where they stopped, not simply when it sounds professional.
Reflection
- Which repeated task do you already understand well enough to explain?
- What do you check automatically that a newcomer would not know to check?
- Which missing detail should pause the work?
- Who decides whether the result is acceptable?
- Which part of your example is a one-time preference rather than a reusable rule?
Practice
Original SelfGrowthVideos exercise: make a one-page workflow handoff. This is our exercise, not Miller’s template or an endorsed method. Work on paper or use an assistant you already have. Use fictional requests rather than client files.
- Choose one small task. Prepare a request brief for a flyer editor. The result should help an editor understand the request; it should not edit a file, agree to a deadline or send a message.
- Write the procedure. Identify the supplied file, list the requested changes, record the requested deadline and name the approver if supplied. Put missing or conflicting information under “Questions before work starts.” Keep requested deadlines separate from confirmed commitments.
- Make a complete example. Write: “Use flyer version 3. Change the start time to 6 p.m. Keep the colors. Please return a draft by Friday. Morgan will approve it.” Create the expected brief yourself. Label Friday as requested, and Morgan as the approver.
- Make an incomplete example. Write: “Use the latest flyer and update the time.” The expected brief should ask which file is current and what the new time is. It should not choose a file or time on its own.
- Try a handoff. Give another person, or an assistant, the procedure and the first example. Then give them a fresh request: “Use version 4; change the venue; Lee approves.” Check whether the result asks for the venue and preserves the supplied file and approver.
- Revise the rule that caused confusion. If the brief invented a venue, specify that missing values become questions. If it treated a requested deadline as agreed, clarify that distinction. Keep the corrected example beside the procedure.
Review
At the next trial, ask the recipient to explain what they can do now and what remains unresolved. Record one instruction that worked and one that needed explanation. If you later consider offering this as a service, use the handoff to describe its scope and review responsibility; a successful fictional trial does not establish customer demand or a production-ready automation.