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.

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.

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⭐FeatureProduct SpecificationA product capability or featureView reference → (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.