Screen

Origin & evolution

The screen as a design unit grew with the graphical user interface. Once Xerox PARC and then the Macintosh established windowed, page-like interfaces, designers worked in terms of discrete views a user moved between, and the practice of designing screen by screen became the default. The web reinforced it: a site was a set of pages, each with a URL, and the page-as-unit assumption🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference → carried straight into early app design.

The thinking matured by demoting the screen from the centre of design. Two developments pushed in the same direction. Atomic design treated a page as the assembly of smaller components rather than a hand-drawn one-off, so a screen became a composition of reusable parts. Journey and flow mapping placed the screen inside a larger sequence, so a screen was understood as one state in a user's path, not an island. The recurring anti-pattern the field now names explicitly is "screens without journeys": isolated views that look fine in a portfolio🧸PortfolioPortfolioA grouping of products by strategic axisView reference → and fail in use because nobody mapped how a person arrives, what they came to do, and where they go next.

Cooper, Reimann, and Cronin's About Face pressed the same point from the direction of goal-directed design: screens should be organised around what users are trying to accomplish, not around system functions or feature⭐FeatureProduct SpecificationA product capability or featureView reference → lists. By that reading, a screen without a clear user goal is a misdesign at the root, not merely a navigation problem.

Modern practice also separates a screen from its states. A login screen is one route, but it has an empty state, a loading state, an error state, and a success state, and designing only the happy path is how products ship that break the moment reality diverges from the demo.

Wathan and Schoger's Refactoring UI makes the practical case for this directly: a screen designed only in its ideal populated state will look polished in a handoff and expose its gaps the moment real users hit it with missing data, slow connections, or failed requests. Empty states are one of the book's named design problems, and their guidance treats every state as a first-class design problem, not an afterthought.

How it works in practice

A team is building a billing area. They define a screen🖥️ScreenExperience DesignA distinct screen or view in the product with route /settings/billing, viewport responsive, access level authenticated, purpose "view and change the current plan". On its own that is a static fact. The value appears when it connects: user_flow_routes_through_screenUser Flowroutes throughScreenhierarchy places it on the upgrade path, screen_navigates_to_screenScreennavigates toScreenhierarchy links it to the payment-method screen it leads to, and screen_renders_design_componentScreenrendersDesign Componenthierarchy ties it to the plan-card and button components it is built from. Now a question like "if we deprecate the legacy plan card, which screens break?" is a graph query, not an archaeology project. The screen has gone from a picture to a node with known dependencies⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → upstream and down.

Screen vs. its neighbours

• Wireframe is a proposal for a screen, an early low-fidelity draft. The screen is the durable thing the wireframe argues for; screen_wireframed_as_wireframeScreenwireframed asWireframehierarchy connects them. Many wireframes can precede one shipped screen.
• Screen state🔳Screen StateExperience DesignA specific state of a screen (e.g., empty, loading, error)View reference → is a variant🆎VariantGrowthA variant in an A/B testView reference → of one screen: empty, loading, error, populated. The screen is the route; the states are what it renders under different conditions, via screen_renders_as_screen_stateScreenrenders asScreen Statehierarchy.
• User flow🔀User FlowExperience DesignA navigation path through the productView reference → is the sequence that strings screens together. A screen is a stop; the flow is the route. A screen with no flow is the anti-pattern the discipline warns against.
• Page in a content sense is editorial: an article, a marketing page. A screen is an application view defined by route and function. They overlap on the web and diverge sharply in apps.

In the graph

In the Unified Product Graph, screen🖥️ScreenExperience DesignA distinct screen or view in the product is a leaf in the Experience Design domain of the Experience, Design & Brand region, anchored under the user journey🛤️User JourneyExperience DesignAn end-to-end map of a user experienceView reference → it belongs to. It is unusually well connected for a leaf: outbound it renders as screen states (screen_renders_as_screen_stateScreenrenders asScreen Statehierarchy), renders design components🧱Design ComponentDesign SystemA reusable UI componentView reference → (screen_renders_design_componentScreenrendersDesign Componenthierarchy), navigates to other screens (screen_navigates_to_screenScreennavigates toScreenhierarchy), and surfaces features (screen_surfaces_featureScreensurfacesFeaturecross-domain); inbound it is routed through by user flows (user_flow_routes_through_screenUser Flowroutes throughScreenhierarchy) and belongs to a product via product_contains_screenProductcontainsScreenhierarchy. That density is deliberate. A screen is where the experience region meets the design system🧰Design SystemDesign SystemThe root design system entityView reference → (the components it renders) and product delivery (the features it surfaces), so it serves as a junction the graph can traverse in several directions.