Designer
🟢 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-planand/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:
- Read Balanced Teams — design is one of three equal disciplines, not a service
- Read Pairing Guide — designers pair too, especially cross-functionally
- Read Cross-Functional Pairing — understand PM+Designer and Engineer+Designer patterns
Working with Skillet for the first time:
- Read Skillet Overview to understand what the PM toolkit produces
- Review a
/story-writeexample to understand the story format you'll contribute to - Read Human-Agent Pairing to understand the AI workflow your PM is using