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.
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|
|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.||“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.
Architecture activity frames project constraints to provide scope clarity and articulate explicit intentions for the project.
Design activity is a multi-disciplinary effort that satisfies the intent of architecture and is heavily dependent on structural feasibility.
Engineering activity assesses contextual conditions and models the appropriate UI structure in support of a target design.
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 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|
Read the full-length post for Project Accountability Model for UI Teams.