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.
Summary:
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 better 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 | 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 |
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.
Recommendation 3: The last proposal identifies familiar UI and experience design practices that provide legitimate sources for accountable documentation. The list of related practices comes 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.
Comments are closed