Choose one approachable problem.

Start with a task you can explain plainly

Choose a problem small enough to explore through one meaningful task. “Redesign a community service” is broad; understanding how someone finds and reserves a suitable class gives you a clearer boundary. The aim is not to invent a startup or prove a business opportunity. It is to practise making decisions and documenting their basis. You can use your own low-risk project or follow Neighbourhood Classes, the fictional community-class booking service used throughout these lessons. No research or product outcomes are supplied by this example.

Describe the need without prescribing the interface

Write the person, situation, task, and uncertainty before naming a feature. Avoid claiming that people need an app simply because you want to design one. A problem statement is a starting hypothesis until appropriate evidence supports it. Keep a separate sentence for the project’s status so a later reader will not mistake practice work for a commissioned service.

Set a manageable and safe boundary

Choose one audience context and one end-to-end task. For the running example, stop at a simulated reservation confirmation. Exclude payments, accounts, staff scheduling, and any claim that a real place has been booked. Use synthetic class details and placeholder information. Do not collect health information or other sensitive details to make the prototype feel realistic. Access information can describe the venue without asking someone to disclose a diagnosis.

• Include browsing a session, reviewing details, and reserving one place.
• Include one unavailable-session state so the scope is not only ideal.
• Keep real bookings, personal records, and operational promises out of scope.

Open an evidence-and-assumption ledger

Create four columns: statement, status, source, and next check. Use statuses such as supplied constraint, assumption, observation, and open question. In the fictional project, even the venue rules are invented constraints, not facts about a service. If you later speak to someone, preserve the context and permission boundary of their contribution. Never rewrite a convenient assumption as research because it makes the story smoother. The ledger will help you decide what can be stated confidently and what must remain provisional.

Define what you want to learn

Write a question that could change your design, such as which session details someone needs before choosing. Define the current deliverable as a concept and a plan to investigate it, not a promise to improve bookings. Set a practical stopping point: a coherent flow with documented unknowns. If participant access is unavailable, you can still complete an assumption-led case study and propose future checks. Do not create fictional interview notes, quotations, or success metrics to fill the gap. Honest limits are part of the work.