Agile recognizes the benefits of breaking down solutions to software problems into manageable chunks, or sprints. The methodology’s goals of reducing documentation, improving stakeholder collaboration, and making coding more efficient—for example, by introducing competitive principles within the coding team—are also highly beneficial. But agile purists’ call to go on a journey with your software team or supplier to an unknown destination, taking an unknown amount of time and money, involves significant risks! The lack of an up-front, holistic vision can lead to a fragmented, inconsistent design.
This is why, in reality, there are very few examples of companies using purely agile methods in commercial settings. This reflects, to some degree, the fact that agile originated with coders, not software product directors. Agile was born out of the understandable desire of any coder to just start coding and have enough time and money to work until they’ve finished. Interestingly, technical architects often do not like Agile because the use of this methodology very often necessitates major changes in the technical architecture as sprints progress or design inconsistencies result.
Lean’s streamlined methods are particularly good if expenditures of time or money are critical. Importantly, Lean also recognizes the value of formalized design thinking and focusing on the customer. This offers the potential to maximize market opportunities, but can also involve the significant risks of taking shortcuts, particularly in validating concepts and nailing down key details. For example, in Lean methods, proto-personas often drive requirements and, because these are largely based on nothing more than opinion or invention, it is easy to question their validity.
User-centered design (UCD) also places the customer, or user, at the center of the SDLC and relies heavily on design thinking. Unlike Lean, UCD has been around quite some time, and the tools and techniques teams often use in its implementation are more robust—for example, formalized usability testing and interactive prototyping. The bottom line is that UCD projects usually deliver good software products that make stakeholders happy.
However, practicing true UCD is very expensive, primarily because of its highly participative and iterative nature. In reality, few organizations can afford the cost of true UCD. Another problem with UCD is that the time it takes means companies could easily miss market opportunities, especially in our rapidly changing technological world.
Benefits and Problems of UX Design
The coming of UX design as a mainstream software-development profession has been a major benefit to the world of software engineering in two ways. The obvious one is that it has made software products better. Less obvious is that it has also improved the software-engineering process. This is largely because UX design primarily utilizes concrete modeling tools such as visual design and interactive prototyping. These tools and their associated techniques make it much easier for stakeholders to define and communicate what they’re proposing as a solution to meet both business requirements and user needs. Concrete modeling techniques also help massively in defining what development teams need to build.
It is this issue of improving the software-engineering process that will be the focus of my discussion in this series and, despite the benefits that User Experience has brought to improving the SDLC, my experience is that User Experience has also introduced some problems.
The Overlap of User Experience with Other Functions
These functional overlaps often cause tensions across members of software-product teams. They can also cause inefficiencies if the UX team’s and another team’s activities result in duplicate efforts or when essential activities fall between two teams so don’t get done on time, efficiently, or effectively.
These problems arise not least because, despite some valiant attempts, definitions of what a UX team should do vary greatly—even within the world of User Experience, let alone outside it! Further, the role of the UX function can legitimately vary depending on the particular context—for example, according to the particular project or client.
Poor Use of Tools and Techniques
There is a plethora of material on UX tools and techniques—for example, thousands of blog discussions about which is the best UX prototyping tool. A common theme in these discussions is advice that UX designers use whatever tools and associated techniques they think are best for the job at the time. Indeed, many argue that it is best practice for UX designers to use various UX tools on the same project. Similarly, different UX designers commonly use different UX tools on the same project, simply because of their individual preferences and experience using those tools.
I have repeatedly questioned the legitimacy of such advice. For example, in my UXmatters article (Why) Is UXD the Blocker in Your Agile UCD Environment? I wrote that I have seen no evidence that allowing individual UX designers to use different UX design tools as, when, and how they please makes UX processes any better. However, even if this were the case, this practice overlooks a key question: whether the choice and use of particular UX tools improves the SDLC as a whole.
In summary, we should always consider the use of UX tools within the context of the SDLC as a whole—in particular, the interface between the Design and Development teams. Sadly, this is often not the case in my experience.
In Part 2, I’ll discuss what we can learn about improving the SDLC, both through analyzing these problems and by learning from other sources. Then, I’ll present some radical ideas on how we can address these problems, resulting in significant improvements in our thinking in relation to the development of software products. I’ll offer evidence that UX professionals have a key role to play in making this happen.