Agile for Designers

Why Designers Need to Understand Agile

If you work at a tech company or startup, chances are the team runs on Agile. The problem is that Agile was originally designed for developers — the original Manifesto was written by developers, for developers. Designers were not part of the picture.

This created a real gap. Many designers feel they don't know how to adapt to sprints, ceremonies, and the way teams operate. The result: either the designer works in isolation from the team, or they try to rush to keep pace with development without giving design the time it deserves.

But the truth is that when Agile is applied correctly, it's the best possible environment for a designer. Rapid iteration, continuous feedback, and a focus on the user — all of this aligns with the principles of good design.

In this article we'll understand Agile from the designer's perspective and learn how to work effectively in Scrum and Kanban teams.

The Agile Basics You Need to Know

Agile is not a single methodology — it's a philosophy with different manifestations. But there are common fundamentals:

The Four Values (Agile Manifesto):

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a fixed plan

Key Principles for Designers:

• Iteration: everything doesn't have to be perfect the first time. Design, test, learn, repeat.
• Continuous delivery: deliver usable work frequently. Weeks, not months.
• Collaboration: designers aren't in an ivory tower. Be part of the team daily.
• Simplicity: the shortest path to value is the best one. Don't overcomplicate solutions.

Scrum: The Most Popular Framework

Scrum is the most popular Agile framework, and most teams use it or a modified version of it.

Roles in Scrum:

• Product Owner: responsible for the product vision and prioritization. The designer works closely with them.
• Scrum Master: responsible for keeping the process running smoothly. Solves problems and removes blockers.
• Development Team: the team that builds the product — this must include the designer.

The Sprint:

A Sprint is a fixed work period (typically two weeks) in which the team works on a defined set of tasks. Each Sprint has a clear goal and ends with a deliverable increment.

As a designer in a Sprint:

The biggest challenge is that design needs to be ready before developers start building. This creates what's known as "Dual Track" — the designer works on the next Sprint while developers are building the designs from the previous Sprint.

Ceremonies: The Important Meetings

Sprint Planning

At the beginning of each Sprint, the team meets to decide what to work on.

The designer's role:

• Present ready designs and explain the related user stories.
• Clarify any interaction details or edge cases.
• Help estimate effort — if the design is complex, make that clear.
• Make sure the team understands the full user journey, not just a single screen.

Daily Standup

A short daily meeting (15 minutes) where everyone says: what they did yesterday, what they'll do today, and what their blockers are.

The designer's role:

• Share design updates even if they're minor.
• If a developer has a design question, this is the right time.
• If there's a blocker (e.g., waiting for a decision from the PO), mention it here.
• Don't drag it out. 1–2 sentences is enough.

Sprint Review (Demo)

At the end of the Sprint, the team presents what they built to stakeholders.

The designer's role:

• Present new designs that haven't entered development yet.
• Explain design decisions and the user research behind each one.
• Gather feedback and take notes.

Sprint Retrospective

The team reviews the process: what went well and what needs improvement.

The designer's role:

• Speak honestly about challenges. If you feel design isn't getting enough time, say so.
• Suggest practical improvements. For example: "We need a design review before development."
• Listen to developers' problems. If your designs are hard to implement, that's important feedback.

Kanban: The Flexible Alternative

Kanban is a simpler system than Scrum. There are no fixed Sprints — work flows continuously.

How Kanban Works:

• There's a board with columns representing stages of work: To Do, In Progress, Review, Done.
• Each task is represented by a card that moves from column to column.
• There's a Work-In-Progress (WIP) Limit for the number of tasks in each column. This prevents the team from starting too many things without finishing them.

Why Kanban Sometimes Suits Designers:

• Flexibility: no sprint deadline pressure. You can take the time each task needs.
• Clarity: you can see all your work and the team's work at a glance.
• Flow: the focus is on completing tasks, not starting new ones.

A Kanban Board for Designers:

You can create a board just for yourself:

• Backlog: all the tasks you need to do
• Research: tasks you're researching
• Design: tasks you're actively designing
• Review: waiting for feedback
• Ready for Dev: ready to hand off to developers
• Done: complete and delivered

Dual Track Agile: The Solution for Designers

One of the biggest challenges is that the designer needs to be ahead of development. The solution many teams use is Dual Track Agile.

The Idea:

The team works on two parallel tracks:

• Discovery Track: the designer and PO do research, design, and validation for upcoming features. This happens one or two Sprints ahead.
• Delivery Track: developers build features that the designer has finished and validated.

In the Discovery Track:

• User research and interviews
• Wireframe and prototype design
• Usability testing
• Defining requirements with the PO

How to Organize the Dual Track:

• Dedicate 60–70% of your time to Discovery (designing upcoming features).
• Dedicate 30–40% to supporting Delivery (answering developer questions, reviewing implementation).

Working with Developers in an Agile Environment

The relationship between the designer and developer is the most important relationship on the team. When it's strong, the product comes out significantly better.

Practical Tips:

Handoff: don't just send a Figma link. Sit down with the developer and walk through the design: the interactions, the states, the edge cases, and the responsive behavior.

Design Specs: document spacing, colors, and fonts clearly. Use Figma Dev Mode or Zeplin.

Be flexible: if a developer tells you something is hard or expensive to implement, be willing to find an alternative solution that achieves the same goal in a simpler way.

Do a Design Review: after the developer finishes the implementation, review it against the original design. Small differences can affect the user experience.

Learn the basics of code: you don't need to be a developer, but understanding the basics of HTML/CSS and technical limitations greatly improves communication.

Agile Tools for Designers

For Project Management:

• Jira: the most popular in Agile teams. Learn how to use it and keep your tickets updated.
• Linear: newer and cleaner than Jira. Widely used in startups.
• Asana/Monday: simpler alternatives if the team doesn't need Jira's complexity.

For Collaboration:

• Figma: not just a design tool — use comments and dev mode to collaborate with developers.
• FigJam/Miro: for workshops, brainstorming, and retrospectives.
• Slack/Teams: daily communication. Create a dedicated channel for design.

For Documentation:

• Notion/Confluence: for documentation. Document design decisions and research findings.
• Loom: to explain designs via video. Faster than writing long documentation.

Common Challenges and Solutions

"Design can't keep up with the Sprint":

This is the most common problem. The solution: work one or two Sprints ahead. If the team is implementing Sprint 5, you should be designing Sprint 6 or 7.

"The developer changed the design":

Make a design review mandatory before the merge. And write clear acceptance criteria in the ticket.

"The PO changes priorities every day":

Bring it up in the retrospective. Explain that constant change affects design quality. Suggest that priorities be locked for at least the duration of the Sprint.

"There's no time for research":

Do lightweight, continuous research. You don't need a big study every time. 30 minutes with one user is better than nothing. And use the data available from analytics and support teams.

"The team doesn't value design work":

Present your work in the Sprint Review. Explain the impact. Show the difference between the first design and the design after research and iterations.

Final Advice for Designers in an Agile Environment

Agile is not a rigid system — it's a flexible philosophy. The most important thing is to be an active part of the team, not just "the designer who sends Figma files." Attend the meetings, participate in discussions, and ask questions. Stay proactive and suggest improvements. And remember that the ultimate goal is the same: build a product that serves the user. When you focus on that goal, you'll find that collaboration with the team becomes easier and more enjoyable.