Top
Process

Reusing the User Experience

Innovating UX Practice

Inspirations from software engineering

A column by Peter Hornsby
June 22, 2009
  6 Comments

Developers often report a sense of déjà vu when creating software—a sense they’ve already designed or coded a function. Of course, the feeling that he or she is doing unnecessary work is particularly frustrating when a developer is under pressure! The reuse of software components can help to address this problem. Components are proven, reusable units of design and code that meet a specific need. As such, they enable a developer to think about solving problems at a higher level of abstraction, making the development process more efficient. For example, rather than writing a function to print a file, a developer can find and reuse a pre-existing component that meets the requirement.

As a rule of thumb, the earlier in the development process reuse can occur, the more efficient reuse becomes. Like software component reuse, the reuse of UX design elements can be a very efficient form of reuse—particularly because this form of reuse occurs very early in the product development cycle. The ability to reuse prior work effectively is one characteristic of a mature discipline.

Champion Advertisement
Please become a patron of UXmatters by subscribing on Patreon.
Continue Reading…

“Specialists in every part of software have a curious vision of the world: All parts of software but his are simple and easily parameterized; his is totally variable.”—Alan J. Perlis

What Is a Component?

The concept of software components arose in 1968, and the software industry has made many attempts to implement software components effectively, with varying degrees of success. Even within software engineering, which has been using components in various forms for over 40 years, there are conflicting views about what a component is. A code-level component might be an object, a function, a procedure, or another language-based element, but the basic principle is a black box unit of functionality with known inputs and outputs that operate within known tolerances. In creating and using a software component, the developer needs to consider two aspects:

  1. the technical demands of the system implementation, including
  • the need for efficiency that is driven by limited machine resources
  • designing code to take advantage of developers’ skills
  • implementation language
  • future maintainability
  1. the real-world problem and the constraints it imposes—While developers should ideally treat a component as a black box with known inputs and outputs, they may still choose to tweak the component to make it more appropriate to their needs.

Reusing User Experience

While the ideal reuse scenario is one where the designer can simply plug in a component, designing for reuse from the outset enables reuse to occur in a much more flexible way. While we may not know the specific details of a problem at hand, we generally have sufficient understanding about basic human interaction principles to enable us to design a good, general-purpose solution, or UX component. To design a successful, flexible UX component, we need a clear understanding of:

  • what we’re designing the component to do
  • the context in which the component exists
  • ways in which we’re likely to want to modify the component

Being aware of the ways in which we could modify a component and documenting them thoroughly builds reuse into the development process from the outset. Even a simple component such as a date entry field can take some time to document completely. The component design documentation must provide a clear and complete picture of the component to promote understanding and reuse.

To design an effective component, we must be clear about the user need it addresses. User needs are a major driver for UX professionals, so we can use a user need as the basis of a high-level description of a UX component that is designed for future reuse. We can capture the essence of the user need in both the name of the component and structured prose that describes the user need in more detail. Using a consistent format for the names of UX components—such as <verb> <noun>—enables easier indexing and retrieval of components.

We also need to understand the business need for UX components. In a large organization, this is critical to helping us understand whether a component is indeed fit for its purpose and to identifying where and how the component aligns with broader organizational goals.

The description of the design of a UX component usually needs to address five elements:

  1. content requirements—which describe the various content elements in the component
  2. information architecture—which describes the arrangement of content elements within the information space
  3. interface design—which describes how the interface elements enable users to interact with the functionality
  4. interaction design—which describes the workflow and behaviors of the user interface
  5. navigation design—which describes the means by which a user moves between content elements and may be optional for a given component, depending on its level of complexity

Experience suggests that, to enable people to effectively reuse components, the visual interface design is perhaps even more important than the user need as a succinct way of communicating the purpose of the component to designers.

Describing the interaction design as a hierarchical task analysis allows us to make the efficiency of various components explicit and compare different interactions in terms of the number of steps completing a task requires. Understanding the interaction design of multiple, dependent components in a system at this low level makes it easier to understand the overall interaction design and level of complexity of the final design. Thus, early in the development cycle, we can understand how complex a given component-based process is.

Finally, a functional specification must support the UX component, describing the component at a technical level, providing all of the information the developer implementing the design requires,s and accounting for UX requirements—for instance, for accessibility.

Describing a Component

Let us return to the example of a date capture component, and I’ll provide a very lightweight example of component documentation. A real-world example would contain much more detail, particularly at the level of the functional specification. I’ve omitted the navigation design and information architecture for this simple example, but complex components would probably include both.

Title: Capture date

User need: Enter a date quickly and accurately

Business need: To support the client-side capture of a date

Content requirements: Date elements—month, day, and year—and instructional text

Interface design:

Date component

Interaction design:

  • User 1: Locate the date form component on the page.
  • User 2: Select the first date field.
  • User 3: Enter the month as a 2-digit value.
  • System 1: The predefined text disappears.
  • User 4: Select the second date field.
  • System 2: The predefined text disappears.
  • User 5: Enter the day as a 2-digit value.
  • User 6: Select the third date field.
  • System 3: The predefined text disappears.
  • User 7: Enter the year as a 4-digit value.

Functional specification: The date entry form consists of the following:

  • form label: Start date
  • 3 text fields: prepopulated with
    • MM for the month
    • DD for the day
    • YYYY for the year
  • behavior: When a user selects the text field, remove the prepopulated text automatically.

Providing a detailed description with several layers of abstraction enables UX professionals to compare different components easily and identify which of several—potentially competing—components is most appropriate for their specific need, as well as whether the component is modifiable. By separating out the description into several distinct parts, we can support reuse of the component with minor variation—for instance, using the component on Web sites with different visual styles, for which the characteristics of the component are consistent in other respects. While this may be a step away from pure component reuse, it is a pragmatic approach that still saves much effort across a complete development cycle.

While this overview provides a designer with the ability to identify an appropriate component and assess its suitability for reuse in the current design context, it is also important to support the reuse of the component by providing downloadable content such as a visual template for use in wireframing and code for a prototype or actual development. Working closely with developers can both promote communication within the organization and make the UX component a more complete solution.

The Risks and Challenges of Component Reuse

Component reuse is not without risk, and this is a lesson that software engineers have learned at their cost over many years. For example, in one case, patients received overdoses of radiation due to improper component reuse in the Therac-25 therapy machine. We are all too aware that poor interface design is also a major risk factor. The disasters at Three Mile Island, Bhopal, and Chernobyl all resulted in part from poor user experiences.

As in software engineering, component reuse in user experience is not without its challenges. Naming components for reuse, particularly in a large component library, is a major hurdle. Studies have demonstrated that the likelihood of any two people using the same term to describe a software component is less than 20%. In UX, a field that is arguably less coherent that software engineering, this is likely to be a major challenge.

Designing a generic component library can be a major task in itself, and many organizations may not have the resources available to do this. In such cases, identifying components that are potentially reusable and modifying them as appropriate in order to make them more generic can be a useful starting point.

In Summary

Done well, component reuse can provide a significant increase in the effectiveness of the design process. Effective reuse must minimize associated human and computational costs while still allowing a degree of flexibility. The human cost is the time a designer requires to find the component to be reused, to understand it, and to perform any necessary modifications. The computational cost is the cost of employing a reusable component relative to that of a purpose-built version of a component. While the formal development of a library of reusable UX components can be a costly process, building reuse into your development process and creating components from existing design artifacts can still bring significant benefits and efficiency to your UX team. 

In Design Process

Peter Hornsby

Director at Edgerton Riley

Reading, Berkshire, UK

Peter HornsbyPeter has been actively involved in Web design and development since 1993, working in the defense and telecommunications industries; designing a number of interactive, Web-based systems; and advising on usability. He has also worked in education, in both industry and academia, designing and delivering both classroom-based and online training. Peter is a Director at Edgerton Riley, which provides UX consultancy and research to technology firms. Peter has a PhD in software component reuse and a Bachelors degree in human factors, both from Loughborough University, in Leicestershire, UK. He has presented at international conferences and written about reuse, eLearning, and organizational design.  Read More

Other Columns by Peter Hornsby

Other Articles by Peter Hornsby

Other Articles on Design Process

New on UXmatters