Website design specification: interface states before development

In the mockup, the enquiry form looks complete: fields, a button and a neat heading. But during development, it turns out that no one has agreed on the error messages, the wait for a response or resubmission. A website design specification is needed precisely for these moments: it explains how the interface behaves under different conditions, not just how it looks in the ideal case.

Before coding begins, it is worth agreeing on a set of scenarios, states and transition rules. Then the business owner understands the scope of the work commissioned, the designer hands over decisions without hidden assumptions, and the developer does not have to decide how the product should behave on their own. Below is a practical way to assemble this package without unnecessary documentation.

1. Separate design decisions from attractive screens

Design handoff means passing on agreed interface rules along with the mockups. A screen shows a particular moment. The specification adds the conditions: what triggers an action, what data is needed, what the person sees while waiting, and how they resume work after a failure. For the business, it matters that these decisions are not made by chance while the layouts are being implemented.

Start with the user's outcome: find a service, compare options or submit an enquiry. For each journey, specify the initial condition, the next action and the indication of completion.

This document is not a request for selecting an agency. If you are still comparing providers, the article on RFI, RFP and RFQ for choosing a contractor will be useful separately. Here the decision is different: exactly what information the team needs before implementing a design that has already been defined.

2. Build a state matrix, not a collection of copies

Interface states describe a component's response to a situation. For a field, these include an empty value, input, focus and an error; for a list, loading, results, no results and failure. Not every block needs every variant. Choose those that can actually occur in the agreed scenario, and explain why the others do not apply.

Separate appearance from behaviour

A button's hover colour does not explain whether it can be clicked during a request. Likewise, a loading indicator drawn in a mockup does not define when it disappears. Beside the visual variant, record three things: the event that triggers entry into the state, the available actions and the exit condition. If the response depends on the server, flag that dependency for discussion with the developer.

For recurring elements, one source of rules with links from the mockups is enough. A separate screen is needed where the composition or journey changes.

Do not conflate different reasons for empty states

“You have no saved products yet” and “No results match these filters” call for different actions. In the first case, a link to the catalogue is appropriate; in the second, changing the search criteria is. Unavailable data should not be displayed as zero results: it has a different cause, needs different wording and may require a different way to retry the request.

3. Document messages, focus and resuming work

Do not leave error copy until the end of the project. The specification needs the actual wording, where it is displayed and when it appears. For an email field, “Enter an address in the format [email protected]” is more useful than “Invalid value”. The validation format must follow the agreed data rules, not an arbitrary limitation of the mockup.

In its explanation of WCAG criterion 3.3.1 on error identification, W3C states that an automatically detected input error must be described in text and the item in error identified. A red border can supplement the explanation but cannot replace it. This is a specific requirement for an error, not confirmation that the entire website is accessible.

Define keyboard focus behaviour separately: focus is the current element a person interacts with without a mouse. Where does it move after opening a dialogue, closing a window or an unsuccessful submission? Show the visible highlight in the mockup and describe the expected path in a note. The final solution is checked in the implemented interface.

A message such as “Saved” or “No results found” may appear without navigating to another page. WCAG 4.1.3 on status messages explains how such changes must be programmatically available to assistive technologies without necessarily moving focus. Do not require the same announcement for every change: the way it is announced depends on the context and importance of the event.

At the design stage, it is enough to specify what message the person should receive and whether their work should be interrupted. The developer determines the technical approach, and the tester checks the result. For a broader context, see GL.ua's article on accessibility-focused design; a state specification covers only part of this task.

4. Walk through a hypothetical quote request

A hypothetical example: a company accepts furniture quote requests through its website. The visitor selects a product type, leaves contact details and adds a comment. The business goal is to receive an enquiry that can be answered. This is a learning scenario, not a description of a GL.ua client or result.

From click to confirmation

Before submission, the form displays required fields and hints. If the contact field is empty, a specific explanation appears beside it after a submission attempt. The comment stays in place. The WAI guidance on form notifications presents approaches to an overall error summary and explanations beside fields. The specification defines the combination needed for this form rather than copying all the options at once.

If local checks pass, the button switches to the “Sending” state. In this hypothetical solution, another click is unavailable until the current request is complete. It must be agreed separately whether fields can be changed while waiting and which entered values will be retained after a failed attempt. The button's visual state does not, by itself, define these rules.

If the server confirms that the enquiry has been created, show “Request sent” and the agreed next step. If the connection drops and the outcome is unknown, do not say “The enquiry was not created”: the interface does not know that. Separate wording about the lack of confirmation is needed, along with an agreed way to establish the outcome. The team defines the retry mechanism in conjunction with the server-side implementation, not just in the design.

5. Check content and responsiveness before layout implementation

A mockup with short headings does not show what will happen with a long service name or a multiline error. Add examples of structurally realistic content: a long name, a missing image and several messages in a form. For each complex block, agree on wrapping, truncation and a way to read the hidden content in full.

Describe responsiveness as reflow rules, not just a “desktop–phone” pair. Specify which elements change order, what remains visible, and how tables and long lists behave. The team chooses precise width breakpoints to suit the content and components. Check intermediate sizes separately: two agreed screens do not describe every situation between them.

For a multilingual website, check texts of different lengths. Specify the source of the fonts, the available styles and the rules for icons. Exported assets must match those used in the mockup.

6. Agree on the package and work through the numbered checks

Design readiness criteria should be based on whether the scenario can be implemented, not on the number of pages drawn. The minimum package includes a journey map, a library of recurring components, a state matrix, copy, responsive rules and a list of open questions. Each question needs an owner and a decision: resolve it before the start or explicitly defer it beyond the current scope.

Before development begins, work through the prototype checks below. Before the website launches, repeat the same scenarios in the implementation: a clickable mockup does not prove that messages, transitions and data handling work correctly.

1. Follow the main journey from its initial condition to a confirmed outcome.
2. For each action, check waiting, success and failure. Find states with no exit.
3. Insert long and missing values, and check several form errors at the same time.
4. Follow the journey on a narrow and an intermediate-width screen. On the finished website, also check keyboard interaction and the announcement of important messages.
5. Compare the mockups, copy and component library. Resolve inconsistencies and establish one version for implementation.
6. Record unresolved dependencies and agree on which ones block the start. Before the public launch, verify that they have been resolved in a working scenario.

Use a separate plan for acceptance of the finished product. The article on corporate website acceptance concerns the next stage. Design handoff defines what is expected, while acceptance checks what has actually been delivered; these procedures are related, but neither replaces the other.

7. Assess timelines, cost and the risk of excessive detail

Preparation time depends on the number of distinct scenarios, content readiness, component complexity and the speed of approvals. First clarify the business rules, then work through the main journey and exceptions, and then agree on responsiveness and the handoff package. Work can proceed in parallel, but result messages should not be finalised until the result itself has been defined.

Break the cost down into scenario research, prototyping, visual design, components, state copy, responsive variants and a review with the developer. Clarify costs for fonts, illustrations or collaboration tools separately, if they are needed. Keeping the specification up to date as changes occur also takes time. Without this breakdown, a lower estimate may simply mean a smaller handoff scope.

The biggest risks are conflicting versions, unagreed server responses and requirements that emerge after the start. Record the package date and version, and describe changes in terms of their impact on scenarios, mockups and checks.

There is no need to draw a screen for every theoretical combination. An informational page without forms may need only concise component and responsive rules. Work through the details where a person enters data or could lose progress.

An agreed design package makes changes visible before coding. Send GL.ua (Glyanets) a list of the main scenarios and your existing mockups to discuss website development and agree on the scope of design preparation for implementation.