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.
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.
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.
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!