Understanding the Work
Before choosing concepts or controls, find out what the work requires. A list of requested features is useful, but it will not tell you why an artist changes approach halfway through a task, which information they must preserve, or what a colleague needs to continue the work.
Observe people working on real projects, with their usual assets, equipment and other applications. Ask them to explain decisions when it will not disturb a delicate operation. A demonstration of the official workflow is only a starting point: watch for preparation, repeated checks, workarounds and interruptions.
Recruit for the Work You Need to Understand​
Separate three things when choosing participants:
- Domain experience: understanding animation, modelling, compositing or another discipline.
- Application fluency: familiarity with this particular tool and its conventions.
- Working circumstances: role, project scale, hardware, access needs and responsibility for other people's work.
An experienced animator learning a new application is not a novice animator. Someone who knows every menu may still be learning the craft. Include returning users and people who use only a narrow part of the product; their work may be highly skilled.
Follow a Task Beyond the Application​
Choose a recent piece of work and trace it from brief to delivery. Record the materials received, decisions made, alternatives tried, checks performed and outputs handed over. Include the conversations, reference documents and other tools that make the task possible.
Keep a short record for each observed task:
| Record | Questions to answer |
|---|---|
| Purpose and acceptance | What makes the result good enough? Who decides? |
| Inputs and dependencies | Which assets, versions, settings and permissions are required? |
| Decisions and alternatives | Where can the approach change? What must remain editable? |
| Enabling work | What preparation or checking supports the creative work? |
| Interruptions and handoff | What must someone remember or explain to resume? |
| Evidence | What was observed, what was reported, and what remains uncertain? |
Do not treat every workaround as waste. A separate reference board may support comparison better than an integrated panel. Investigate what it contributes before replacing it.
Turn Observations into Design Requirements​
Write requirements in terms of work, with the observation beside them. “Reviewers need to identify which version a comment concerns” is more useful than “add comments”. Describe an ordinary case, a difficult case and a change of plan. Carry these through conceptual design, then test them with users.
Practical check: ask a colleague to reconstruct the task from your notes. If they cannot identify its success criteria, dependencies and handoff, gather more evidence before settling the interface.