- DSIA Research
- Posters
- Information Architecture Glossary (DSIA)
- UX Design Practice Verticals Glossary (DSIA)
- What is IA Structure?
- What is IA Structural Engineering
- What is Information Architecture?
- Blog
- Publications
- Educational
- DSIA Research
- Posters
- Information Architecture Glossary (DSIA)
- UX Design Practice Verticals Glossary (DSIA)
The Architecture Risk Principle and the Value of the Design Architect
If you are a digital product owner or manage a UX organization, you must consider the architecture risk principle (ARP). ARP correlates to a widely known statistical probability called the Pareto principle. The Pareto principle, commonly referred to as the 80–20 rule, states that, for many events, roughly 80% of the effects come from 20% of the causes. Likewise, the architecture risk principle asserts that architecture activities for any given project represent 20% of the effort but affects roughly 80% of the subsequent collaborative efforts for design execution.
As a result, sound digital architecture activities can mitigate up to 80% of a project’s risk—leaving design resources responsible for the remaining 20%.
Why Complex Projects Struggle at Execution
Design activities must naturally confront risks that a lead architect cannot anticipate. Hence, design managers and their respective teams share accountability for domain-specific risks (roughly 20% of a project’s total risk).
However, when teams forego formal architecture activities and lead with iterative design execution, the responsibility of risk placed on design managers and their staff (including software developers) increases by 400%. This drastic and unrealistic transfer of responsibility usually goes unacknowledged and is a reason why many projects fail or fail to meet expectations.
The “canary in the coal mine” for projects often manifests as a tense exchange between team members to gain clarity and direction while simultaneously attempting to articulate a solution under fixed time constraints. Consequently, team resources get redirected to activities and documentation that fall into the realm of architecture.
“…the responsibility of risk that’s placed on managers, designers, and developers actually increases by 400%; the crushing weight of this assumed responsibility is why projects fail.”
When formal architecture activities take a back seat to design and engineering activities, talented managers, designers, and software engineers will naturally close architectural gaps to satisfy their narrower interests. As a result, the patchwork-like architecture will likely fall short of being a reliable foundation for future complexity and scale.
Common Warning Signs of Architectural Gaps
- An architecture lead (role) is not assigned.
- No one has been assigned the responsibility of modeling the UI structure (information architecture)
- Team members find it challenging to identify firm objectives
- Ambiguous scope creates more questions than answers for designers and developers
- Lack of UI- and UX-specific key performance measures
- The absence of a shared vocabulary for discussing key project activities and deliverables
Architecture Promotes Clarity
The architecture establishes a frame of reference for which owners, designers, and technology teams collaborate to render an optimum solution. Translating owner intent and documenting a synthesized rationale across a wide range of factors are essential for a design architect.
Architects maintain the systemic view to guide design teams and keep them on task effectively and are the most senior advocate of design and planning.
While hiring a design architect is not required for every project, organizations must do a better job of determining when to employ them. When senior UX designers assume an architecture role—which will happen more often than not— it’s crucial to communicate the extended responsibility to the owner and team. When the organization faces a future scope that warrants an exclusive architecture resource, the team and owner will be familiar with the value of the role.
What is a Design Architect?
If the “design architect” phrase sounds unfamiliar to you, it’s because I’m formally proposing it here. I originally introduced the idea of design architecture in a 2015 article called “A New Architecture for Information Systems. It reads:
“A design architect is a seasoned facilitator of user experience planning, UX design, and is the operational lead in the creation of application user interfaces. They are relied upon to help rationalize the phases of user engagement, design approach, and expertly promote scope alignment in preparation for the architecture, design, and engineering activities of application user interfaces.”
Overall, “the design architect is not the champion for the users; they are the champion of the business (owner) and the user. Striking a sustainable (via process and governance) and equitable balance between the two is the strategic responsibility of the design architect.”
A design architect is a seasoned facilitator of user experience planning, UX design, and is the operational lead in the creation of application user interfaces.
In Summary
- The cost of poor architecture is real.
- Teams lose valuable time iterating over ambiguity.
- Design and engineering contributors become overextended.
- Products meet their untimely demise due to significant gaps in systemic thinking.
Consider adding a design architect role to your next project. When architectural discipline is incorporated into the UI design process, digital teams will improve time-to-market cycles, bring greater focus to team contributors, and deliver sustainable user and business value.
Share this:
- Click to share on Facebook (Opens in new window)
- Click to share on Twitter (Opens in new window)
- Click to share on LinkedIn (Opens in new window)
