deliverables

In this installment I propose a need for, and an example of, a model for UX architecture. Models allow us to discuss a system without specifying particularities about the system. This is important if we want to understand how the system can be put to good (or better) use. Models also allow us to look at the relationships among various systems, again to improve their operational efficiency, or to determine allocation of resources. Throughout this series, I've looked to Architecture to inform UX architecture. Architecture's political and strategic positioning, its established processes and shared understanding among professionals provide a rich history…

Throughout this series, I've been using Architecture (bricks-and-mortar Architecture, capitalized) as an analogy for UX architecture (lower-case). Because Architecture has "had a seat at the table" for hundreds of years, perhaps we can learn from its success and apply those lessons to UX architecture, thereby increasing UX architecture's strategic value. In the next installments, I turn to more tactical concerns: the deliverables and processes required to execute on a UX architecture. In this piece, I discuss how different stakeholders require very different deliverables. I also discuss how Architecture and UX architecture differ in terms of stakeholder understanding about the desired outcome. Awhile…