In 2014, the city of Oakland, California had a problem that nobody would have described as exciting. Every time a resident called to report a pothole, a broken streetlight, or a flooded storm drain, the complaint went into a spreadsheet. A city worker read the spreadsheet. The city worker sent an email. Somebody else read the email and decided whether to dispatch a crew. The crew went out, or didn't, or went to the wrong address. The resident heard nothing for weeks.
The process had existed in roughly that form since the 1980s. It wasn't broken in the dramatic sense — nothing exploded. It was broken in the quiet sense: it wasted thousands of hours every year, frustrated everyone involved, and produced worse outcomes than a well-designed notebook would have. Nobody had fixed it because nobody had been asked to look at it whole.
When Oakland eventually connected its 311 complaint system to an automated routing tool in 2015, average response time dropped from 14 days to under 3. No new employees. No new budget. Just someone finally mapping the process clearly enough to see where the time actually went.
Most automation courses want to jump straight to tools. Zapier this. Make that. Connect these two apps and watch the magic happen. But Oakland's story points at something more important: the tool was never the hard part. The hard part was getting a clear picture of the actual process — every step, every handoff, every place where a human had to stop and wait for something.
That map — a complete picture of how a process actually moves — is called a workflow. Not how the process is supposed to work, but how it really works on a Tuesday at 2pm when someone is running late and the usual person is out sick.
Before you can design any automation challenge worth solving, you have to find a workflow that has a broken seam in it. A broken seam is a place where the work stalls, goes manual for no good reason, gets duplicated, or requires a person to do something a computer could handle faster and without getting tired.
In 2017, a 16-year-old student named Param Jaggi built an algae-based carbon-scrubbing device for car exhaust pipes — not because he had better chemistry than professional engineers, but because he had looked at a process (cars producing CO₂) and asked a question the engineers weren't asking: what if the fix happened at the pipe, not the engine? He reframed the problem before touching a single tool.
This is the move. Before you open any automation platform, before you write a single trigger or action, you ask the reframing question: Where exactly does this process lose time, lose accuracy, or lose information — and why has that always been accepted as normal?
The answer is almost always the same: it got accepted as normal because the people doing the work adapted to it. When you adapt to a broken seam long enough, you stop seeing it as broken. You see it as just how things are. You need to become the person who can see it fresh.
You can now see what most people miss. The goal of this lesson — and this module — is to make you that person: someone who walks into any process and can immediately spot the seams.
When Oakland automated its 311 routing, some city workers who had spent years managing those spreadsheets found their jobs significantly changed. No one was fired. But the nature of the work shifted in ways those workers didn't choose. Here's the question this raises, and it has no clean answer: when automation makes a process more efficient, who decides what happens to the people who were doing that process? Should they get a say? Does it matter that the outcome was better for residents? Sit with that.
Professional process designers — people who do this for companies like McKinsey or Accenture and charge enormous amounts of money — use frameworks that are genuinely complex. But the core of what they do can be compressed into three questions you can ask about any process you encounter:
1. Where does it wait? — Find every point where the process pauses for a human decision, an email reply, a manual check, or an approval. Waiting is where time disappears.
2. Where does it duplicate? — Find every point where the same information gets typed, copied, or re-entered somewhere it already exists. Duplication is where errors appear and energy gets wasted.
3. Where does it go silent? — Find every point where nobody knows what's happening. The pothole complaint that went into a spreadsheet and was never acknowledged. The job application that disappeared into a portal. Silence is where trust breaks down.
These three questions are your audit tool. Apply them to any process — at school, at home, in a business — and you'll find broken seams within minutes. The seam that answers yes to all three is your best automation candidate.
Ages 13–15, notice something here: when institutions fail publicly — delayed emergency responses, slow government services, broken healthcare paperwork — they almost always fail at a broken seam. This isn't an abstract design concept. It's a policy problem. Understanding where seams break is how you evaluate whether an institution is actually working.
Think of one process you interact with regularly — at school, in a club, at home — that feels slow or repetitive. Apply the three questions. Where does it wait? Where does it duplicate? Where does it go silent? You don't need to solve it yet. Just see it clearly.
You're going to describe a real process you know — from school, home, a club, or anywhere — and your lab partner (an AI auditor) will help you apply the three audit questions to find the broken seam. Your partner won't tell you where the seam is. You have to argue for it.
This is an investigation, not a lesson. Your partner will push back, ask you to be more specific, and challenge conclusions that aren't well-supported.
In 2015, IBM announced that its AI system Watson would transform cancer treatment. The pitch was compelling: Watson would read millions of medical papers, analyze patient records, and recommend personalized cancer therapies faster and more accurately than human oncologists. Hospitals paid tens of millions of dollars to license the system. MD Anderson Cancer Center alone spent $62 million on a Watson-based project over three years.
By 2017, internal documents leaked to STAT News showed Watson was recommending treatments that oncologists described as "unsafe and incorrect." In 2022, IBM quietly sold off the entire Watson Health division for a fraction of what it had invested. One of the largest AI failures in corporate history.
What went wrong? The problem had been defined too broadly. "Help doctors treat cancer" is not a problem that a machine can solve. It's not a seam — it's an ocean. The engineers had never mapped a specific workflow, found a specific bottleneck, and asked a specific question narrow enough that the AI could actually help. They had skipped the design step entirely.
Watson's failure has a name in design circles: the scope trap. You find a real problem — cancer treatment is genuinely hard and inefficient — and you write an automation challenge that's so big and vague that no tool can make meaningful progress on it. The challenge sounds important, which makes it feel like the right challenge. But importance and specificity are different things.
A well-designed automation challenge has three qualities. It's specific enough that you could describe every step of the workflow being changed. It's bounded — you know where the automation starts and where it stops. And it's testable — you can describe, in advance, what "better" looks like in measurable terms.
IBM's Watson challenge failed all three. "Help doctors treat cancer" has no defined workflow, no clear boundary, and no agreed measurement of success. No wonder it collapsed.
In 2019, a team of students at a Brooklyn high school entered a regional design competition with a project about food insecurity. Their original challenge statement: "Use AI to solve hunger in New York City." Their mentor sent it back with one comment: too big.
They spent two weeks mapping the actual process at a local food pantry — how donations came in, how inventory was tracked, how clients were served. They found one specific seam: volunteers spent about 40 minutes each morning manually counting inventory before the pantry opened, and frequently misjudged supply levels, causing either waste or shortages. Their revised challenge statement: "Automate the morning inventory count at the Bedford Community Pantry so volunteers can spend that time serving clients instead."
That team won. Not because hunger is easier than cancer, but because they found a challenge small enough to actually solve.
The format that works is built around a simple sentence structure:
We want to automate [specific task] in [specific workflow] so that [specific person] can [specific better outcome] instead of [specific current waste].
Every blank in that sentence has to be fillable with a real, concrete answer — not a general concept. If you can't fill it in, your challenge isn't defined yet.
IBM spent $62 million of hospital money — money that could have funded actual cancer treatment — on a system that didn't work, partly because the problem was never defined carefully enough. Who is responsible for that? The engineers who built it? The executives who oversold it? The hospital administrators who bought it without demanding proof? When an institution makes a costly mistake in the name of innovation, where does accountability actually sit? This question is being asked right now about dozens of AI deployments in healthcare, education, and criminal justice.
The most commonly skipped step in automation design is defining what success looks like before you start. This sounds obvious. Almost nobody does it.
In 2020, the city of Chicago deployed an algorithm to predict which buildings were at risk of fire so inspectors could prioritize their visits. The algorithm worked — it correctly identified high-risk buildings at a rate significantly better than chance. But when journalists at ProPublica analyzed the results, they found the algorithm was also disproportionately flagging buildings in low-income and minority neighborhoods for inspection, which sometimes led to fines that displaced residents. The city had defined success as accuracy of fire risk prediction. They had never asked: accurate compared to what else? Or: accurate in a way that distributes burden fairly?
A testable challenge defines not just what you're measuring, but who you're measuring it for, and what the unintended consequences might be. This is harder than writing a success metric. It requires thinking in advance about who benefits and who might be harmed.
You now know something that most automation designers skip entirely: the question "how will we know if this works?" has to be answered before the automation runs — not after something goes wrong.
Before you finalize any automation challenge: Can you name the specific workflow? Can you describe every step? Can you say where the automation starts and stops? Can you define success — including for people who weren't asked? If any answer is no, you're not ready to build yet.
Take the broken seam you found in Lab 1 — or pick a new one — and write a challenge statement using the format from the lesson: We want to automate [specific task] in [specific workflow] so that [specific person] can [specific better outcome] instead of [specific current waste].
Your lab partner will evaluate it against the three criteria: specific, bounded, and testable. Expect to revise it at least once. The first version is almost never good enough.
In 1968, Wells Fargo launched what it called the first modern ATM system in the United States. The machine did something that, at the time, seemed almost magical: it gave people money without a human teller ever being involved. Customers slid in a card, punched in a code, and cash came out.
What the bank had actually built, stripped of the wonder, was a simple two-part logic: if a card is inserted and a correct PIN is entered, then dispense the requested amount and deduct it from the account balance. That was it. The entire "magic" of the ATM was one trigger — a card plus a correct PIN — connected to one action — dispense money and update a record.
Today, every no-code automation platform in the world — Zapier, Make, n8n, Airtable, Power Automate — runs on exactly the same logic. Something happens. Then something else happens because of it. The tools have gotten dramatically more powerful. The underlying shape has not changed at all.
Before you can design a real automation challenge, you need to understand the shape that all automations share. It's called trigger-action logic, and once you see it, you'll recognize it everywhere — in apps, in smart home devices, in industrial machines, in algorithmic trading systems.
A trigger is the thing that starts an automation. It's a specific event that the system watches for. Not a general condition — a specific, detectable event. A form is submitted. An email arrives with a specific subject line. A file is uploaded to a folder. A date and time arrives. A number in a spreadsheet crosses a threshold.
An action is what the automation does when the trigger fires. It's also specific and concrete. Send an email to this address. Add a row to this spreadsheet. Post this message to Slack. Create a calendar event. Move a file to a different folder. Update a database record.
The trigger is the when. The action is the then. All of no-code automation design is finding the right when and building the right then.
In October 2012, Knight Capital Group — one of the largest trading firms on Wall Street — lost $440 million in 45 minutes because of a software error in their automated trading system. A technician accidentally activated an old piece of code that was supposed to have been turned off. The old code's trigger was: "when a buy order is placed." Its action was: "buy as many shares as possible as quickly as possible." For 45 minutes, the system executed that logic over and over, on real markets, with real money, until someone physically walked to a server and turned it off.
The lesson here is not that automation is dangerous. The lesson is that trigger-action logic is precise and literal. The machine does exactly what you told it to do, not what you meant. If the trigger is too broad — "when a buy order is placed" without any limits or conditions — the action will fire in every situation that matches, including situations you never intended.
This is why the design step matters so much. Before you connect a trigger to an action, you have to ask: In exactly what circumstances should this trigger fire? In what circumstances should it not? What happens if it fires at the wrong time?
At an institutional level — and this matters for anyone thinking about policy — this is why large organizations spend enormous resources on "edge case" testing. An edge case is a situation that technically matches your trigger's conditions but is not a situation you intended to handle. Finding edge cases before deployment is one of the most valuable things a human can do in an AI-heavy system.
Knight Capital's $440 million loss was caused by a human mistake — someone re-activated old code. But the damage was done by a machine that could act far faster than any human could intervene. If a machine can cause $440 million in damage in 45 minutes, should there be legally mandated "kill switches" in all automated financial systems? Who decides what those thresholds are? And what happens when the machine's speed is also the thing making the system valuable? Speed and risk are the same variable here — you can't fully separate them.
Professional automation designers almost never start at a computer. They start with paper or a whiteboard. They draw a flowchart — a simple diagram where each box is a step, each diamond is a decision, and each arrow is a connection. The flowchart lets you see the whole shape of the automation before any tool is opened.
For your automation challenge, you need to be able to draw three things: the trigger event, every action that follows, and every decision point (places where the automation branches based on a condition — "if this is true, do A; if not, do B").
In 2016, a team at the UK's National Health Service used this exact approach — flowcharting on paper first — to design an automated appointment reminder system that reduced missed appointments by 23% in its first six months. They found three decision points during the flowcharting process that they would have missed if they'd started building immediately: patients who had already confirmed didn't need a second reminder; patients over 80 preferred a phone call over a text; and reminders sent after 8pm had a significantly lower response rate. None of these were obvious before seeing the flow drawn out.
You now understand something that separates designers from builders: drawing the workflow is not preparation for the real work. Drawing the workflow is the real work. The building is just translation.
For your challenge statement from Lesson 2, try to identify: What is the trigger? What is the action (or actions)? Are there any decision points — conditions where the automation should do something different depending on circumstances? Sketch it on paper if you can. Even a rough sketch reveals things a written description hides.
Take your challenge statement from Lab 2 and describe the trigger-action structure: What is the trigger event? What actions follow? Are there any decision points where the automation should branch? Your lab partner will help you stress-test the design by finding edge cases — situations where your trigger might fire when it shouldn't, or where your actions might cause unintended effects.
Think of this like designing the blueprint before anyone picks up a tool. Your partner is the structural engineer who finds the load-bearing problems before the building goes up.
In 1979, Steve Jobs visited the Xerox Palo Alto Research Center (PARC) on a deal brokered by Xerox's own investors. What he saw there — a computer with a graphical interface, icons, windows, a mouse — would eventually become the Macintosh. The engineers at PARC had invented the modern personal computer interface. Xerox had it first, by years.
Xerox did not build it into a product. The engineers who designed it could not communicate its value to the executives who controlled the budget. They showed demos. The executives saw a toy. Xerox's core business was copiers. Why would anyone buy a computer they could point at instead of type on?
Jobs saw the same demo and understood it in thirty seconds. When he left, he told his team to build it. The Macintosh launched in 1984. Xerox's interface technology, invented by their own researchers, was commercialized by a competitor who had walked through their front door.
The people at PARC had a correct and genuinely world-changing idea. They failed to communicate it to the people with the authority to act. The idea died at the seam between having it and sharing it.
This is not a lesson about selling yourself. It's a lesson about translation. When you've spent time mapping a workflow, finding a seam, writing a challenge statement, and designing a trigger-action structure, you know things that your audience doesn't know. The gap between what you know and what they know is the communication gap. Bridging it is design work, not performance.
Every automation challenge presentation has to answer four questions in the listener's head — usually within the first two minutes. If these questions aren't answered, the listener's brain fills them in with skepticism:
What is actually broken right now? Not in theory. With specific evidence. How much time is being lost? How many errors? Who is affected?
What exactly would change? Not "the process would be better." A concrete description of the before state and the after state, step by step.
How do we know it worked? A specific measurement. Not "it will feel faster." Numbers, comparisons, a before-and-after you can check.
What could go wrong? This one surprises people. Addressing failure modes upfront actually increases trust. It shows you've thought past the optimistic case.
In 2018, a team of three teenagers from Lagos, Nigeria won the Africa Prize for Engineering Innovation with a device that detected lead contamination in water using a cheap sensor connected to a phone. Their prize pitch didn't open with the technology. It opened with a specific story: a specific school in Lagos where students had been getting sick, the specific number of weeks it had taken to identify lead as the cause, and the specific number of tests that a health worker had to manually process during that time.
Then they showed what their device changed: not "it's faster," but "a health worker using this device could test a water source in 90 seconds instead of waiting 11 days for a lab result." The audience felt the difference because the before-and-after was concrete enough to be experienced, not just heard.
Your automation challenge presentation should work the same way. Start with the before — a specific, real description of how the process currently runs, including the frustration or cost. Then show the after — not as a promise, but as a concrete, testable change. The gap between before and after is your argument. You don't need to oversell it. A clear gap sells itself.
Steve Jobs walked into Xerox PARC because investors had arranged the access. The engineers didn't invite him. The technology they spent years building was then commercialized by someone else, and Xerox received almost no benefit. When you design something and someone else builds it and profits — because they were better at communicating its value — is that fair? Does it matter that millions of people got access to better computers as a result? Who owns an idea if the people who had it first couldn't communicate it?
In 2021, a 14-year-old student named Hana Kobayashi presented an automation challenge to her school's technology committee: a system to automatically categorize and route student IT support tickets so that simple issues (password resets, printer problems) were resolved by automated instructions before being escalated to a human technician. The committee's first question was: "What happens when the automation miscategorizes a ticket and a student needing real help gets an automated response instead?"
She had prepared for this. Her answer: the system would always offer a "this didn't help" button, which would immediately flag the ticket for human review and notify the student within 15 minutes. Misrouted tickets would be logged and used to improve the categorization model. The committee approved the pilot.
Anticipating the hard questions isn't about being defensive. It's about showing that you've thought past the moment your automation runs perfectly — which is the moment everyone imagines — and into the moment it doesn't. That's what separates a design that gets built from one that gets politely declined.
You now understand the full arc of designing a real automation challenge — from finding the broken seam to mapping the workflow, from writing the bounded challenge statement to presenting it in a way that earns the right to build it. That arc is what this module has been building toward. Everything from here is practice in executing it.
You've mapped the journey from "something feels broken" to "here's a specific, buildable, presentable automation challenge with defined success metrics and anticipated failure modes." That's professional-level design thinking. Take the module test when you're ready.
You've found a broken seam, written a bounded challenge statement, designed the trigger-action structure, and thought about edge cases. Now you present the whole thing as if you're pitching it to a school administrator, a manager, or a community leader who has the power to approve or reject it.
Your lab partner plays a skeptical but fair decision-maker. They will ask the four questions: What's actually broken? What changes? How do we measure success? What goes wrong? You need to answer all four convincingly — not with a script, but by thinking through what you actually know.