What does a product designer do on a small team?
Define a product designer's contribution through a workshop-booking project: framing problems, exploring behavior, coordinating constraints, documenting decisions, and examining the implemented experience.
Describe responsibilities before software skills
A product designer helps a team decide how a product should serve people within real constraints. The work can include research, interaction design, content, visual decisions, and coordination with implementation and operations. On a small arts-service team, the most useful description of the role is a set of responsibilities rather than a list of software tools.
Make decision boundaries visible
Write down who frames the problem, who speaks with participants, who owns operational rules, and who can change implementation. A designer may contribute to all of these without having sole authority over them. Make the decision boundaries visible so important questions do not fall into gaps between job titles. Place the proposed solution beside a simpler alternative and ask what extra work each one creates. Count decisions the person must make, rather than decorative elements on the proposal. A useful proposal explains its scope before commitment and its resulting responsibilities. If the design depends on someone remembering an instruction from a previous screen, move that instruction closer to the decision or remove the dependency.
Map contributions to a booking project
Use a workshop-booking improvement as a role-mapping exercise. List a designer's possible outputs: a problem statement, service questions, alternative flows, an annotated prototype, and review notes from the working product. Beside each output, identify the colleague whose expertise is needed and the decision the output should support. Keep a record of the starting conditions alongside the prototype. The same action can be easy with a familiar record and confusing with an incomplete one. Choose the record deliberately, then describe what would count as completion. Show the state immediately after the action as carefully as the initial view. A proposal that ends at the interface action cannot answer whether the person understands the result.
Close gaps between specialties
If design is treated only as the final styling stage, unresolved eligibility rules or failure states can emerge late. If the designer is expected to decide every policy and technical issue alone, the project also becomes fragile. Bring the relevant people into the decision rather than expanding a job description until it hides missing collaboration. Check whether a local fix creates a problem elsewhere. A longer explanation may clarify one choice but become clipped in another context; an extra confirmation may protect a destructive action but obstruct routine work. Carry the revision through the full example and its alternate route. Document the tradeoff explicitly so the next person modifying the design understands which behavior the change was intended to protect.
Judge artifacts by the decisions they support
Review the role map against the project's actual needs. Every artifact should support a decision or communicate behavior that another person needs to understand. Avoid measuring contribution by the number of screens produced. A small, well-explained change may be more valuable than a large presentation when it resolves the obstacle people encounter.
Worked decision
A designer can propose cancellation wording, while operations confirms the policy and implementation confirms which booking states permit the action.
References & further reading
Examples and exercises in this guide are original teaching scenarios.
