Designer

IntermediateTemplate6 min

🟢 Required

Use this when: You're a designer at Artium and want to understand your role in the iteration cycle — or when you're a PM or engineer wanting to understand what designers need from you.


The designer's job

Designers own the user experience. They research, prototype, and validate — embedded in the team, not upstream of it.

You conduct user research, design interactions and visuals, prototype and validate before build, participate in all ceremonies, and pair with PMs and engineers. Your job is to make sure the team ships software that users can actually use — and to flag when it won't.


Core responsibilities

  • User research. Talk to users. Test with users. Don't design in a vacuum.
  • Interaction and visual design. Flows, wireframes, high-fidelity mockups — whatever the story needs.
  • Prototype and validate before build. Don't wait for engineering to discover a UX problem. Validate flows before stories enter the iteration.
  • Participate in all ceremonies. IPM, standup, demo, retro. You're not a service provider — you're a team member.
  • Pair with PM and engineers. Co-create stories with the PM. Pair with engineers during UI implementation. See Cross-Functional Pairing.

What designers do NOT do

  • Throw mockups over the wall. Handoff without pairing creates rework. Pair during implementation, not just during handoff.
  • Work in isolation for weeks. If you're designing without showing work, you're accumulating risk. Share early, share often.
  • Own the backlog. The PM owns scope and priorities. You own the experience. Influence priorities, but don't compete for the backlog.
  • Skip ceremonies. IPM needs your input on design readiness. Retro needs your perspective on process. Demo needs your eye on UX quality.

Working one iteration ahead

While the team builds iteration N, you're designing for iteration N+1. This means:

  • Monday (IPM): Confirm design readiness for committed stories. Flag any story that needs design work before engineers can start.
  • Tue–Thu: Split your time — review in-progress UI work with engineers (iteration N) and prepare designs for upcoming stories (iteration N+1). Conduct user testing when possible.
  • Friday: Contribute to demo narratives — help frame the UX story, not just the feature story. Participate in retro. Review design implications of retro action items.

If design isn't ahead, engineers will block on design. This is the most common designer-caused bottleneck. If you're falling behind, flag it in standup — don't let the team discover it in IPM.

For the full weekly breakdown, see Weekly Iteration Rhythm.


What designers need from PMs

  • User personas with real context. Not just "admin" — who is this person, what do they care about, what frustrates them? If personas don't exist, ask the PM to create them or pair on it.
  • Access to users for research and testing. The PM should facilitate user access — scheduling interviews, arranging testing sessions, navigating client relationships to make research happen.
  • Involvement in story writing. Don't just review stories — co-create them. The best AC for UI stories includes design context that only you can provide.
  • Time in the iteration for design exploration. Not every design decision can be made in 30 minutes. The PM should account for design work in iteration planning.

See PM role guide for the PM's full responsibilities.


What designers need from engineers

  • Early feedback on technical feasibility. Before you invest in a complex interaction pattern, check with engineering. A 15-minute conversation can save days of rework.
  • Implementation that matches design intent. When the build diverges from the design, pair to resolve it — don't silently compromise. See Cross-Functional Pairing: Engineer + Designer.
  • Honesty about what's hard vs. what's impossible. "Hard" means it takes more effort. "Impossible" means it requires architectural changes. You need to know the difference to make good trade-offs.

See Engineer role guide for the engineer's full responsibilities.


AI workflows

AI tools are entering the design workflow. The same human-agent model applies: the tool drafts, you decide.

Task AI tool role Designer role
Rapid prototyping (Figma Make) Generate layout and component options Evaluate against user needs, refine, iterate
Research synthesis Organize and theme interview notes Validate interpretations, add context the AI missed
Design review facilitation Generate structured feedback prompts Guide the conversation, prioritize feedback
Content and copy Draft UI copy, error messages, empty states Edit for voice, clarity, and user context

Skillet's current scope is PM-focused. Design-specific AI tools are an active area — contribute patterns you discover on engagements.

For AI concepts, see AI Foundations.


How designers interact with Skillet

Designers don't run PM skills, but you inform and consume Skillet output:

  • /story-write — Contribute acceptance criteria for UI stories. Your design context makes the AC testable and buildable.
  • /demo-prep — Help frame the demo narrative. The best demos tell the user story, not just the feature story.
  • /story-review — Catch missing design references, incomplete UI criteria, and stories that need design input before build.
  • /retro-plan and /retro-synthesize — Contribute observations about design process, pairing quality, and user feedback loops.

Anti-patterns

Anti-pattern Why it fails Fix
Designer-as-decorator Brought in after stories are written to "make it pretty." UX problems discovered too late to fix cheaply. Involved from the start. Co-author stories. Validate flows before build.
Pixel-perfect handoff without pairing Engineers misinterpret intent. Multiple rework cycles. Frustration on both sides. Pair during implementation. 15 minutes at story start prevents hours of rework.
Working in isolation Designing for weeks without showing work. Assumptions accumulate. Big reveal fails. Share work in progress. Get feedback early from PM and engineers.
Skipping user research Designing based on assumptions instead of evidence. Ships features users don't want or can't use. Talk to users. Even 3 interviews is better than zero.
Designing too far ahead Three iterations of design ready but none validated. Requirements shift, design work is wasted. Stay one iteration ahead, not three. Validate before investing in detail.

How to prepare

New to design at Artium:

Working with Skillet for the first time:

  • Read Skillet Overview to understand what the PM toolkit produces
  • Review a /story-write example to understand the story format you'll contribute to
  • Read Human-Agent Pairing to understand the AI workflow your PM is using