in Agile, Process

Agile and UX Coaching

It seems to be increasingly commonplace for there to be a shortage of senior level UX designers, so the ability to extend fewer of them across more teams is likely of great interest and potential value to many organizations. This is an emergent pattern in Agile UX circles for achieving this.

UX Coaching visual

More UX in early iterations, more Dev in later iterations

One of the more common challenges in integrating UX work into an Agile team is the push-and-pull between the good Agile practice of having knowledge and expertise distributed across team members and the desire to have a genius designer just come up with a strong design concept and hand it off to the team, so that the team can quickly get started building.

The latter model seems nice in the short term, but leads to all kinds of problems in the longer term.  When developers simply are handed something to build, something they were not part of designing, they are likely to care less about the quality of the experience, since they have a decreased sense of ownership of the work.

And, because they are less likely to understand the thinking behind the overall concept, i.e. why a certain design choice was made, they will be less able to extrapolate it into the atomic-level details they are working on, many of which the overall concept inevitably did not account for.  In short, not having the team actively participate in developing the overall user experience vision will lead to a lower quality product.

Group of people sketching (and I think the person in the foreground is Johanna Kollmann)

@johannakoll sketching, photo by Paul Kelly

Teams I have met and worked with are usually eager to participate and own the UX design, but often just need a bit of high-level guidance.  What should be the overall user flow? In what way should pages for anonymous users be different from those for users who are signed in? What are some key considerations in designing the navigation? In designing forms? Etc.

The UX Coaching model has emerged as a strong pattern which provides a best-of-both-worlds solution to this challenge.  Here, the UX expert acts as a kind of consultant to the team, providing guidance while ensuring that the team is actively participating in the development of the overall vision. Team members are not just reviewing and providing feedback on the design, but are in fact the designers of the user experience.

In this model, the UX Coach plays two main roles:

  • Visioning: At the outset of the project, the UX Coach helps the team develop a user experience strategy and vision that best supports the overall business need.
  • Office Hours: During development iterations, the UX Coach is available during regular “UX Office Hours,” which become part of the project rhythm, to provide the team with feedback on their design concepts, to ensure that it remains consistent with the overall vision and in line with the latest UX best practices.

UX Visioning

The specific activities that would be part of developing the experience vision will be unique to each project.  Some examples include a Product Box activity and a Design Studio activity.  Additionally, it will involve some user research, such as a contextual inquiry, user interviews or whatever makes sense for the current situation.  As with the design work itself, the UX Coach would lead the team in how to do this work, but the team is responsible for doing it; they will be the ones observing and interacting with users.  Here, the UX Coach does not present design concepts to stakeholders; team members do.  The UX Coach does not produce sketches or wireframes or prototypes; the team does. (Yes, they may provide training and guidance regarding the mechanics of creating these forms of artifacts, but they are not producing the actual project artifacts.)

At the conclusion of the visioning phase, which ideally should last no more than three weeks, every team member should have a clear vision of what the product is, why the product is being created, and what the current vision is for what the user experience of the released product will be.

UX Office Hours

With the team now having a clear sense of direction of the user experience, they can begin to simultaneously design and develop the detailed solution. During early iterations, teams are likely to spend a greater part of their time doing design work compared to actual development work.  Some developers are likely to feel that they are wasting time on doing user interface design and that it will look bad on their burnup chart. It will be the job of the UX Coach, in collaboration with a ScrumMaster or equivalent team role, to manage this.

Teams need to take a step back and realize that, while short-term velocity may be lower, the overall project velocity is likely to be higher, since iterating between sketching/wireframing and building can happen more fluidly with the same group participating in both of these activities.

As the product begins to take shape, the product itself can more and more become a reference point in the design, with an increasingly smaller part of iterations needing to be devoted to design, allowing for velocity to increase. (E.g.  a developer can build a new page template using an existing template but only add one or two new blocks of functionality)  This approach can powerfully mitigate the whole “feeding the beast” phenomenon that emerges when UX designers are expected to be creating entire solutions an iteration or so ahead of designers, which really is nothing more than doing waterfall inside of Agile.

These are some key advantages of this model:

Allows a small number of UX specialists to guide a large number of teams

As I mentioned above, perhaps the greatest strength of this model is that it allows for a smaller number of senior level UX designers to lead a larger number of teams.

At the same time, the idea of having one individual work on many simultaneous projects is generally considered an anti-pattern in Agile circles.  In a traditional model, because project pace tends to be far slower than in Agile model, working on many projects at the same time may appear to be effective, but the reality is that it creates continual disruption of work and incurs a cost each time the individual switches between projects, since they need to be brought up to speed on whatever developments have happened since they last were working on the project.  And with an Agile project, a lot more is likely to have happened in a shorter period of time.

It is a bit like one ball player trying to play on two fields at the same time.  It just doesn’t work. But a sports coach certainly can coach more than one team, and so too can a UX Coach lead the UX design for several teams.  After the initial project visioning, at which point the coach’s involvement is more intensive, the relationship can then become a recurring part-time relationship.

Facilitates increased UX literacy across the organization

As team members are forced to think about the software experience, in addition to the implementation of the software, they will develop an increased understanding of the relationship between these two dimensions of work. Over time, they will require less and less guidance from a UX specialist, making for an approach to designing user experiences that is more holistic, cost-effective,  and leads to a higher quality experience.


This approach will really only work with very senior-level User Experience designers, who have experience in developing overall experience strategies, are fluent in current best practices, and have experience facilitating group sessions. However, that is no different from the requirements for being a successful Agile coach, which requires years and years of experience in the project trenches, in a variety of roles.  The approach is not recommended for junior-level designers, who are likely to be more effective if instead allowed to focus on a single project. There are probably other disadvantages, but I can’t think of any at the moment.

Update: Once again, Joe Sokohl comes through with key insights, pointing out something that was obvious in my mind but I did not state explicitly in the post – the idea of a UX Coach is analogous to an Agile Coach. Just like the Agile Coach is not part of a team but helps the team undergo the transformation from a traditional to an Agile approach, so too does a UX Coach help Agile teams undergo a similar transformation, from UX being a vaguely mysterious notion to something that is just another normal part of an Agile project lifecycle. Thanks Joe!


    • […] dos últimos cacrks de Frogtek) y yo. Luego nos arrepentiríamos de salir tan tarde, ya que las actividades organizadas por Biko2 por la mañana, Coding Dojo y charla “La organización ágil” de […] 

  1. Great article. I think one important and overlooked point is that both designers and developers need continual UX coaching throughout a project. As you put it the short-term velocity will be lower but overall will be higher.

  2. Interesting article, Anders. I like the thought of being a coach in my organization. It seems to me that, for this to be a useful strategy, your organization has to be at a certain level of UX maturity. People have to all be clear on what UX is all about, and what that end-vision is, that they can all work and converge on a solution. Also, project stakeholders (developers, business, operations, etc) have to 1) trust each other, and 2) be willing to work outside their job role. In lots of enterprises I’ve worked in, the attitude of the team is, “That’s the design team’s job to make it pretty, and not my problem…”

    So part of the UX coaching needs to including some of that organizational teaming component, helping people get pass the ‘that’s not in my job role’ point of view.

  3. Hey Jared,

    In short, my answers are Yes, Yes, and Yes!

    Yes, there should definitely be visioning throughout the project. Or, more specifically, the team should continually be assessing the accuracy of their project vision. Often, as detail designs are developed, this can reveal the need to make adjustments to the vision.

    Yes, the vision certainly needs to be a living part of the design process. One way to help enable that is to simply have the vision statement on an easel-size post-it in the team room. Of course, all teams don’t have the luxury of all being in one room, so it will also be necessary for facilitators to ensure that the vision is continually revisited.

    Yes, UX is definitely not a single thing. And yes, just as an Agile Coach needs to be strong in terms of their Agile knowledge, so too does a UX Coach need to be very strong in terms of their UX skills. But as the field matures, more and more people will be at this level of knowledge.

    Re. your final note, I have to disagree a bit. I think the concept of a UX Coach simply is a natural evolution of the UX practice as a response to the Agile revolution. Mentoring is all good and well, and I have been doing that for years, but its too passive in a project context, in which Coaching becomes a much more active and on-the-ground form of mentoring.

  4. This is an interesting idea. I’m intrigued.

    A couple of things jump out at me:

    1) I’m struck how, in the world of No-Big-Design-Up-Front, we keep trying to put Big-UX-Up-Front. Just sayin’. I really like the idea of creating a vision, but it seems limiting to me to stop there. Shouldn’t there be user research activities through-out the project?

    2) With regards to the vision, in our research at UIE, we met many teams who created visions, but failed at making them meaningful through out the design & development process. The vision is often lost in the details of getting the project done.

    The teams that successfully integrate their visions do so by making them living parts of the entire design process. Always asking the question, “Is this helping us get closer to our vision?” I’m wondering how someone who is not part of the daily routine facilitates this.

    3) UX isn’t a single thing. At best, it can be quantified as a collection of skills. It sounds like your approach of a UX coach implies that individual is at a high enough level in all the necessary skills. That sounds like really big shoes to fill. (And very high risk, because if that person isn’t properly skilled and guides the team in the wrong direction, their trust of the coach is lost.)

    I’m not convinced that creating a new role is the right approach to integrating UX into the Agile process. I still think we need to think more along the lines of mentorship than coaching.

  5. I see that both of you agree that there is such a things as a Tech Coach under this pattern, which is only supported by most orgs that I’ve seen. Most places have a senior tech guru that hovers and touches all of the projects going through all the different teams, no matter what development methodology is being practiced. Usually these folks are too expensive to have lots of them (nevermind google) or egos get in the way of having too many of them. Did I just say that?

  6. Hey Joe – great feedback as always. Your comment made me realize that I failed to include something that was so obvious in my mind that I did not think to state it explicitly: the idea of a UX Coach is virtually the exact equivalent of an Agile Coach. Just as teams struggle to understand their path from a traditional software development approach to an Agile approach, so too do teams need coaching in how to integrate UX into an Agile model, for the simple reason that Agile effectively is silent about UX.

    So, yes, the construct not only posits that there would be a “Tech Coach” roaming around, but is in fact based on it, except that the teach really is an Agile Coach, i.e. not a tech lead but someone who helps with shifting how people work, from a traditional to an Agile approach.

    Re. the UX Coach not being part of the team, that is very intentional. The whole source of the Us/Them problem between UX and development is that UX is a separate role, a separate person who is the keeper of the UX, when the reality is that UX is everywhere. Every team member affects the UX and is affected by the UX design. For that reason, it should ideally be distributed across the team. The front-end developer should understand UX. The tester should understand their impact on UX. And so on.

    Remember, I am not proposing that the team be completely left to their own devices when it comes to the UX design. It is critical that the UX Coach participate in helping the team form the overall UX vision early on. Once that general direction is in place, however, the team should fully take the reins and be able to create the atomic level experience under the watchful guidance of a coach.

    • I may intervene for a quick check to ask the team How are we doing? and if they feel they are doing well and mainkg progress, I would remove myself and let them continue. If they are still framing the problem, I may also ask Are we ready to define the problem statement? If so, I will ask each member to write it down and then have each member read what he/she wrote to the team. Then, I would ask the team if we have similiarities or still need more time. I would excuse myself so the team could finalize the problem statement or continue working on the problem statement.

  7. Well-written and thoughtful article, Anders. I think it does give us somehting to ponder.

    My biggest drawback I see is this idea that the UX Coach isn’t part of the Team. That’s always been the big struggle: UX professionals have been considered an add-on, an accretion, to “Agile.” Instead, my contention is that UX professionals are no different from dev professionals or biz professionals. And as team members, UX profis should do what they do best and not what they don’t do well.

    Does the same construct posit that there’s a Tech Coach wandering among different teams? If so, then I think this model is viable. You could think of them as an agile SWAT team.

    Again, my biggest concern is parity & equivalence. I hope that we don’t foster fragmentation of UX resources. Too, perhaps the goal is to be honest with project sponsors: It’s not easy nor cheap to create compelling user experience environments.

Comments are closed.


  • Agile and UX Coaching #ux #design #ui #usability | May 1, 2010

    […] #ux #design #ui #usability Agile and UX Coaching #ux #design #ui #usability Link – Trackbacks Posted in User experience (UX) | Permalink. ← How To Avoid Web Design […]

  • User Experience, Usability and Design links for July 27th | May 1, 2010

    […] Agile and UX Coaching – Anders Ramsay.comOnce again, Joe Sokohl comes through with key insights, pointing out something that was obvious in my mind but I did not state explicitly in the post – the idea of a UX Coach is analogous to an Agile Coach. Just like the Agile Coach is not part of a team but helps the team undergo the transformation from a traditional to an Agile approach, so too does a UX Coach help Agile teams undergo a similar transformation, from UX being a vaguely mysterious notion to something that is just another normal part of an Agile project lifecycle. […]

  • Agile and UX Coaching – Anders | A Blog for Social Usability May 1, 2010

    […] via Agile and UX Coaching – Anders […]

  • June Roundup | UX Booth May 1, 2010

    […] community to consume, respond to, and grow from. Here are some highlights from the UX community: Agile and UX CoachingOne of the more common challenges in integrating UX work into an Agile team is the push-and-pull […]