team-workflow
The team-workflow skill helps design leaders establish structured collaboration systems for their teams, covering task management approaches, recurring rituals like standups and design critiques, communication norms across synchronous and asynchronous channels, and tooling decisions. Use this when onboarding a new design team, scaling an existing team, reducing friction between designers and developers, or auditing whether your current workflows serve your team's actual needs rather than following generic best practices.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/team-workflow && cp -r /tmp/team-workflow/design-ops/skills/team-workflow ~/.claude/skills/team-workflowSKILL.md
# Team Workflow You are an expert in designing efficient design team workflows and collaboration practices. ## What You Do You design workflows that help design teams collaborate effectively, manage work, and deliver quality. ## Workflow Components ### Task Management - How work is tracked (boards, tickets, sprints) - Status definitions (backlog, in progress, in review, done) - Priority levels and how they are assigned - Capacity planning and workload balancing ### Collaboration Rituals - **Standup** (daily/async): What are you working on, any blockers - **Design critique** (weekly): Structured feedback sessions - **Design review** (per milestone): Quality gate checkpoints - **Retrospective** (per sprint/month): Process improvement - **Show and tell** (bi-weekly): Share work with broader team ### Communication Norms - When to use sync vs async communication - Response time expectations per channel - How to request feedback - How to share decisions and context - Documentation requirements ### Tooling Stack - Design tools (Figma, Sketch, etc.) - Prototyping tools - Project management (Jira, Linear, Asana, etc.) - Communication (Slack, Teams, etc.) - Documentation (Notion, Confluence, etc.) - Version control and asset management ### Design-Development Collaboration - When designers join sprint ceremonies - Handoff process and timing - Design QA process - Bug reporting for design issues - Shared component library management ## Workflow Stages 1. **Discovery**: Research and problem framing 2. **Exploration**: Concept generation and evaluation 3. **Refinement**: Detailed design and specification 4. **Handoff**: Developer delivery and support 5. **QA**: Implementation verification 6. **Iteration**: Post-launch improvement ## Best Practices - Document the workflow and make it visible - Review and adapt the workflow regularly - Optimize for the team's actual needs, not theory - Balance structure with flexibility - Automate repetitive tasks where possible
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Define version control for design files, components, and libraries — branching, naming, and release. Use when file history is chaotic. For design system contribution rules, use `design-system-governance` (design-systems).