The Design Process and Agile Development: Part 2 — Collaborative Activities

The Design Process and Agile Development: Part 2 — Collaborative Activities

This is Part 2 in our blog series on how the design process works alongside the Agile methodology to produce results within an integrated team. If you haven’t read Part 1 — which lays the foundation for these practical activities that the team can collaborate on — please check that out before reading further.

Daisy Mølving

February 12, 2024

So you’re ready to tackle a new project with an integrated team of UX designers, product owners, and agile software developers. You know that success can be achieved in close collaboration between your team members, each representing deep expertise in desirability, viability, and feasibility. But which activities would be most profitable for the team to put their heads together on, and what should their responsibilities be? Here, I have laid out some common, design-progressing activities so that your team can collaborate efficiently on Finding Out, Translating, and Creating their way to a successful end product.

Design Process

Find Out — Together

Finding Out is where it all starts, but it most certainly doesn’t only happen at the start! We 'find out' in continuous cycles throughout the project, not just from our users, but also from our stakeholders, and product and development teammates. After all, though the end product may be ultimately for our end users, design is also influenced by viability (the business) and feasibility (the developers). So it makes sense to 'find out' collaboratively.

Stakeholder Interviews

Stakeholder interviews are an integral early step for determining what your stakeholders care about — their hopes and fears, past project experiences that might drive their decision-making, key metrics they need to hit, and any assumptions they may have. Not only will you build rapport, you’ll also learn how to engage your stakeholders through the design process. I’ve experienced that not all stakeholders have immediate faith in design, so understanding how they measure success and engaging with their success criteria throughout your work, can be crucial to earning their trust.

Developers must also 'find out' from stakeholders; in addition to familiarizing themselves with the existing codebase and infrastructure, they must understand organizational capabilities that would affect feasibility and timelines. Of course, it is sensible to share learnings from stakeholder interviews with your dev teammates so that they, too, can understand how to appeal to the business’ sense of success.

Competitive Analysis and Analogous Research

As domain experts, your client has an excellent understanding of their competitors. Leverage this when performing competitive analysis. Developers should simultaneously perform a competitive assessment of the tech landscape of the product domain to determine feasible options that would best realize the experience we end up defining through design and infrastructure.

What does your client believe gives their contemporaries a competitive edge? Their answer also identifies non-competing businesses that solve different problems similarly, informing analogous research. Analogous research, in turn, informs development spikes and experiments.

User Interviews and Testing

Getting a stakeholder (ideally a product owner) involved in user interviews and testing gets someone in your corner, translating user feedback to the rest of the business more compelling. However, ensure that your chosen stakeholder is well-prepped for their observer role throughout the sessions so that they do not unduly influence your users. Also, avoid inviting more than one stakeholder to any sessions where possible — the fewer overall contributors, the less intimidating it will be for your user participants. Follow up with your collaborators to discuss and download your initial impressions after each session to get everyone on board.

CI Tools for Accessibility

Is there an existing product that you're redesigning? Developers can set up automated accessibility testing tools such as axe or Lighthouse to audit current state. Are you building a green-field product from the ground up? Developers can additionally set up continuous integration pipelines with such accessibility testing tools so that there is a cycle of feedback between design and development with user needs at the center.

Axe Auditor Dash 1x
Image of Axe Auditor’s dashboard. (n.d.). Deque.

Translate — To Your Team

It is imperative that you have your teammates onside for your design endeavors, and this all comes down to alignment through your ability to Translate. Bring your team into what you learned in language that appeals to them. If translation is successful, progress can be made quickly and priorities are decided confidently based on evidence. It allows efficiency and provides motivation even through ambiguity.

Presenting Synthesis and Insights

The UX team is involved in the first step of translation: translating all your user research and feedback through synthesis. The second step of translation happens when that synthesized research is presented to the rest of the team. Consider your audience! Convey to stakeholders how insights interact with their business goals. Convey to developers how user expectations might have feasibility implications. Focus on outcomes rather than process. If a stakeholder was involved in your user interviews and/or testing, invite them to give their take on insights to bolster your translation.

Communicating Product Service

I have often found that client product teams need more adequate documentation of the service they provide — a gap resulting in team misalignment and inefficiency. Communicating the product service through a service blueprint presents not just the customer journey through a process (including where they interact with your product) but also where they interact with other actors (perhaps other users or service providers), along with the software frontend and backend infrastructure that supports it.

Therefore, it shows your team members how they each influence the product that underpins the user experience. In addition to providing clarity through product evolution, service blueprints present new opportunities for service improvements across team responsibilities.

Create — In Tandem

In order to keep 'finding out' we need to Create something to put in front of users, keeping the wheel turning towards product success. Creation outcomes could be thoughtful interview questions, wireframe concepts, generating compelling ideas, prototypes, or fully refined and branded UIs built from consistent components. Most of these outcomes benefit from team collaboration.

Interview and User Testing Moderation Guides

Use “assumptions” and metrics gathered in stakeholder interviews to inform moderation guides for user interviews and testing. Better yet, hold a workshopping session to understand what your team members really want to know from users. Examine these team concerns through your designer lens to ask open, non-leading questions that generate insightful user responses.


No one person has all the best ideas — draw from your teammates’ expertise and experiences in your ideation sessions.

  • Developers can apply what they learned from code audits, competitive assessments, experiments, and spikes to inform the feasibility of your proposed solutions.

  • Stakeholders can unlock awareness of project history before your time. A proposed solution may bring back memories of past failures that lead to design principles and constraints. These act as guardrails to help prevent similar mistakes with the latest design.

Building Prototypes

Prototypes allow teams to make ideas and concepts tangible rather than just words. Prototypes also lead to discoveries and new hypotheses. This is where the development team really shines.

Though designers are adept at creating prototypes with software such as Figma, AdobeXD, or Sketch, there are limits to the fidelity of interactions. Often, the best way to validate designs is to build prototypes in code. This also means that any successful designs are already in place for further developer iteration.

For a recent client in youth sports tournament scheduling, the UI was required to be richly interactive and highly intuitive, though it was deceptively complex to design. Dragging and dropping games across time slots while viewing relationships, conflicts, and field availability was easily sketched in Figma, but it needed to be prototyped in code in order to be user-tested faithfully. Close collaboration between design and development quickly produced concepts in code where interactions could be quickly understood and tweaked for improvement.

Creating a UI Library

To build prototypes quickly and react to feedback efficiently, UI libraries and the design systems that support them accelerate progress.

Developers can begin building (or configuring an existing) UI library in code at the start of any project, even before research is complete. A basic UI library contains the most commonly used atomic UI elements users need (e.g., a button). Competitive analysis and initial research also inform more domain-specific additions to the library. If customers expect certain UI elements or interactions because that’s what all client competitors have, it is reasonable to incorporate them for use in your prototypes. If no design system exists, keep components low-fidelity. Branding and styling can easily update as your product becomes more refined.

In a recent project with GeneDX, designers and developers collaborated to build a library of UI components that could be consumed by initial prototypes and eventually by a higher fidelity app in production. If this library is uncoupled from the app, then the infrastructure for the prototype can be as simplistic as possible and completely sacrificial. The dev team gets to work on prototypes without worrying about final infrastructure and scalability in the preliminary phases of the project. Deploying this UI library also allows for visibility from the business — early concepts can even be user-tested in this way!

Integrating the design process with Agile development ultimately expedites innovation and assures that our solutions are user-centric and capable of evolving within a dynamic market. Instead of viewing design and agile development as conflicting processes, use this opportunity to leverage the wide range of expertise within your integrated team for product success. If you’re interested in transforming the outcomes of your projects through Agile and design collaboration, please reach out for a consultation — we’d love to create something impactful together!

Daisy Mølving

Senior Designer

Daisy Mølving is a sock knitter, foil fencer, and design enthusiast. She began her career at 8th Light as a developer, before completing another apprenticeship and embracing her love of design. Daisy combines a nuanced grasp of visual styling and research skills with deep technical experience to craft designs that consider every interaction layer, from the users down to the underlying code implementations.