Refactoring the User Experience

“As UX professionals, there is much we can learn from good software engineering practice.”

The ability to take a broad view of the world and incorporate lessons learned from other disciplines distinguishes the best practitioners in any field. As UX professionals, there is much we can learn from good software engineering practice, which maps a team’s understanding of a problem at a human level onto the implementation of a technical solution. The essence of good software engineering practice is effective user experience—from developing the high-level design documentation that describes how the main elements of a system interact to its implementation in clearly written code. Though the relationship between software engineering and user experience is not always an easy one, software engineers and UX professionals share some common goals. Both have a vested interest in producing systems that are useful and usable.

This column, Innovating UX Practice, will explore how we can apply software engineering concepts and practices in the context of user experience design and, hopefully, build greater understanding between the two disciplines.

“Programmers rate themselves almost exclusively by these two rubrics: how challenging is the field and toolset, and how virtuoso are their talents.”—Alan Cooper

“Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.”—Donald Knuth

“Design and programming are human activities; forget that and all is lost.”—Bjarne Stroustrup

The Need for Refactoring

“When faced with a situation in which we are trying to improve a user experience without adding new functionality, we can apply refactoring, a common approach in software engineering.”

Both software engineers and UX professionals can find themselves in the position of having to modify a system that has evolved without strategic planning rather than resulted from requirements?driven design. When faced with a situation in which we are trying to improve a user experience without adding new functionality, we can apply refactoring, a common approach in software engineering. Martin Fowler, coauthor of the book Refactoring: Improving the Design of Existing Code, defines refactoring as follows:

“…changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure…you are improving the design of the code after it has been written.”—Martin Fowler

Consider an object-oriented system that software engineers have repeatedly modified to meet a variety of different needs. An organization’s ever-changing demands on software engineering to make changes to the system’s code can result in software engineers’ taking different approaches at different times to meet short term needs. As a result, variable and method names may have become inconsistent. In such a case, when the time comes for engineers to add new functionality to the system, they are likely to find that the structure of the code makes it difficult to do so.

While the engineers could add the new functionality without refactoring the code, they may judge that changing the object model would make the code more coherent and easier to modify in the future. At the same time, bringing consistency to the variable and method names would make the code much more readable, making it easier for other engineers to understand how the code works. While none of these changes would add functionality to the system, they would make it easier to do so in the future. More important, these changes would improve the user experience of the software engineers who are working on the system!

When UX professionals refactor a user interface, we identify usability problems, refine the user interface’s look and feel, and attempt to improve users’ performance, without changing the software’s essential functionality. Our goal is to ensure that, when using the software, users are able to develop a coherent mental model of how the software works. We support users’ understanding of the software by making its user interface consistent and predictable. Further, we want to be able to add new functionality in the future, without forcing users to change their mental models significantly.

Identifying UX Smells and Deeper Problems

“UX smells can indicate opportunities for refactoring a user experience.”

Software engineers use the term code smells to refer to symptoms in the source code that may indicate deeper problems that might provide opportunities for refactoring. Similarly, UX smells can indicate opportunities for refactoring a user experience. Recognizing UX smells can be extremely subjective—depending on our experience with a system. Some examples of things we might identify as UX smells include

duplicated processes

Web pages with too little content

Web pages with too much content

use of different terminology for the same concept

All of these UX smells could be indicators of deeper problems. For example, duplicated processes can present problems in the maintenance of the software and also cause inconsistencies in users’ mental model of the system. Web pages with too little or too much content are both aesthetically unpleasant and frustrating for users. Using different terminology for the same concept confuses users.

Incorporating Refactoring into Your Process

“In user experience, effective refactoring demands a clear understanding of users and what they are trying to achieve with an existing system, but also what they may want to achieve in the future.”

In user experience, effective refactoring demands a clear understanding of users and what they are trying to achieve with an existing system, but also what they may want to achieve in the future. Thus, clarity about the strategic direction for the software is essential, and ideally, that strategic direction should have been informed by user research.

When software engineers refactor code, they create a robust set of tests to determine whether the changes they’ve made during refactoring have been effective. Then, they execute the tests on a regular basis to ensure the software still works as expected. For user experience, a clear understanding of how users currently perceive the software should inform any refactoring process. At the end of the software development process, usability testing should ideally indicate an improved user response to the software—or, at the very least, no change in user response—before making changes to the user experience live on a Web site or publishing shrink-wrapped software.

As with anything else in user experience, you’ll need to justify refactoring as a UX approach within your organization. Refactoring is integral to an agile development process, so in organizations where agile development is already established, selling refactoring will probably be much more straightforward. Yet, even in organizations that haven’t adopted agile development practices, refactoring offers substantial benefits.

Benefits of Refactoring

“Greater internal consistency … makes it easier for people to understand how the system works, reducing the overhead associated with bringing new people onto a project.”

Refactoring improves the internal consistency of a software system, whether in the software’s code, its structure, or its user interface. Greater internal consistency, in turn, makes it easier for people to understand how the system works, reducing the overhead associated with bringing new people onto a project. A principle Fred Brooks first noted in The Mythical Man?Month affects both user experience and software engineering professionals: “Adding manpower to a late software project makes it later.” The nature of what we do generally makes it more effective to have a small number of skilled people focused on a project, but when we do have to add team members, consistency helps.

Learning to look for UX smells and identifying the deeper problems they often indicate will help you to improve the user experience of your software. As with refactoring in software engineering, spending time improving what already exists in a user interface will help make future changes to your software much simpler to design and implement. Refactoring provides greater consistency for all users—both within your organization and your customers’ organizations.

1 Comment

Hi Peter, You are absolutely right, there are many more commonalities that a software engineer who may be in the category of senior optimizer level shares with any UX engineer. It’s not just with regard to the refactoring, it shares a whole new dimension of how the software has to be seen from the code perspective.

It’s not just the output that has to be engineered. It’s also the code that has to have a very structured and a schematic approach. I could probably say, from what I know, a disturbing point with regard to the intrinsic structuring (code engineering) these days the open source communities have brought in a great revolution that would present the ideation of free plugin systems that would take the role of many functionalities. The job becomes easy, but if not properly structured, we are creating a problem for the future. Thanks to OOPS for making it a well defined concept, giving room for much of innovation and optimial discoveries.

Coming to the extrinsic structuring (the UX) it has to be a greater balance between the need-to-haves and the nice-to-haves. The marriage between the intrinsic and the extrinsic structuring creates a perfect system.

It’s not easy to achieve, as in a process like agile development, specifically Scrum, for every sprint we might have certain backlogs that may be paused or postponed. This concept allows such a lovely flexibility for every programmer to craft their development with simple bricks. But again to have an efficient Scrum, we need a very effective Scrum owner. I consider that guy as the character who has the blood mixed with the software Eegineering, UX, IA, and the scheduling capabilities.

Thanks for sharing such a wonderful concept. Not sure how much spread across the world is a concept where a designer is not bothered about functionality, he just sees his screen colors and its layout. But you have brought a very nice point of outer structuring, sharing commonality and relationship with inner structuring.