How to make Human-Centered Design work in agile teams

Agile methods and human-centered design (HCD) both promise better products. But integrating the two often feels harder than it should. Many teams want to put users first, but the reality of sprint schedules and shifting priorities gets in the way. Is it possible to combine the strengths of both, without letting either fall through the cracks?

This article introduces the Human-Centered Agile Workflow (HCAW) — a practical framework that blends HCD and agile for today’s cross-disciplinary, often remote teams. We first shared the HCAW model in detail at the AHFE Conference, presenting our approach and field insights to the international research community.

The Problem: Agile and HCD Pull in Different Directions

Modern software teams need to move fast, deliver frequently, and respond to change. Agile frameworks, especially Scrum, are good at this. They break work into small increments and encourage constant adjustment.

Yet, HCD requires something else: deep user research, creative ideation, and iterative prototyping, often before development begins. In many teams, these activities are sidelined or squeezed into already-packed sprint cycles.

Practitioners notice the gap. Studies show that the influence of human-centered approaches on agile projects averaged only 4 out of 7, where 7 means “great influence” [4]. Teams want to focus on users but struggle to keep up with the agile pace.

“We know users matter, but the process makes it hard to actually involve them consistently. The sprint rhythm always wins.”

What HCAW Changes

The Human-Centered Agile Workflow (HCAW) tackles this integration head-on. It offers a way for teams to:

• Apply HCD principles fully, not as an afterthought [5]
• Seamlessly connect business, design, and development activities
• Support interdisciplinary, distributed teams (including remote work)

HCAW is designed for real project constraints — limited time, changing requirements, and teams who rarely share the same office.

How HCAW Works

Two Levels of Iteration

HCAW introduces two “gears” for work:

• Cycles: Larger planning and conception units (often a release or big feature)
• Sprints: The standard short, iterative development intervals from Scrum

This structure allows research and ideation to lead, while development keeps pace.

Sprint 0: Laying the Groundwork

Each cycle starts with a Sprint 0, split into two parts:

• Cycle Conception: Teams clarify the business problem and user context together. Researchers conduct studies and share findings as an Insight Report.
• Co-Creation Workshop: Designers, developers, and other team members co-create solutions. Early prototypes are built and tested. Feedback loops ensure ideas are grounded in real user needs.

After this, the team plans the sprint backlog, with business, design, and development aligned.

Parallel Tracks

Every sprint, two tracks run in parallel:

• Implementation: Development teams deliver the current sprint’s features.
• Conception: At the same time, teams explore, prototype, and validate ideas for the next sprint.

This approach ensures that by the time development starts, requirements have been informed by recent user insights and refined prototypes.

“The co-creation workshops made a huge difference. Everyone’s voice was heard — not just the loudest. We caught issues early instead of finding out too late.”

Built for Remote and Distributed Teams

HCAW does not require co-location. In our own projects, most teams were remote or split across locations — like 82% of agile projects today [7]. The workflow was designed with this in mind: meetings, workshops, and handoffs all support distributed collaboration.

What We Observed in Practice

After applying HCAW in several service design and development projects, we noticed three patterns:

1. Users Stay Central: User research is never skipped or shortened. It is built into the process, not tacked on.
2. Cross-Disciplinary Teams Work Together: There are shared ceremonies and artifacts; business, design, and development speak the same language.
3. Responsiveness Improves: Teams adapt to change more easily, but don’t lose sight of what users need.

“We were able to keep up with changing priorities, but this time, our design decisions were based on real user insights — not just gut feelings.”

How to Adopt HCAW

If your team wants to try this approach, consider these practices:

• Start every cycle with shared user research and context setting.
• Use co-creation workshops to bring in multiple perspectives early.
• Run design and development activities in parallel, but keep the outputs connected.
• Schedule regular retrospectives focused on the process itself, not just the work.
• Plan for distributed collaboration — document decisions and make workshops remote-friendly.

What’s Next

Our initial experience with HCAW is promising. We’re expanding our study to larger and more varied teams, including those working fully remote. Future research will explore the model’s limits and adaptations.

Your Turn:
How do you balance agile delivery with deep user research in your work? Which practices help (or hinder) your efforts to keep design human-centered?
Share your thoughts in the comments — we’re eager to learn from your experiences.

You can read the full conference paper introducing HCAW on ResearchGate.

References

1. Chang, C., et al.: Time-line based model for software project scheduling with genetic algorithms. Inf. softw. Technol. 50, 1142–1154 (2008). Elsevier, USA
2. Coverity: The Software Development Challenge. Coverity, San Francisco (2006)
3. Brown, T.: Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperCollins, New York (2009)
4. Nielsen Norman Group: Effective Agile UX Product Development. (2017)
5. International Organization for Standardization: DIN EN ISO 9241–210 Human-centred design for interactive systems. (2010)
6. Beck, K., et al.: Manifesto for Agile Software Development. Addison-Wesley, Reading (2001)
7. VersionOne: The State of Agile Report. (2016)
8. Brown, T.: Design thinking. In: Harvard Business Review (June 2008), pp. 87–92. Harvard Business Publishing (2008)
9. Camacho, M.: David Kelley: From design to design thinking at Stanford and IDEO. In: She Ji: The Journal of Design, Economics, and Innovation, vol. 2, issue 1, pp. 88–101. Tongji University Press, Shanghai (2016)
10. Plattner, H. et al.: , Design Thinking. In: mi-wirtschaftsbuch. Munich (2009)
11. Gibbons, S.: Design Thinking 101. https://www.nngroup.com/articles/design-thinking/ Retrieved 6 March 2017
12. Waloszek, G.: Introduction to Design Thinking. https://experience.sap.com/skillup/introduction-to-design-thinking/ Retrieved 6 March 2017
13. Knapp, J., et al.: Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon and Schuster, New York (2016)
14. Collier, K.: Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Addison-Wesley, USA (2011)
15. Gothelf, J., et al.: Lean UX: Designing Great Products with Agile Teams. O’Reilly Media, Sebastopol (2016)
16. Rubin, K.: Essential Scrum: A Practical Guide to the Most Popular Agile Process. Addison-Wesley, USA (2012)
17. Jongerius, P., et al.: Get Agile!: Scrum for UX. Design and Development. BIS Publishers, The Netherlands (2013)
18. Brown, D.: Agile User Experience Design: A Practitioner’s Guide to Making It Work. Morgan Kaufmann, San Francisco (2012)
19. Ries, E.: The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. Random House, New York (2011)
20. Gothelf, J.: Lean vs Agile vs Design Thinking: What you really need to know to build high-performing digital product teams. Gothelf Corp, Glen Rock (2017)
21. Jarrell, J.: Stories versus Themes versus Epics. https://www.scrumalliance.org/community/articles/2014/March/stories-versus-themes-versus-epics Retrieved 6 March 2017