We have several cross-functional agile teams in different locations working on products that aggregate up to 2-3 solutions. Are there any examples of how companies manage a consistent UX across such teams? A style guide is a good start, but how do you empower cross-functional agile teams the same time as managing consistency of UI/UX design and driving forward new design. Can you separate responsibility from accountability? How do companies like Adobe manage this? Thoughts and feedback gratefully accepted.

2 Answers 2


I am a UX designer on an agile project that manages a suite of applications for higher education institutions. We are composed of 5 delivery teams and a handful of core teams that support their work (analysis, UX, services). Each of the 5 teams has a dedicated UX designer who who, within the sprint structure, implements the design standards set within the core UX team. The tools we use to manage implementing UX best-practices across teams in a consistent way include:

  • A style guide/pattern library that contains examples of the elements we have used across products. This serves to ensure styles are consistent, and that we are using the same widget similarly across applications.
  • Weekly meetings of the Core team with all of the UX designers. In these meetings we share our work and critique. These generally informal meetings allow us to see how other designers are tackling issues and can lead to an awareness of creeping inconsistency, or likewise, help us base our designs on the work of our peers in their apps.
  • Lots of Skype conversations! As is desirable in Agile environments in general, we rely heavily on informal communication channels to ask questions, share insights, and raise concerns about the way we do things. This is generally where the push for improvements begin, and is the first step towards identifying and fixing issues.

While I could hardly say we are perfect in our processes, it has served us pretty well in working as a coordinated, yet autonomous, UX team and our applications are always moving closer together and improving(as evidenced in usability testing).


Tough question - without one-true-answer which probably means the moderators will be jumping on this in a second. But assuming I can type fast enough to be useful...

The advice that Jeff Patton gives in this piece is pretty much spot on. It's an old post, but a good one. The only one I'd niggle with is the advice about dual track approaches... but that's a separate essay answer in-of-itself. http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html

What I've seen to be most effective is to have embedded UX folk in each team, rather than having a centralised group. There's just too much overhead in an agile process to have UX working separately most of the time. When it does UX becomes the bottleneck, and then often becomes ignored or bypassed.

The upsides of embedded UX that I've seen are:

  • Much more buy in on the value of UX by the whole team. People are more exposed to the work that goes into it and more readily see the pay off you get from doing it well.

  • You get to focus on a particular problem and can more effectively go deep. By being around during development you also get the opportunity to do much more opportunistic research work - and turn research into a continual ongoing process, rather than a phase. Spotting new issues that arise as initial prototypes are experienced by the customers, etc.

  • More people involved with UX - especially in the contexts where there are too few UX folk. If you're on the team you can spend time with team members, facilitate and teach and get more people helping out with the research work. Sure, you can't instantly turn people into great researchers - but I've been amazed by how quickly people can pick up the basics and start making useful contributions.

  • Much tighter feedback loops, because you're there to see issues as they arise, suggest options, do opportunist research to highlight and identify them, spend less time producing intermediate documentation artefacts, etc.

About the only downside I've encountered, and I'm not even sure that it is a downside, is that it tends to surface the lack of resources for doing UX work. But, for me, the value you get out of it is more than worth having that fight.

The flip side is my experiences of having UXers multi-task. The advantage is obvious - fewer researchers support more teams - but in my experience the disadvantages outweigh that:

  • UX work tends to be more phased and separate from the ongoing product development work.

  • Because it's not continuous we can miss really important things that happen between the phases / touch points with the team.

  • It's much harder to get buy-in by the rest of the team on the value of UX activities.

  • Less UX work gets done since you're not around to facilitate & manage UX activities done by others.

  • You spend more time writing up documentation and producing other artefacts to communicate things that can be done in lighter ways if you're embedded with the rest of the team. Further cutting into the time for research activities.

  • Multi-tasking is hard. It's easy to underestimate the time you spend context-switching between projects.

If you've not already come across 'em I think you'll find this blog post by Leisa Reichelt on UX research at GDS of interest https://gds.blog.gov.uk/2013/08/30/how-we-do-user-research-in-agile-teams/

One other thing that often comes up is the idea of having separate UX stories. I'd strongly recommend against this for various reasons. Instead my preferred approach is to:

  • Where the UX work is related to delivering features - have that work form part of the story(ies) for that feature. If your team has a definition-of-ready and a definition-of-done for stories then that's often a place you can look to ensure that the right kind of UX input and work is happening at the right time.

  • Define research activities on a regular cadence, rather than as stories. (e.g. do usability testing once a sprint).

  • Integrate UX work into whatever process the PO and product managers are using to decide what to build. Or, these days, trying to encourage the whole team to think in terms of research, experiment and product discover in the Lean UX / Lean Startup mold.

On the topic of style guides. Something that's very effective with agile teams is using a live style guide (see https://uxmag.com/articles/anchoring-your-design-language-in-a-live-style-guide for a quick explanation). When everybody is oriented around the same "real" artefacts it's much easier to get alignment, etc.

Some background reading that I think you'll find useful:

  • Agile User Experience Design by Diana Brown
  • User-Centered Agile Methods by Hugh Beyer
  • UX for Lean Startups by Laura Klein
  • Lean UX by Jeff Gothelf & Josh Seiden
  • Agile Experience Design by Lindsay Ratcliffe and Marc McNeill

And a couple of communities that specialise around Agile / Lean UX. Lots of folk there who will have experienced and addressed similar problems:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.