“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:
- 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
- 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:
- content requirements—which describe the various content elements in the component
- information architecture—which describes the arrangement of content elements within the information space
- interface design—which describes how the interface elements enable users to interact with the functionality
- interaction design—which describes the workflow and behaviors of the user interface
- 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.