razor-pages-ui-design

name	razor-pages-ui-design
description	Design or refine server-rendered ASP.NET Core Razor Pages and MVC view experiences. Use for page structure, workflows, forms, tables, responsive behavior, interaction states, visual hierarchy, or choosing suitable UI components and patterns; not for Blazor-only component work.

Razor Pages UI design

Help shape a clear interface before or alongside implementation. Treat the user's goal and the project's design authority as primary; this skill supplies judgment, not a house style.

Start with the actual product

Inspect the relevant pages, shared UI, styles, scripts, screenshots or designs, and governing documentation. Establish:

• who uses the interface and what they are trying to complete;
• the important information, decisions, actions, and consequences;
• existing layout, component, vocabulary, and responsive conventions;
• required states such as initial, loading, empty, validation, success, partial, stale, unavailable, and failure;
• explicit accessibility, browser, device, branding, and performance constraints.

Do not invent personas, product requirements, breakpoints, or a new design system to fill gaps. State a small assumption when one is needed.

Design the experience

• Organize the page around the user's task and decision order, not the data model.
• Make primary information and actions easy to find; keep secondary detail available without competing for attention.
• Use familiar controls and semantic structures. Add custom interaction only when it materially improves the task.
• Preserve information and actions across supported widths and zoom. Reflow or reorder before hiding.
• Define feedback and recovery for realistic waits, invalid input, conflicts, failures, and destructive actions.
• Consider keyboard, screen-reader, pointer, touch, reduced-motion, forced-colour, and contrast needs as part of the design rather than a later decoration pass.

When several approaches fit, present two or three meaningful options with their tradeoffs and recommend the best fit for this context. Do not present a preference as a universal rule.

Components and patterns

Reuse an existing, tested project component when it serves the same need. Adapt it when the context differs. Propose a new local component or external library only when the current parts cannot meet the requirement proportionately.

For deeper design criteria and component guidance, read references/ux-and-components.md.

Deliverable

Provide enough for implementation: intended flow, page regions, component choices, important states, responsive behavior, accessibility considerations, and unresolved product decisions. Match detail to the size of the change.