BRIEF.md, the template

The project brief for your semester project. You start it on September 2 and keep adding to it all semester; each version you hand in goes on Blackboard. Dan Brown calls this the shared document where the problem statement, the objectives and the key insights about context live (Practical Design Discovery, chapter 4). It is never finished. Every hand-in this month is a section of this file, revised.

Copy everything below the line into a new file called BRIEF.md, then fill it in.

1. Assertions

Dated. Expected to be wrong. When you revise, add the new version above the old one with a new date; do not overwrite.

Problem statement

v0, YYYY-MM-DD. One or two sentences. Who is stuck, what they are trying to do, what is in the way, what it costs them. Write it like a reporter: the project and the core conflict as fast as you can. If your solution fits in the sentence, it is the wrong sentence.

Project objective

v0, YYYY-MM-DD. What you will deliver, not what problem you will solve. Brown's five things to be specific about: scope, outputs, fidelity, time, priority. This becomes the one-page proposal behind your pitch on Sep 21.

2. Context

A few lines under each. Put a ? at the end of every line you have not checked against a person or a document. The question marks are the point.

Business

Domain, mission, objectives, markets, brand, culture, operating processes. For a product with no market this box is mostly empty. Say so.

Technology

What the product is, what it does, what it depends on, what it cannot do. You are not the expert. Write down what the people who made it told you.

Users

Expectations, what they cannot see or do not have on hand, everything they do around the activity (not just the part your product touches), what they believe about the industry. This section becomes your audience hand-in on Sep 9: three audiences, a paragraph each, which one you lean to.

Content

What exists to read about this product: papers, patents, documentation, reviews, forum threads, job postings that describe the pain. Style, structure, how much of it there is and how good it is.

3. Hunches

Impressions as they come, one per line, dated, with the evidence beside it. Review them when you add to section 2. Delete the ones the evidence stops supporting. Brown: learn to let go.

• YYYY-MM-DD. Hunch. Evidence: who said it, or where you read it.

4. Questions

The three questions you must answer to set a direction, picked from the question marks in section 2. For each one: the gathering activity that answers it (stakeholder interview, domain research, existing assets, user research, competitors, the current product), who you will ask or what you will read, and the date. Anything not answerable by Sep 12 is not in the problem statement.

1. Question. Activity. Who or what. By when.
2. Question. Activity. Who or what. By when.
3. Question. Activity. Who or what. By when.

5. What the machine did

One line per session. What you asked the model, what it gave you, what you kept, where you overruled it. This is the note every hand-in asks for, kept in one place.

• YYYY-MM-DD. What you asked. What you kept.