This post includes a DSIA recommendation for project role accountability.

TL;DR Version

Application user interface (UI) practitioners [1] deliver solutions using their creativity, a toolkit of human-centered design methods, and a healthy appetite for technical precision. However, practitioners working in more complex team environments often operate without adequate checks and balances. When this happens, UI teams are disadvantaged regarding an essential organizational principle: accountability. In this post, I’ll describe four core activities necessary for maintaining UI team accountability in delivering digital user interfaces.

Traceability

Every UI team should aim at being accountable, as in possessing the ability to make reporting their actions understandable. Sound accountability practices allow organizations to audit project assumptions and the provenance of UI engagement. An effective way to enable such insight is through documentation.

Documentation is a crucial aspect of design team maturity because it promotes traceability. In software development, traceability refers to the ability to track requirements and business rationale to system and software functionality and vice versa. The same is true for UI and experience design teams. For example, journey maps, sitemaps, and wireframes are UI documents that should methodically correlate to a project’s strategic requirements and rationale.

Accountable UI documentation should answer questions that help all parties understand the function and value of a UI solution. Formulating a sound argument can start by applying the centuries-old rubric for investigative inquiry, as shown in List-1.

List-1 Classic interrogative framing when creating accountable UI documentation

• Who…?
• What…?
• Where…?
• When…?
• Why…?
• How…?

The responsibility of an activity lead is to facilitate the process of their respective activity and ensure that the project outcome and supporting documentation meet acceptable standards for accountability.

As projects get larger, it’s necessary to be explicit about the ownership of trace UI documentation. UI-based documentation can be assigned to an individual “leader” or multiple individuals. However, as ownership of accountability becomes increasingly distributed, ownership, and thus accountability can quickly get diluted.

To ensure that accountability is maintained correctly, assign a leader role (often called a “lead”). The responsibility of an activity lead is to facilitate the process of their respective activity and ensure that the project outcome and supporting documentation meet acceptable standards for accountability.

Activities

When considering UI team accountability, it helps to be clear about which activities warrant attention and documentation. I’ve leveraged my research in information architecture science to describe four activity patterns that promote accountability, as shown in List-2.

List-2 Activity patterns for promoting accountability

• Architecture
• Design
• Engineering
• Production

While these terms may seem familiar, it’s necessary to clarify their meaning as part of this recommendation [2] mainly because they are common terms in the digital domain and, more often, promote a counter-productive pattern of exclusion.

For example, if you put business stakeholders, product managers, technologists, and UI practitioners in the same room, it can be assumed that any mention of architecture, engineering, and production refers to a technology-based discussion. Likewise, any mention of design naturally provokes a conversation around the interaction and visual design of the user interface.

In contrast, this post asserts that both technology and UI teams express four activity patterns: architecture, design, engineering, and production. The following recommendation (see Table-1) describes these four activity patterns.

Table-1 Project Accountability Model for UI Teams (DSIA Recommendation)
The Project Accountability Model asserts that four types of project-level activities can be used as criteria for managing accountability. UI teams should integrate accountability practices as a core discipline to satisfy inquiries from various internal and external audiences.

Activity	Description	Related Role Name	Outcome
Architecture	The collective effort to frame systemic, relational constraints in a way that provides context and reveals an expression for an explicit intent [3].	“Architect”	Intent
Design	The collective effort to provide a solution [4] within the respective constraints of architectural intent.	“Designer”	Solution
Engineering	The collective effort to rationalize a structure [5] that allows the design solution and architectural intent to instantiate in the intended context.	“Engineer”	Structure
Production	1) The collective effort to instantiate a design solution as a concrete object for use per its respective architecture, design, and engineering specifications; 2) the effort by which a product is made.	“Developer”	Product

Investigating these activity patterns warrants considerably more discussion than what I intend for this post. However, you can quickly discern the difference between the activities by becoming familiar with the outcome for each (see the last column). Doing so will place you on a clear path.

Applying Accountability in Practice

No matter how small or large the project, our user interfaces have a business and human impact. And the more interfaces we create, the greater the impact. For a profession that creates digital interfaces for human interaction, it’s a practitioner’s responsibility to promote sustainable human engagement.

Establish a baseline for accountable documentation because it’s the responsible thing for a leader to do.

Hence, if you assume a project leadership role, don’t ask for permission to include the necessary steps to promote accountability. Establish a baseline for accountable documentation because it’s the responsible thing for a leader to do.

Additionally, when attempting to put this recommendation into practice, you may have to convince others (i.e., technologists, product managers, stakeholders, and clients) that technology and UI teams exercise the four recommended activities equally. Anticipate resistance, but know that continual education and demonstrable success foster acceptance.

Further, since the four activities can be applied to a wide range of domains, if not all, it’s wise to use a qualifier to avoid confusion. For example, let’s refer to your UI/UX design team as a UI organization. According to the proposed recommendation, your UI organization should consider promoting four practices of project accountability, as shown in List-3.

List-3 Four areas of project accountability for UI teams.

• UI Architecture
• UI Design
• UI Engineering
• UI Production

The good thing about the areas of accountability in List-3 is that the industry already has the depth to build best practices in each area. As a result, practitioners who wish to hone their leadership capabilities should consider building best practices around accountable UI documentation. Table-2 provides a quick reference of disciplines that already generate some form of documentation for the four areas of UI accountability.

Table-2 Suitable practices for accountable UI documentation practices.

Area of Accountability	Related Practice
UI Architecture	UX Planning (relates to: Design Architecture, UX Architecture)
UI Design	User Experience Design, Interaction Design, Visual Design, Content Publishing, Usability Engineering
UI Engineering	Information Architecture
UI Production	Front-end Software Development

There are no authoritative sources for the related practices listed in Table-2. While the academic and scientific pursuits of human-computer interaction (HCI) were birthed with the scenario of human-computer engagement in the 1970s, doing so with formality and accountability as a profession is still a developing practice.

Summary

This post recommends an explicit practice of UI team accountability. Operating with a sense of accountability has significant implications for responsibly creating digital technology. Hence, it’s incumbent on project leaders to maintain proficiency in creating UI documentation that promotes accountability at any scale of operational complexity.

When you include accountability as a core UI practice, you will improve collaboration within technology and product teams and provide the traceability that strategy and business stakeholders require to make sound decisions and meet the needs of customers, employees, partners, and citizens.

I leave you with some additional observations from my research:

• Project activities are interdependent; you can’t effectively perform one without considering the others, no matter how small or large the effort.
• The order in which these activities are listed does not imply a process. However, it does suggest hierarchal dependency.
• An activity role does not necessarily dictate the job title of the person who leads or contributes to a project activity. For example, you can have the title “Senior UX Designer” but participate as a UI designer on one project and lead UI architect on another.
• The person who assumes the lead role for an activity inherits the responsibility to maintain accountability for that activity.
• The only limit to someone maintaining multiple roles and leadership of multiple activities is their ability to do so responsibly.
• The project activities in this recommendation are based on the vocabulary of my research in information architecture science and UI team diagnostics. However, the conceptual distinction between each activity is more important than the labels they are given. So, feel free to name each activity to fit your context.
• Project activity patterns are not limited to user interface and technology teams. They can be mapped to any set of organizational behavior.

Nathaniel Davis is Founder & CEO of Methodbrain, researcher, and information architecture analyst. He advises teams on UI Engineering and how to build strategic proficiency within UI/UX teams.

Notes

[1] The term “Application UI practitioner” includes but is not limited to practitioners of experience strategy, user experience design, usability engineering, user research, information architecture, copywriting, content publishing, interaction design, visual design, and front-end development.

[2] “Collective effort” implies that one or many can contribute to any given project activity.

[3] Architectural intent, as in “the rationalization of two or more reciprocating entities within a domain of behavior.” Source: Nathaniel Davis, DSIA Research. Retrieved January 2019.

[4] Design solution, as in “the outcome of design activity that serves as the representational requirement of an intentionally (with reference to architectural intent) built object.” Source: Nathaniel Davis, DSIA Research. Retrieved January 2019.

[5] Structure, as in “an arrangement and organization of interrelated elements in a material object or system, or the object or system so organized.” Source: Oxford English Dictionary (Online ed.). Retrieved  December 2019.