Project Accountability Model – TL;DR Version

The following is the abbreviated version of the “Project Accountability Model for UI Teams” and captures the key ideas and recommendations for use as a DSIA-based framework.


Many UI and UX design teams exhibit four types of core activities. However, these activities are often conflated under the single umbrella of “design.” This conflation makes it difficult for teams to isolate activity-based roles and, as a consequence, leaves significant gaps in execution and documentation. The Project Accountability Model promotes project-level responsibilities for UI and experience teams with four core activities. When these activities are acknowledged, teams can improve outcomes and be better equipped to account for their efforts.

Recommendation 1: Project Accountability Model for UI Teams advises project teams to explicitly recognize four key activities on any project: Architecture, Design, Engineering, and Production. Additionally, these patterns are shared by technology- and UI-related functions.

This is a critical recommendation since UI-based activities are often narrowly viewed as a design-only activity. To change this dangerous perception, UI and UX teams are encouraged to adjust their vocabulary and perspective for describing their efforts to create and manage effective user interfaces.

Figure-1 Four activities to which technology and UI teams contribute in equal measure.

Recommendation 2: Table-1 describes each project-level activity. It then appropriates a role name for each activity and identifies the expected outcome.

Table-1 Project Accountability Model for UI Teams

Activity Description Participant Name (Role) Outcome
ArchitectureThe collective effort to frame systemic, relational constraints in a way that provides context and reveals an expression for an explicit intent [3].“Architect”Intent
DesignThe collective effort to provide a solution [4] within the respective constraints of architectural intent.“Designer”Solution
EngineeringThe collective effort to rationalize a structure [5] that allows the design solution and architectural intent to instantiate in the intended context.“Engineer”Structure
Production1) 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.“Producer”Product

The following illustration was used in UI Structural Engineering 101. It’s included here to express Recommendation 2 with simpler language and the use of visuals.

UI Architecture
Architecture activity frames project constraints to provide scope clarity and articulate explicit intentions for the project.
UI Design
Design activity is a multi-disciplinary effort that satisfies the intent of architecture and is heavily dependent on structural feasibility.
UI Engineering
Engineering activity assesses contextual conditions and models the appropriate UI structure in support of a target design.
UI Production
Production activity produces the consumable product that’s used by the targeted audience.
Core UI Team Activities for Creating Effective Digital Interfaces
© 2020 Nathaniel Davis | Methodbrain

Recommendation 3: The last proposal identifies familiar UI and experience design practices the provide legitimate sources for accountable documentation. The list of related practices come from the DSIA recommendation for UX Design Practice Verticals.

Area of Accountability Related Practice
UI ArchitectureUX Planning (relates to: Design Architecture, UX Architecture)
UI DesignUser Experience Design, Interaction Design, Visual Design, Content Publishing, Usability Engineering
UI EngineeringInformation Architecture
UI ProductionFront-end Software Development

Read the full-length post for Project Accountability Model for UI Teams.