Apply the full IRSRI data-to-decision model to design a responsible performance tool. The goal is not to build production software in two hours. The goal is to create a coach-grounded product plan with a clear decision, useful data, understandable output, privacy safeguards, and a testable definition of success.
Do not begin with a dashboard or an AI feature. Begin with a user and a repeated problem:
Who uses the tool—athlete, coach, parent, official, or clinician?
What decision are they trying to make?
What information do they currently lack?
What action should become easier or safer?
What must the tool never claim?
Study the course tools as patterns. APOPT Watch converts activity files into training questions and planning context. rslts organizes longitudinal athlete evidence. The MCP connection supports specific natural-language questions. Heart Diagnostics separates signal quality, descriptive physiology, and screening. Sport-specific form apps constrain the workflow to relevant phases, while the Canvas supports custom protocols.
Use this minimum architecture:
Input → Quality check → Derived evidence → Uncertainty → Athlete-facing action → Reassessment
Every output should answer “What should the coach do next?” without pretending the data is more certain than it is. Include plain-language explanations and a route for athlete feedback.
0–15 minutes — Problem statement. Interview or imagine one specific user. Write the job-to-be-done and the current workaround.
15–35 minutes — Workflow. Draw the current workflow and the proposed workflow. Identify where time, confusion, missed context, or unsafe interpretation occurs.
35–55 minutes — Data design. List required inputs, optional context, data quality checks, derived measures, and information the tool should not collect.
55–75 minutes — Output design. Sketch one primary screen or report. Include a finding, evidence, uncertainty label, recommended action, and reassessment point.
75–95 minutes — Safeguards. Define consent, de-identification, storage, access, deletion, age-appropriate design, non-diagnostic language, and escalation.
95–120 minutes — MVP test. Define the smallest useful version, three acceptance tests, one failure test, and a five-user pilot plan.
App name and one-sentence purpose.
Primary user and coaching decision.
Current and proposed workflows.
Data inputs and quality checks.
Derived insights and uncertainty.
Athlete-facing output and action.
Privacy, safety, and scope safeguards.
MVP, acceptance tests, and pilot plan.
Prompt 1: “Act as a skeptical coach-product reviewer. Challenge this performance-app plan for unclear user need, unnecessary data collection, false precision, weak athlete action, and missing reassessment.”
Prompt 2: “Create a threat and misuse review for this app. Include privacy leakage, invented AI claims, medical overreach, biased comparison, low-quality sensor/video input, and an athlete misunderstanding the output.”
Prompt 3: “Turn my app plan into five test scenarios: normal use, missing data, contradictory athlete feedback, misleading sensor/video input, and a safety escalation. Ask me to predict the correct product behavior before revealing your critique.”
Prompt 4: “Interview me as a product owner. Ask one question at a time until the MVP has a specific user, decision, input, quality gate, output, action, and measurable acceptance test.”
Submit a 2–4 page app plan or equivalent visual brief with the eight required sections. Include one screen sketch, one end-to-end example, the AI critique, and the revisions you accepted or rejected with reasons.
Which athlete or coach decision is the app designed to improve?
What data is required, and how will the app detect missing, low-quality, or incomparable inputs?
Which insight will be shown, what uncertainty accompanies it, and what must the app never claim?
What action should the athlete or coach take, and when will they reassess whether it helped?
Which privacy safeguard, scope boundary, and acceptance test are essential before a pilot?