Day-to-day operating brief
What Product Designer work looks like in practice
A Product Designer works across problem discovery, user flows, interaction and visual design to shape a digital service from concept to release. The role collaborates with product, engineering, research and commercial teams, often handling prototypes, participant insight, analytics and unreleased roadmap information. Terms should define product areas, design systems, research permissions, accessibility standards, source tools, approval authority, experiments, customer data, remote equipment, intellectual property, portfolio use and responsibility for supporting implementation without owning technical release decisions.
Responsibilities reflected in the contract
- Investigate product and user needs.
- Create flows prototypes and interface designs.
- Maintain approved design-system patterns.
- Test accessibility and usability assumptions.
- Document decisions and support implementation.
A realistic working scenario
A commercial stakeholder requests a checkout change that could confuse users and weaken accessibility. The designer documents the evidence and trade-offs, then follows product approval rather than silently implementing the request.
Outputs to agree
- evidence-led product designs
- consistent accessible interaction patterns
- clear development-ready handovers
Records and evidence
- Problem brief evidence and constraint.
- Flow prototype test and iteration.
- Component accessibility and approval.
- Handover implementation review and outcome.
- Design files.
- Project briefs.
Reporting relationship
Typically reports to Creative Director, Design Lead, Account Director or Project Manager. Confirm the employer's actual reporting structure in the builder.
Authority and escalation
- The designer cannot expose participant data, promise roadmap delivery, approve engineering release or publish confidential work without authority.
- Obtain approval before committing expenditure, changing contractual commitments or making regulated or staffing decisions outside the assigned role.
Tools and systems
- Design software.
- Project management tools.
- Approval systems.
- Client communication tools.
Workplace context
- Office, studio, remote systems, client meetings or approved project locations.
Contract priorities
- products users and collaboration remit
- research data prototypes and experiments
- design systems accessibility and tools
- approvals IP portfolio and handover
Information the employer should prepare
- the products and user groups
- the research and data permissions
- the design tools and system ownership
- the accessibility and approval standard
- the IP portfolio and handover rules
Individually written and reviewed against the maintained role record.