User Experience and the Big Picture, Part 1: Problems, Problems

January 20, 2020

This is Part 1 of a three-part series in which I’ll ultimately present some radical thinking about how we could improve the software-development lifecycle (SDLC) and the key role that UX professionals can play in achieving this improvement.

Those of you who are familiar with my other UXmatters articles—such as “Are You Still Using Earlier-Generation Prototyping Tools?”—are aware that I’ve given a great deal of thought to making the UX function more effective and efficient. If you’re familiar with some of my other articles—such as “Agile Problems, UX Solutions, Part 1: The Big Picture and Prototyping”—you’ll also understand that I’ve given even more thought to making the entire SDLC more effective and efficient, and the key role that User Experience plays in this important goal.

Champion Advertisement
Continue Reading…

Our pursuit of a more effective, efficient SDLC is, in part, simply a function of basic curiosity and a desire to improve the world of software development. It is also perhaps an inevitable consequence of 30 years of experience across the wider SDLC, in both academic and practical contexts, including extensive experience in specific areas such as requirements engineering, business analysis, coding, and technical architecture. However, despite our making some good progress in this area, the same basic problems keep reoccurring, with the same consequence: a very suboptimal SDLC that all too often results in the delivery of inviable software products.

Of course, this problem is very well recognized, researched, and debated. Academia has covered this problem extensively, and there are many PhD theses on this topic. Likewise, many commercial organizations make a big point of promoting their unique ways of building software products. Welcome to the world of software-engineering methodology.

I subscribe to a belief that many people who solve complex problems share: If you truly understand a problem, you are probably 90% of the way toward solving it! This is why Part 1 of this series focuses on the key problems that we often experience in the SDLC. I’ll first address holistic SDLC problems, then discuss some specific issues in relation to the UX function.

Holistic SDLC Problems

A useful framework for discussing these problems is to consider the four big players in the software engineering methodology game today: waterfall, agile, Lean, and user-centered design (UCD). All four of these methodologies have sought the goal of improving the SDLC—and all four have brought both successes and problems.

Perhaps one of the key problems is that many professionals have simply not understood what these things actually are. They are frameworks, paradigms, broad approaches, or ways of thinking about the SDLC. They are not software-development methods and do not provide any detailed advice on how to actually build a software product. So, when an organization says, “We use agile,” that can mean many different things! Likewise, there are very few examples of organizations using any of these frameworks in their pure form. For example, many organizations chant the mantra of UCD, but even a cursory investigation reveals that their methods mostly fall far short of the true definition of UCD. In reality, most methods are unique, custom hybrids that incorporate some parts of some of these frameworks.


Waterfall’s concept of breaking big problems down into discrete stages is basically reasonable. Indeed, it is a necessity in my opinion. Its drive to create a holistic view of the software as soon as possible is also admirable. Accountants, lawyers, and technical architects love the illusion of certainty it brings. Of course, waterfall’s reality rarely matches anyone’s fantasy of what the final software will be. This is partly because requirements can never be fully defined at the outset. They often legitimately change during the SDLC, which is typically a long process, and the world often changes significantly during development. Plus, a lot of learning about the requirements takes place during the SDLC process. Indeed, much learning takes place precisely as a result of executing the SDLC.

However, many of waterfall’s failures are not a result of its core principles. Rather they occur primarily because of two of the more pragmatic features that people have historically associated with waterfall. The first is that most waterfall projects rely on abstract modeling devices such as requirements documents and use-case diagrams, which inevitably leads to high degrees of ambiguity in the definition of requirements. Second, most teams have chosen to structure waterfall projects so different teams carry out separate stages of the development process. For example, a completely different team from the Design team carries out the requirements stage, using fundamentally different tools and techniques. This inevitably leads to massive communication problems across the stages in the waterfall.

In reality, there is nothing stopping the use of concrete modeling devices on waterfall projects—such as interactive, high-fidelity prototypes. Likewise, it is perfectly feasible that the same team could carry out the requirements and design stages, using the same—or at least more similar—tools and techniques.


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

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

Stakeholders from other teams and disciplines could perform many of the activities that UX design teams often perform. An obvious example of this overlap of functions is persona development, which marketers, requirements-engineering specialists, or business analysts could also do. Another example is the development of use cases, which business analysts have traditionally developed. User Experience also overlaps with the development world—for example, when UX designers prototype using development tools such as HTML and JavaScript or when they build assets for live deployment, using tools such as Zeppelin.

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.

I have often seen UX designers present bewildered development teams with an uncoordinated stream of design deliverables that define what they need to build—for example, Adobe Photoshop or XD screen designs, Figma prototypes, Confluence documents, and Excel spreadsheets, along with some hand-coded HTML and JavaScript. Plus, UX teams often seem oblivious or uncaring about the problems their use of multiple, disparate tools causes development teams. Indeed, development teams themselves are sometimes unaware that their job could be so much easier if UX teams used fewer tools and used their tools in a more coordinated manner.

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.

What’s Next?

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. 

CEO of Ax-Stream

London, England, UK

Ritch MacefieldRitch has worked in UX design since 1995. He has a BA with Honours in Creative Design, an MSc with Distinction in IT-Computing, and a PhD in Human-Computer Interaction (HCI) from Loughborough University’s HUSAT (HUman Sciences and Advanced Technology) Institute. Ritch has lectured at the Masters level in five countries—on user-centered design, UX design, usability engineering, IT strategy, business analysis, and IT development methodology. He also has numerous internationally recognized qualifications in IT-related training and education. He has published many HCI articles and was on the editorial team for the Encyclopedia of HCI (2007). Ritch has led major UX design and user-centered design projects at Bank of America, Vodafone, Thomson-Reuters, and Dell Computers. His international experience spans 15 countries. Ritch presently heads Ax-Stream, an approved Axure training partner. His work currently encompasses Axure training, advanced Axure prototyping, usability and acceptability testing of early conceptual prototypes, coaching and mentoring of senior UX designers, and strategic UX work—integrating UX design and user-centered design into agile development methods and moving organizations from second and third generation to fourth generation prototyping methods.  Read More

Other Articles on Development Process

New on UXmatters