Planes of UX
In "The Elements of User Experience", Jesse Garrett laid out 5 planes of UX design. Building from Strategy at the bottom layer up to Scope, Structure, Skeleton, and Surface as the final plane. In the second edition, he augmented the planes to discuss “product as information” and “product as functionality” and included things like functional and content requirements, information architecture and information design.
While this model has helped many gain a better understanding of how design could be engaged throughout the development lifecycle—since his planes follow somewhat the steps in product definition to delivery, overall I have found it to be gross oversimplification especially when trying to apply it to enterprise software.
I can’t help but be reminded of Edward Tufte’s quote: “Confusion and clutter are failures of design, not attributes of information.”
Wild West Wanna-Be Rides the Planes of UX
But I have to be honest, I always found this model a little confusing—which is ironic given the man professes to have invented user experience design.
My confusion starts with its separation of functionality from information. I have been at this for a long-time and I have no idea what “product as functionality” or “product as information” means. (And yeah, I read the book).
For the novice, applying the functionality-oriented vs. informational-oriented to websites like this one, that the provide content, verses websites like this one that provide functionality to write and publish the content…. Oh wait, that’s not right…
Maybe he means informational-oriented websites like the NYT? Where you can read articles and don’t forget the NYT Cooking site, that has great recipes that allows you set preferences, alerts, save recipes, even build shopping lists with on-click functionality… shit. I did it again.
Yeah I have no idea what he means.
For web apps, their functionality is based on the ability to input, manipulation, and output information. Information is the key part of making the interaction work.
The confusion only grows when when you move down through his planes. It frankly makes no sense to bifurcate things like interface design vs. navigational design, interaction design vs. information architecture, let alone functional and content requirements.
I think this failure of articulation explains why so many who site Garrett’s work typically just use the five planes themselves: Strategy, Scope, Structure, Skeleton, and Surface. At least those make sense, well except maybe skeleton, and structure…
“The scope is given structure on the functionality side through
interaction design, in which we define how the system behaves
in response to the user. For information resources, the structure is
the information architecture: the arrangement of content elements
to facilitate human understanding.”
from “Elements of User Experience Design”, page 30
Those are the same thing.
How the system responds is part of facilitating human understanding. You cannot separate those two things, its core to how human learn. We experiment; we try something see what happens, and then do it again to see if the same thing happens. This is why babies love peekaboo, or toddles repeat the same joke infinitely if it makes an adult laugh, or why adults use keyboard commands from one app in another app. Its trial and error.
But back to the thread…
But taking a step back, even just looking at the five plane I never felt it captured the complexity of designing enterprise solutions. So I expanded these five layers to seven in order to provide more clarity around systems that require compliance and governance. And to take into account the variability that comes when platforms are used in multiple industries each with different user roles, each with their distinct needs, using the same system to accomplish different tasks.
Enterprise software is very different from consumer apps, everything from how they are build for reliability and scale, to how they are purchased, deployed and maintained. Enterprise software is a completely different animal from consumer software. This has been my model for the planes of UX in enterprise:
Visual Design / Surface — How the product looks and feels
This layer defines the aesthetic and visual clarity of the product (i.e. typography, color, spacing, iconography, layout, etc.). In enterprise software, this isn’t just about appeal—it’s about legibility, scannability, and building trust across complex data systems and working a diverse set of environments. The design must scale from high level dashboards down to detailed views and troubleshooting, balancing brand presence with user efficiency.
Terminology & Instructions — How meaning is conveyed
This layer addresses the language of the product: not just labels, tooltips, error messages, etc. But also any domain specific terminology, onboarding copy. instructional text etc. that has to be designed with the users’ learning curves in mind—what is initially helpful quickly becomes clutter. Clear, consistent terminology is essential in enterprise software, where domain-specific language (e.g., healthcare, finance, logistics) must be precise, localized, and role-appropriate. Great information design reduces training time and boosts confidence.
User Interaction, Design Patterns — How people engage with the system
This includes controls, workflows, and design patterns that support predictable, learnable interactions: forms, filters, tables, modals, and navigation patterns. In enterprise contexts, design patterns must serve both routine efficiency and complex, multi-step tasks, adapting to the skill level of technical and non-technical users alike. Consistency gives way to predictability, and warnings & confirmations are frequently seen as inconveniences.
Information Architecture — How content and functions are organized
This structural layer defines how information is grouped, labeled, and made discoverable. It accounts for hierarchy, taxonomy, navigation structure, and data relationships. In enterprise products, this enables modularity, scalability, and vertical customization, ensuring that complex systems remain navigable and coherent for diverse roles with varying levels of access to the system’s functionality.
Functionality & Usefulness — What the product does and how well
This is the layer of capabilities, utility, and value delivery. It ensures that the product solves the right problems through meaningful features. In enterprise markets, this requires alignment with customer workflows, compliance needs, and evolving industry standards—ensuring extensibility, reliability, and relevance over time. In many cases the users of these systems know as much as the people building them about the capabilities of the technologies being used to build the products, and they have expectations about how they will be able to leverage those capabilities.
User Roles, Needs, and Goals — Who it’s built for
This layer defines how the product adapts to different job functions, and subsequently different workflows. Enterprise systems must support multi-user environments: admins, approvers, analysts, executives, and more. Each role brings distinct needs & goals as well as permissions. This layer drives customization, personalization, and role-based experiences that increase engagement and satisfaction.
Product Strategy — Why the product exists and where it’s going
The foundational layer that aligns business vision, market opportunity, and customer value. It typically relies heavily on things like ARR rather than one time payments. The business value is based more on enablement (i.e. number of documents processes, inventory management, etc.) rather then engagement (i.e DAU/WAU). It defines success metrics, prioritizes investments, and informs vertical-specific differentiation (e.g., HIPAA compliance in healthcare, auditability in finance). Strategy ensures every layer above is coherent, purposeful, and built to support growth and change.
5 to 7 Planes
Being able to approach the enterprise solution with greater granularity and clarity is critical to ensuring designs’s success.
Garett’s Five Layers:
Surface — How the product looks and feels. This layer focuses on visual elements like typography, color, and imagery. Its purpose is to ensure the product is aesthetically appealing and easy to understand.
Skeleton — How users interact with and navigate the product. This layer focuses on interface elements such as buttons, menus, and navigation systems. Its purpose is to optimize usability and streamline user flow.
Structure — How features and content are organized. This layer defines the underlying framework of the product, arranging information and functionality into a coherent system. Its purpose is to support intuitive interaction and information access.
Scope — What the product includes—and excludes. This layer translates strategic objectives into specific features and content. Its purpose is to define the product’s functional boundaries and capabilities.
Strategy — Why the product exists. This foundational layer defines the product’s goals by aligning business objectives with user needs. Its purpose is to establish a clear vision for success.
