Reusing the User Experience

By Peter Hornsby

Published: June 22, 2009

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.”

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.

“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 software industry has made many attempts to implement software components effectively, with varying degrees of success.”

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 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.”

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
“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.”

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 … components is most appropriate for their specific need.”

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 in user experience is not without its challenges. Naming components for reuse, particularly in a large component library, is a major hurdle.”

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

“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.”

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.

6 Comments

You say, “Studies have demonstrated that the likelihood of any two people using the same term to describe a software component is less than 20%.”

What study is this, please? Thanks.

Hi there,

The full reference is:

Furnas, G.W., T.K. Landauer, L.M. Gomez, and S.T. Dumais. “The Vocabulary Problem in Human System Communication.” (PDF) Communications of the ACM, 30(1), 1987.

Although this copy doesn’t appear to have the figures in!

Identifying keywords that all users of components can easily understand can be a very challenging task. I’d be interested to know your thoughts.

Kind regards, Peter

Peter

Great article. Quick question.

I am wondering why you never employ the term design patterns, or the like, as design patterns is the prevailing metaphor around the concept you are outlining? I do think the concept of reuse is an important real-world term that helps introduce the discourse on design patterns and that components are UI examples of reusable interface patterns; but now this term is so prevalent among those of us who tackle issues like this that it almost seems like you are avoiding it. Especially since you go into a bit of history, it’s almost strange to see patterns/em

This is not a criticism—I think your article is fine. It’s more of a methodical question. I focus a lot on the development of discourse in interaction design, so this type of thing stands out for me.

Carlos

Hey Carlos,

Thanks for taking the time to comment. It’s great to get feedback on these articles!

A set of design patterns alone isn’t sufficient; the design patterns need to be structured so that we can understand the component easily, but also reuse it flexibly by modifying just the relevant aspect of the component. Ideally, we will also have the—prototype or code—implementation elements available as part of our reuse library.

I felt that using the term design patterns might detract from the key message of how we describe components for reuse. I see design patterns as an important part of the story, but not the whole story.

Kind regards, Peter

Great article!

I particularly enjoyed the level of detail you recommend in documenting interactions and such. At the same time, I find that the level of detail must be flexible, so as to accommodate varying levels of tolerance.

The type of detail you outline seems to me mostly geared toward the development community and fellow UXers—who are most concerned about it. Communicating this level of detail to most others—such as a business owner, a marketing associate, or even some designers—will often win you boredom, impatience, and a reputation as a stuffy, academic type who doesn’t really understand their needs.

I’m sure you understand all this, but I just wanted to call it out.

Cheers

Interesting article. Thanks Peter.

Join the Discussion

Asterisks (*) indicate required information.