# SIDE A / musician usability session

Status: prepared, not conducted. This document contains no participant findings.

## Decision to make

Does an independent musician understand how to turn a finished song into a prepared release without someone explaining the interface? Use the observations to decide what to simplify next.

## Who to invite

Three to five independent musicians who have prepared a single or short EP. Include someone doing it for the first time and someone with a previous release. Invite them only with the portfolio owner's approval; no invitations have been sent.

Allow 25 minutes each. Explain that the design is being tested, not the person. Ask permission before recording, offer an unrecorded session, and use anonymous participant codes in notes. Do not ask for passwords, distributor accounts, unreleased recordings or private client information. The fictional sample is enough for the core session.

## Opening prompt

“You have finished two songs and want to prepare a release. Explore this workspace as you would on your own. Please say what you are looking for and what you expect to happen. Your changes stay on this device. You can stop whenever you want.”

Do not explain the sleeve, filters or checklist first. Record their first interpretation of the screen.

## Tasks (read the goal, not the interface labels)

1. Find out what still needs to be added to Blue Hour. Ask what they believe ‘prepared’ means here.
2. Add a fictional songwriter to Warm Light and mark it as having no explicit lyrics. Observe whether they expect the other credits or audio to change.
3. Find the next piece of work due. Ask what they would do if it were overdue.
4. Mark that piece of work complete. Observe whether they can identify what is now next. Ask them to find the completed task again.
5. Move release day one week later. Before saving, ask what will change and what will stay done. Compare their answer with the preview.
6. Download a release pack. Ask what they expect it to contain, whether it has been sent to a distributor, and how they would keep a copy.

Optional own-release task: create a release with invented names and participant-chosen, non-sensitive test files. Let the participant choose files themselves. File selection and persistence must be verified before claiming that import works end to end. Do not use the session to work around a declined upload permission.

## Observation sheet (one copy per participant)

Participant code: ___  Experience preparing releases: ___  Device: ___

| Task | Completed without help / with help / not completed | Time to first useful action | Hesitation, wrong turns or errors | Exact quote (with consent) |
| --- | --- | --- | --- | --- |
| Missing details | | | | |
| Songwriter and lyrics | | | | |
| Next task | | | | |
| Complete and recover task | | | | |
| Change date | | | | |
| Export and explain pack | | | | |

After each task ask: “How easy or difficult was that, from 1 (very difficult) to 7 (very easy)?” Do not turn a small sample into population percentages.

## Close

- What would you use instead today?
- What felt unnecessary or unclear?
- Is anything essential to preparing your release missing?
- Would you keep using this after the first release? Why?

## Synthesis and next change

Group observed problems by consequence: prevents completion, causes a wrong decision, slows the task, or cosmetic. Prioritize repeated completion problems over feature requests. Write each finding as an observed event, the affected task, evidence and a proposed change. Distinguish participant quotations from the designer's interpretation. Retest the changed task before claiming improvement.

No participant results, completion rates or testimonials may be added to the portfolio until sessions have actually happened.