If you work in a digital-design organization that collaborates with technologists, product owners, and business stakeholders, it’s highly likely that your design team’s full contribution is not well understood. This needs to change.
In this article, I’ll explain why having a firm conceptual foundation for an application user interface is an essential step in achieving digital maturity, as well as the reason why many design leaders are managing more than design.
Champion Advertisement
Continue Reading…
Alignment
As an information-architecture analyst, an essential aspect of my work is helping teams establish conceptual alignment. Over my career, I’ve observed how organizational ambiguity impairs a team’s ability to align and deliver reliable digital communications, products, services, and tools.
Digital-design teams that inherit organizational ambiguity are prone to periodically experiencing process-reengineering efforts. Although such efforts might have good intentions, they often position the digital-design practice within a surrogate department such as marketing or technology. In other cases, the design team might adopt questionable processes or engage in unsustainable design practices that product-, technology-, or data-driven objectives prescribe.
The relationship between user interface–design practices and traditional software development is not as formal as newcomers to the field of User Experience might expect. This ill-defined connection likely results because institutions of higher learning do not generally teach software development and human-computer interaction (HCI) as integrated disciplines. Plus, they often teach other practices such as UX design, interaction design, visual design, usability engineering—UX research and testing—information architecture, content strategy, experience planning, and analytics independently of one another. These practices are also relevant in optimizing the way people interact with computing devices.
Furthermore, insights—or the lack thereof—from the humanities, social sciences, and psychology are deeply rooted in both the most successful and failed application user interfaces. This convergence of practices, disciplines, and sciences exacerbates the challenge of getting entire product teams on the same page. To help solve this problem and provide a path forward, I’ll share my proposal for an approach to alignment.
In 1984, the International Organization for Standardization published its recommendation for computer networking, The Basic Reference Model for Open Systems Interconnection. The specification included a reference model that segments the core aspects of network computing into seven layers. These seven layers are popularly known as the OSI (Open System Interconnection) Model. Although the OSI specification speaks primarily to the interests of software engineers, it briefly acknowledges a scenario for human interaction, which happens exclusively at the model’s application layer, as Figure 1 shows.
Figure 1—The seven-layer Open System Interconnection model
At the top of the OSI model sits a software application [1] and its technology infrastructure, which must deliver reliable functionality to the OSI environment. The application is also responsible for instantiating a user engagement through a deliberate session and communication mode.
Any data that an application transmits through the application layer should be meaningful to its intended recipient—that is, a computing system or a human user. As a result, the application layer is the gateway to application functionality and communications across a network.
Within an OSI environment, two primary types of application interface functions [2] transmit data through the application layer, which “include functions performed by programs [and] functions performed by human beings”:
Application Human-User Interface (AUI) Functions
Application Technology Interface (ATI) Functions
The services of the application layer’s primary application interface functions must maintain parity as they manage their respective systems of logic, communication, and interaction. Figure 2 depicts the two primary interfaces of the application layer.
The success of an application is traditionally a measure of technology-based functionality. When an application’s technology interface performs as prescribed, the technology team considers it a success and proceeds to building the next set of functional improvements. This approach to measuring application success is sufficient for communications that occur solely between computing systems. However, when the performance of an application depends on human interaction, success criteria should correlate to both technology and user-interface assessments:
Application User Interface Assessment—Verify that you’ve achieved reliable contextual integration, optimal usability, and performance.
Application Technology Interface Assessment—Verify that you’ve achieved reliable information systems integration, software functionality, and performance.
Organizations have innovated information systems, software, and networked computing for decades, but continually use less rigorous measures when adopting standards and protocols for human-computer interaction. However, the fact is that, if we fail to apply sound human-computer interface practices and operational protocols or to responsibly account for and document such activities, the application as a whole fails. [3]
Creating a technology interface requires an extensive range of organizational activities. Therefore, the organizational practices that support the application UI functions must be equally robust. As Figure 3 shows, teams should measure application success against the intended performance that the technology-interface and user-interface functions deliver.
Figure 3—Technology-interface and user-interface functions
We’re Not All Designers
I’ve used the terms design and design team liberally in this article. However, for digital-design teams to maximize their contribution to their organization, it’s essential to be clear on how to contextualize design within a broader system of collaborative activities.
As I’ve shown, the application technology interface is a niche function within the OSI model, in which the application user interface is its counterpart. There are no standard guidelines for implementing the UI function. However, if the UI function shares equivalence with the technology function, as I argue here, UI activities would likely correlate to technology activities. [4]
Based on my recommendation for a project-accountability model, we should expect mature application UI organizations to provide more than design activities. They must also consider defining their own set of activities for UI architecture, UI engineering, UI design, and UI production. [5]
The project-accountability model that I propose does not refer to design as a profession. Instead, it abstracts design as activity that renders a unique outcome in relation to other core activities, as shown in Table 1. For relatively small design efforts, this distinction often gets lost; for larger, more complex efforts, people often mistakenly conflate them under the banner of design. This oversimplification impairs the entire industry in its effort to create meaningful, sustainable user interfaces at scale. And as we know, everything in our digital landscape is scaling.
Table 1—Project Accountability Model for UI Teams
Activity
Description
Common Title
(Role)
Outcome
Architecture
The collective effort of framing systemic, relational constraints in a way that provides context and expresses an explicit intent.
Architect
Intent
Design
The collective effort of providing a solution within the respective constraints of architectural intent.
Designer
Solution
Engineering
The collective effort of rationalizing a structure that allows the design solution and architectural intent to instantiate within the intended context.
Engineer
Structure
Production
The collective effort of instantiating a design solution as a concrete object for use in accordance with its respective architecture, design, and engineering specifications; and the effort of making a product.
Builder
Product
The project-accountability model suggests that the design activity alone has a limited scope and is not a panacea for creating optimal application UI functionality. Instead, the industry should consider promoting design as one of four key project-level activities to which both the information technology (IT) and UI organizations contribute. As Figure 4 shows, the technology-interface and the user-interface functions share similar activities for planning and building the application’s functionality.
Figure 4—Organizational practices supporting AUI and ATI functions
Our Intellectual Heritage
For those of you who lead digital design within your organization, you are likely the inadvertent owner of the application user–interface function. Many design leaders and design-operations managers fall into this category. If so, it is your responsibility to make your team’s role more explicit and clear.
When you take on this responsibility, be aware of the conceptual challenge that you help perpetuate in choosing to identify as a Design team. The term design is a conceptually limiting when you’re referring to an organization that’s actually delivering UI functionality. I recommend two not-so-surprising names for a team that is accountable for providing application UI functionality—neither of which is new:
User Interface (UI) team—This designation raises the user interface to its rightful place of prominence and brings the proper focus on the most tangible, core output that enables human-digital engagement.
Human-Computer Interaction (HCI) team—HCI reminds us of who the user interface is for—human beings—and what we intend the user interface to help people to do effectively—interact.
Although human-computer interaction as a term and as an actual area of study best embodies the interests of satisfying the application UI function’s objectives, HCI has lost its association with a professional practice, and most now think of it primarily as an area of academic research. We must reverse this perspective. The Association of Computing Machinery (ACM) has defined HCI as follows:
“Human-computer interaction is a discipline concerned with the design, evaluation, and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them.”
ACM’s definition for HCI makes a strong argument for a unifying professional umbrella for every professional who contributes to the outcome of a digital user interface. If you identify as a UX designer, experience designer, interaction designer, digital-product designer, researcher, information architect, or content strategist, HCI is our shared intellectual origin.
As professional titles have changed to suit market demand and team dynamics have evolved to meet business needs, human-computer interaction has remained the foundational concern in creating application user interfaces.
UI design leaders must explain how other other UI-based activities and their respective disciplines are essential to creating effective user interfaces. I understand that discontinuing the use of design as the umbrella term for creating application user interfaces may be a tall order for some. However, expressing design as one part of a set of core activities would help our technology, product, and business colleagues better understand the depth of expertise that is involved in what we do and make room for discussing other essential, nondesign tasks such as operations, research, experience strategy/architecture, information architecture, content publishing and strategy, and UI structural engineering.
A Recommendation for UI Professionals
The technology interface and the user interface represent the original dichotomy of digital-application functionality. Your digital-design team’s contribution to business value [6] depends on how well you align with technology teams and their objectives in delivering machine-to-machine and machine-to-human communications. Thus, product managers, design managers, and technologists should assess whether their teams are fully delivering responsible application UI functionality.
Here are five aligning principles to consider:
Technology and the human-user interface represent the dichotomy of networked computing.
The user interface is a function of network computing in which human behavior is the central performance dependency. [7]
When an application’s performance depends on human interaction, its user interface is as critical to the application’s functionality as is the technology interface.
A functioning user interface is an expression of architecture, design, engineering, and production activities.
Even if human-computer interaction is not in your UI team’s name, it should be an underlying pillar of your team’s value proposition.
If you already have a shared model that aligns your design team with technology, you’re ahead of the curve! And, if your business and product leaders understand the crucial role of a highly functioning user interface as the essential complement to the technology interface, good fortune awaits you. If not, this article offers a foundational perspective for you to consider.
To promote your team’s maturity and achieve greater alignment with the business, technology, and product teams, consider maturing your design ethos by aligning it with the OSI model and assuming responsibility for ownership of the application UIfunction.
Until we properly value the fact that everything we do ultimately leads to a user interface that augments our human-based communication and our digital communications, our products and services will continue to fall short of their potential to serve humanity. Professionals in the UI field need to participate in discussions about refining an emerging perspective of what design and other core activities mean to digital. Feel free to engage and help move the conversation forward.
Endnotes
[1] Browser-based Web sites, native mobile applications, and productivity user interfaces are common forms of applications.
[3] Application failure can have an impact on many things, including but not limited to business, social, economic, and cultural systems.
[4] My unpublished research in information-architecture theory informs this assertion and shows how we can use it to understand the organizational dynamics of UI design teams.
[5] The terms architecture, design, and engineering correlate to my research in activity-based information patterns. I distinguish these different activities to help teams address role conflation and improve the delegation of essential responsibilities.
[6] This statement assumes that an organization perceives user value as business value.
Nathaniel has over 25 years of experience in human-computer interaction and is a leading advocate for the advancement of information architecture as an area of research and practice. He began practicing information architecture in the late ’90s, then focused on information architecture as his primary area of interest in 2006. He has made a study of information-architecture theory and how that theory translates into science, workable software, and methods that improve human interaction in complex information environments. Nathaniel was formerly director of information architecture at Prudential. His information-architecture consultancy Methodbrain specializes in UI structural engineering. Read More
