# Customer-task interview and app brief Use this worksheet to understand one real task before choosing features. Obtain permission to take notes; let the participant skip private information. Empty or redacted examples are enough for an early conversation. Do not collect passwords or sensitive customer records here. ## 1. Set up the conversation - Date: - Interviewer: - Participant role (use a label rather than unnecessary personal details): - Task they actually perform: - Who decides whether to adopt a new tool: - Permission to take notes and agreed use of those notes: - Where notes are kept and when they will be removed: Opening to adapt: > I am exploring how this task works today. Could you walk me through the last time you did it? I am here to understand the process, not to sell you a finished app. Please leave out anything private. ## 2. Follow the last occurrence 1. What happened that made you start the task? 2. What did you do first, and what happened next? 3. Which people, messages or tools did you need? 4. Where did you wait, repeat work or ask for help? 5. What happened when the usual process did not work? 6. How did you know the task was finished correctly? 7. What would make changing the current process difficult? Useful follow-ups: “What happened next?” “Can you show a harmless example?” “Who makes that decision?” Avoid introducing a feature before you understand the process. | Step | Person acting | Information or tool needed | Handoff / wait / error | Evidence or open question | | --- | --- | --- | --- | --- | | Trigger | | | | | | First action | | | | | | Next action | | | | | | Decision | | | | | | Finished result | | | | | | Exception | | | | | ## 3. Keep the evidence distinct | Note | Type: said / shown / assumption / unknown | Source or harmless example | Follow-up needed | | --- | --- | --- | --- | | | | | | | | | | | | | | | | - Reported frequency (label estimates): - Reported time or cost (not measured unless actually measured): - Existing workaround and what already works well: - Simpler process change worth trying: - Adoption decision, buyer and constraints: - What the participant corrected when you played the task back: Task sentence: > When __________ happens, __________ needs to __________ so that __________. ## 4. Turn the task into a small app brief - First user and job: - Other people who must act: - One record to create or update: - Minimum fields: - Who may see each record: - Who may change it: - Statuses and allowed decisions: - What remains unchanged while a decision is pending: - Which record fields change for each accepted, declined or cancelled outcome: - What the user sees when the task is finished: - What must survive refresh and sign-in: - Important exception or failure: - Integrations or provider setup still required: - Features deliberately outside this first version: Passing exercise: > Given __________ sample data and __________ account, the participant can __________. After __________, they can correctly identify __________ without my explanation. For the guide's appointment example, keep the original time while pending. Accepting sets the requested time as confirmed in the sample record; declining retains the original time. Test both decisions with separate requests, then check the confirmed times after refresh and sign-in. Use fictional records first. Do not connect real calendars, send messages, charge anyone or change customer records merely to demonstrate the idea. ## 5. Plan an observed sample task - Goal given to the participant: - Prototype version and date: - Sample accounts/data: - Actions completed: - Errors or hesitation observed: - Help given by the facilitator: - Participant comments (separate from observations): - Result: passed / failed / not tested: - Change to make and task to repeat: ## 6. Decide whether a live pilot is appropriate - Required access, saved-data and launch checks completed: - Invited, consenting participants: - Agreed duration: - Permitted data: - Support owner/contact: - Existing process to fall back to: - Costs and manual work explained: - Success criterion defined before starting: - Stop condition: - Actual results (leave blank until observed): - Remaining unknowns: Decision: clarify the problem / test a simpler process / build or revise the smallest flow / prepare a bounded live pilot. - Why this is the next step: - Owner: - Next action and date: One conversation or completed task does not establish market demand, revenue or a conversion rate. Record what happened and use it to choose the next useful test. Guide: https://www.overskill.com/learn/validate-an-app-idea-with-a-customer