the engineering design process
setup (5 min)
In your worksheet, each person should write down three real problems that they want solved in their work, personal projects, computer life, or internet life.
For example:
- "I always procrastinate on buying groceries, and then I don't want to buy groceries, so I suffer."
- "Members in my co-working space don't get emails when they sign up, so they are confused, which isn't fun."
- "I don't know whether my business is growing or shrinking, or why, so I feel lost and aimless."
- "I feel addicted to social media and it causes me to waste away and detach from my friends."
- "I can't express myself musically by writing songs, so I'm frustrated and feel creatively blocked"
- "I am overwhelmed at work by too many messages, emails, and meetings, and not enough time to organize it all. I wish everything was organized, so I don't feel so overwhelmed."
After you're finished writing down your three problems, add a 🔎 emoji to TWO problems you really want to try to solve in your group.
Pick whichever problem got the most 🔎 emojis. The person whose problem it is becomes the "client." Everyone else is the engineering team. ALL of you should start a recording, using some kind of meeting transcription software or voice recorder on your phone.
the engineering design process
1. define the problem (5 min)
The client describes their problem, and the team interrogates it:
- What actually hurts?
- When does the problem occur, and in what context?
- How often does the problem occur?
- What happens if it stays unsolved?
- Understand why the problem matters.
- Look for multiple problems, or hidden problems, or false assumptions.
- Get enough detail that you could personally take responsibility for solving the problem.
Keep asking "what is this actually trying to solve?" until it grounds out in something the client clearly, deeply cares about.
This may remind you of our design exercise from class 1, and that's because that design exercise IS a problem definition exercise!
Agree on a WRITTEN problem statement, such as "The problem is ___."
The client should sign off on that sentence before you move on to research.
2. background research (10 min)
- What already exists?
- Has the client tried anything before? How did that work?
- What does the team know from their own lives?
- Are there constraints we should know about?
- How does the problem work?
- Ask your agents to do research on this problem, to see if anyone else has solved it in a simple or elegant way, or to see how many other people experience the same problem!
Compile your research into a "memo" with the problem statement at the top, and a summary of all of your research. Make sure to read the background research!! You can learn SO SO much from researching a problem. In fact, this step is responsible for most unexpectedly useful knowledge I have, by far. I love background research!
3. specify requirements (10 min)
What would "solved" look like, concretely? Write at least 3-5 checkable, testable criteria. Try not to specify the solution inside the requirements! Don't assume the solution!
In the real world, this is one of the most important parts of the engineering process, and it's a core aspect of what we interview for in "system design" interviews.
Here are some requirements to check:
functional requirements:
- what new behaviors or capabilities must exist for the problem to be "solved".
non-functional requirements:
- cost (maintenance cost)
- cost (build cost)
- scale (how many users?)
- usage requirements (how/when will it be used?)
- reliability requirements (how often can it fail?)
- training / habits (will the users be trained?)
- maintenance requirements (who needs to maintain it?)
Bad: "it feels better." (too vague!) or "zo computer is setup" (specifies the solution! maybe zo is the wrong tool!)
Good: "inbox has zero recurring subscriptions I don't want." or "groceries arrive at my house on monday between 12pm-3pm automatically, and i never needed to say anything or open an app" or "the system is free to maintain with my existing subscriptions."
4. brainstorm solutions (10 min)
The point here is Quantity and Variance and Creativity over "quality". Each person should brainstorm at least 5 ideas. Try to include the laziest and cheapest possible idea (engineers love these!). Also, include at least one very absurd and silly idea (we also love these)!
Your ideas should satisfy the requirements, ideally your background research is helpful here.
5. evaluate + pick (5 min)
Score your TOP brainstormed solutions against the requirements from step 3.
Do NOT just use vibes!! If you're just using vibes, articulate those vibes AS REQUIREMENTS and add them to your requirements. Good iteration!
The Client should pick a solution, and two other runner-up solutions.
6. prototype (10–15 min)
Use your agents to Prototype the solution. Just copy-paste your entire doc into the agent, and ask it to prototype the chosen solution, based on the context and requirements specified.
All 3 of you can run separate agents, trying out separate aspects of the solution (or submodules), or prototyping designs to show the client.
Try to make as much progress in the prototype as possible, until the client has a "HELL YES!!!" feeling, and they are VERY happy with the direction, and with the prototype.
Keep trying things, in parallel, until they are HAPPY with something.
7. test against requirements (10 min)
Try to rigorously test the solution(s) against the requirements from step 3, both in simulation and, if possible, in a real world environment.
If your prototype doesn't solve the problem, is that because it didn't meet requirements, or is it because the PROBLEM was under-specified, and you are uncovering new aspects to the problem?
8. communicate results (5 min)
Typically, this is important when you're working on a larger team or in a larger organization, so they know:
- What problem you solved
- What requirements you met
- The Cost/Details/Specification of your solution
- The results
In your case, take your conversation and your "final product", and ask your agents to turn it into a Specification Document, which anyone else could use to replicate or modify the solution to their needs, if they have a similar problem.