This post includes a DSIA recommendation for project role accountability.
Application user interface (UI) practitioners  deliver solutions using their creativity, a toolkit of human-centered design methods, and a healthy appetite for technical precision. However, when practitioners work in more complex team environments, they often operate without adequate checks and balances. When this happens, UI teams are disadvantaged when it comes to an essential organizational principle: accountability. In this post, I’ll describe four core activities that are necessary for maintaining UI team accountability in the delivery of digital user interfaces.
Every UI team should aim at being accountable, as in possessing the ability to make the reporting of their actions comprehendible. 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 show in List-1.
List-1 Classic interrogative framing when creating accountable UI documentation
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 properly maintained, assign a leader role (often referred to as 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.
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
While these terms may seem familiar, it’s necessary to clarify their meaning as part of this recommendation  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 that can be classified as 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 a range of 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 .||“Architect”||Intent|
|Design||The collective effort to provide a solution  within the respective constraints of architectural intent.||“Designer”||Solution|
|Engineering||The collective effort to rationalize a structure  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 in accordance with its respective architecture, design, and engineering specifications; 2) the effort by which a product is made.||“Builder”||Product|
To investigate each of 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, the user interfaces that we create 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 in equal measure. 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 begin building 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 sources 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 nascent practice.
This post recommends an explicit practice of UI team accountability. Operating with a sense of accountability has significant implications for how you responsibly create 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/or leadership of multiple activities is their ability to do so in a responsible manner.
- 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.
 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.
 “Collective effort” implies that one or many can contribute to any given project activity.
 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.
 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.
 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.