Idea concept sheet
Describe who an idea serves, the problem it addresses, how it works, and the smallest useful test.
Use this concept sheet between brainstorming and a fuller proposal. It makes a rough idea clear enough for someone else to discuss and compare.
One idea, its intended users, a problem, and an initial value hypothesis.
A concise concept with a proposed mechanism, assumptions, and a small test.
On this page
How to use it
- Select one idea rather than combining several unrelated concepts.
- Describe the intended user, situation, problem, and available evidence.
- Explain how the concept would work and what value you expect.
- Identify assumptions and choose the smallest test that can inform the next decision.
Keep its limits in mind
A clear concept is not proof of demand or feasibility. Avoid turning anticipated benefits into established outcomes or calling a manual test a working algorithm.
Making a daily review summary testable
Fictional example: Yunqiao has roughly a dozen review-feature ideas. The team can run one no-code test within a week. A daily summary is one candidate; the first trial would be prepared manually.
On a small screen, scroll across the diagram to read it.
Scope: The test checks whether people use the summary. It does not require developing an algorithm or establish that the concept saves time.
Evidence to collect: Record which tasks the five trial users handle with the summary. Confirm the success threshold before deciding whether to build the feature.
Next step: Agree on the observation criteria and run the manual trial before expanding development.
Three reasons an idea needs more than an attractive name
First, pause if the concept combines several problems or users with different tasks. “Smart reminders for everyone” cannot tell a reviewer what behavior to examine. Choose one person in one recurring situation and explain the difficulty. A concept sheet can be short because it makes a bounded idea explicit, not because it omits the mechanism.
Second, stop if the mechanism consists of a benefit statement. “Save project managers time” says what you hope for, not what the service would do. Describe the input, the action, what the user receives, and the work still done by people. Do not present a manually prepared summary as an implemented algorithm or assume that automating it would cost nothing.
Third, do not turn a small trial into a development commitment. A user agreeing to receive a summary has not promised to rely on it or pay for it. Participation, access to project material, observation criteria, effort limits, and the next decision all need agreement. Keep unknown success thresholds visible rather than choosing a convenient one after seeing results.
Choose the right level of detail for the next conversation
This concept sheet is a site worksheet. It connects an idea to a task and a test without claiming to be a standardized business case. Use the smallest document that can support the current decision; a polished proposal is premature if the basic mechanism is still unclear.
| Material and question | Method | Output and boundary |
|---|---|---|
| One rough idea needs a user and mechanism | Idea concept sheet | A concept and assumptions; no evidence of demand. |
| One topic needs more possible approaches | Mandala chart | Directions to explore; no winning concept. |
| An experience needs a sequence of visible moments | Storyboard | A proposed sequence; not observed usability. |
| A bounded product response needs resources and approval | Product proposal | A validation and investment request; not approved development. |
Make the daily-summary concept operationally explicit
The complete fictional Yunqiao packet contains roughly a dozen review-feature ideas and capacity for one no-code test within a week. The selected candidate is a daily summary for studio project leads managing three or more projects. It would identify reviews awaiting feedback and relevant feedback times at 9 a.m.; the first version would be prepared manually. A one-week trial with five users is proposed. No trial participation, baseline effort, success threshold, cash budget, or observed result is supplied.
The problem statement is losing track of clients who have not completed feedback. That is the concept’s motivation, not an established frequency. The hypothesized value is less checking and chasing across projects. Before producing a summary, agree the source and meaning of each timing field: a feedback deadline and the time of the latest received feedback are different facts. Do not silently populate one when the other is missing.
The testable mechanism is a human compiling agreed project records, identifying the items still pending under a stated rule, and sending the summary to an authorized lead. The lead can then decide what to check or follow up. Sending a message is not a task completed by that user, and a reply of “useful” is different from observed use. Keep a record of the manual compiler’s work as well.
| Element | Supplied idea | What to agree before trial |
|---|---|---|
| Audience | Leads with at least three projects | Actual participants, task context, and appropriate access. |
| Delivery | Daily at 9 a.m., manually prepared | Delivery days, time zone, source cutoff, and error handling. |
| Content | Pending reviews and feedback timing | Pending rule; deadline versus latest-feedback timestamp. |
| Value and test | Less checking; one week with five users | Observable tasks, comparison basis, success and exit conditions. |
Review user behavior and the work required to support it
The resulting concept asks permission for a bounded manual trial once the missing arrangements are confirmed. Define a task record that links an item in a particular summary to a user action, such as checking a pending review, contacting its owner, or deciding that no action is needed. Retain corrections and stale items. Do not count five recipients as five active users or every delivered row as a completed task.
For the proposed review, separate delivery reliability, whether users understand the entries, what they actually do with them, and the effort of producing and using the summary. A claim of reduced checking needs a comparable baseline and an adequate observation procedure; those inputs are absent here. The cost of manual preparation matters even if users spend less time searching. An eventual automated system would require its own accuracy and access checks.
If people use the summary but repeatedly correct its status, the next work may be defining the source rule rather than building automation. If they do not use it, ask whether timing, relevance, an existing alternative, or the underlying need explains that behavior. Keep the sample’s limits: a five-user plan is not a market study. Record whether to revise, stop, or request further investment, with reasons and actual approval. No trial outcome is reported.
Check your work
- A reader unfamiliar with the discussion can explain the concept.
- The user, problem, mechanism, and value hypothesis are clear.
- Manual work is distinguished from implemented automation.
- The test records observable behavior and unresolved success criteria.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.