The State of Agile (Enterprise) UX – A Blog Review
In our last post, we discussed a method for quantitative user research. In contrast to the specific topic of the last post, this post gives pointers on how products with a great user experience (UX) can be achieved in the context of an agile development process.
Nowadays 84 % of software companies apply agile methods – yet, how the topic of how UX can be integrated into the process is the topic of ongoing discussions between UX professionals and with other stakeholders within the organization.
Recently, a number of blog posts about UX in different settings were written and caught my attention. As the area of UX – especially in the combination of agile development of enterprise software – is quickly developing, these articles are definitely worth reading if you are a UX professional (or if you work together with UX professionals). I thought this worth to sharing some pointers.
A must-read is Aviva Rosenstein’s article “The UX Professionals Guide to Working with Agile Scrum Teams”, published on Boxes and Arrows. As the title says, the article is focused on the Scrum methodology (a popular framework for organizing agile development). The article discusses a survey about the challenges UX professionals face in Scrum and gives detailed practical advice on how these challenges can be addressed. In particular, the article discusses the problems faced in creating a UX vision when UX work is aligned strictly with the Scrum teams’ sprints or brought in too late in the process. Among the suggestions are the creation of user personas (and using these personas in the user stories or scenarios) and including the team in the design process.
The article “Fitting Big-Picture UX Into Agile Development” by Damon Dimmick was published on Smashing Magazine. For me, the important ideas in this article are 1) the idea of including UX-focused sprints in the agile development process and 2) the idea of a design owner whose role is to foster design and ensure consistency.
Jon Innes post “Integrating UX into the Product Backlog” on Boxes and Arrows suggests a UX Integration Matrix that allows including UX efforts into a products backlog. Jon highlights the necessity of a good feedback loop for agile and UX work. I do love Jon’s idea to estimate UX complexity using Fibonacci numbers and to use task completion rate as a metric for the usability of a UI implementation!
The article also discusses the cause for the (perceived) different value of UX in consumer-oriented vs. enterprise-oriented businesses. While an enterprise company makes money even if user’s can not handle effectively leverage the software or by selling professional services to fix problems that occur, a consumer-oriented business cannot operate that way. I would add to this argument that the perception of the value of UX is shifting. Buyers increasingly understand that an efficient interface design saves time and money by generating more – and higher – quality output faster. As a consequence, even analysts with a technical focus are integrating usability efforts in their reviews of market offerings as an evaluation criteria. Therefore, the perception that UX is less important in enterprise-oriented businesses that in customer-oriented businesses is misleading.
Paul Bryan’s text “Is UX Strategy Fundamentally Incompatible with Agile or Lean UX?” on UX Matters focuses on the field of UX strategy and its compatibility with agile. It discusses two approaches for fitting UX better into modern development processes: Lean UX and Agile UX. The author identifies three key questions are discussed around the agile UX topic: 1) participating in an agile team structure, 2) modifying UX activities and deliverables such that interdisciplinary work gets more effective, and 3) scheduling the timing of UX activities to more easily fit to the sprints of the development team. Especially with respect to the third topic, Paul Bryan offers a number of quotes discussing the importance to do UX strategy and planning before the development starts.
The compatibility of lean UX within large companies is discussed and the author concludes that “[t]hey are fundamentally incompatible”. The reasons are is that “[t]he lean UX form of UX strategy is too lightweight, too reliant on small data sets, too malleable, and too subject to the assertiveness of a just few individuals. For a large company that has a deep understanding of its market, its customers, and its competition, and the resources to fund the best path forward, it’s not the optimal approach.”
An older but valuable post is Jeff Patton’s “Twelve emerging best practices for adding UX work to Agile development” published on AgileProductDesign.com. Among the suggestions Jeff makes are the usage of low fidelity prototypes in communication and the use of prototypes as documentation.
While there is still a lot of uncertainty on how UX is best integrated in the agile development process, especially in large enterprises businesses, there are some factors that are beginning to clarify.
The answer to the question if UX resources should be part of the agile (e.g., Scrum) team or a central resource from my perspective largely depends on the structure of the organization: In smaller organizations and agencies, the need for holistic tasks and planning (e.g., developing a UX vision and a style guide) is smaller than in larger organizations with multiple product teams. Thus, allocating UX resources in the agile team is less problematic. In larger businesses, in which multiple development teams work towards a common goal, the necessity for holistic tasks is much larger. As it is hard to integrate such holistic long-term tasks into a sprint rhythm (mostly two weeks), in such a setting, having UX as a shared resource is more beneficial.
A very lean approach to UX with largely reduced deliverables might be just too lean for large enterprises. Still, communicating both with development teams and with decision makers to create a shared understanding and a common goal based on a visualization of the UX team’s product vision is the most important key factor to success and is more important than highly polished deliverables.
Making the design and research process open and transparent also reduces or eliminates problems with the perception of the work of the UX staff. To be able to achieve an efficient communication, it is very important to establish working processes and a language that everybody understands. For example, by establishing design personas that both, product owners and UX designers use in their stories and scenarios (tip: Make your personas available in your intranet or wiki and allow that stories and scenarios can be linked to them!).
Interdisciplinary thinking is beneficial, too. It does not hurt if UX designers have an understanding of the technical concepts of the software product, but it also does not hurt if developers and other stakeholders take pen and paper to sketch their ideas in visual brainstorming sessions rather than staying in the abstract.
Having somebody fulfilling the role of a UX design owner seems to be especially important in a B2B (business-to-business) settings. Here, the results of having a bad UX are not as immediately visible as in B2C (business-to-customer) settings. And as such, it is more important that somebody advocates the importance of UX. A bad UX in a check-out process in an e-Commerce setting will immediately result in a smaller conversion rate and loss of customers and can straightforwardly be identified with methods such as A/B testing. In contrast, the results of a bad UX in B2B software are much less directly visible (this is not to say they are less drastic!).
… go to to Jochen Toppe and Jesco von Voss for review and valuable comments.