Web specifications: describe uses rather than screens

Digital project management · 6 min reading

A useful web specification describes who should do what, in what situation and with what expected result. Screens come next, to translate these uses. For a small company, this approach allows above all to compare proposals on a common scope and to verify that the site delivered meets the defined needs.

Key points

• Start with actual tasks, not a list of desired features.
• Associate each priority use with observable validation criteria.
• Specify the exceptions, the data required and the person who decides.
• Keep the models as a discussion support, without making them replace the requirements.

Start from the tasks that the site must allow

“Add a customer area” describes a solution. “Allowing a buyer to find a document related to their order” describes a need. The distinction matters: the second statement allows the possible solutions and their constraints to be discussed, while the first already imposes a form.

The GOV.UK Service Manual recommends describing the user's problem and treating non-user suggestions as hypotheses to be verified. This method, designed for British public services, can also guide company specifications.

Collect situations, not just opinions

Review the requests received by support, business questions and difficulties reported by the team. Have a recent task explained: what was the starting point, what information was missing, how did the person get their answer? Distinguish between documented observations and assumptions. A wish of the manager can remain relevant, but it must appear as a choice to be discussed.

Don't forget internal users. Preparing an order, correcting a product pages or sending a request to the right person is part of the uses to be described, even if these actions are not visible on the site.

Write a verifiable usage sheet

For each priority task, indicate the profile concerned, the trigger, the desired action and its objective. Add the necessary information, the expected result and the special conditions. The GOV.UK documentation on user stories proposes this framework and defines acceptance criteria as results to verify that the need is satisfied.

Define what will allow you to accept delivery

Avoid “the form must work”. Specify what happens when it is sent, what the visitor sees, where the request arrives, and how an error is reported. The criteria describe the expected behavior, without unnecessarily imposing an extension or technology.

Assign a priority to each use: essential for opening, useful but deferrable, or outside the scope. If everything is essential, ask what task can actually wait. Also note the dependencies: product data, access to software or business validation can condition the implementation.

Illustrative example: request a usable quote

This example is fictitious. A professional supplies company wants to receive quote requests for configurable equipment. Its first document only mentions “a quote page with form”.

A formulation focused on usage would be: “As a purchasing manager, I want to transmit the characteristics of the equipment sought so that the company can study my request without making me re-enter everything. »

The validation criteria could be as follows:

• The requester identifies the essential information before sending.
• Missing information is reported without deleting fields already filled in.
• After a successful sending, a confirmation explains further processing.
• The request reaches the designated person with their structured information.
• The team can distinguish a new request from an already supported request.

A mockup can then show the fields and confirmation. It does not prove, in itself, that the request is arriving or that the team knows how to handle it.

Enter constraints and open decisions

Add the constraints that change the possible response: mobile consultation, documents to attach, recipient software, employee rights, available content. For personal data, the CNIL recalls the principle of minimization : the collection must be adequate, relevant and necessary for its purpose. So justify each field instead of repeating a form out of habit.

Separate confirmed requirements from points to be arbitrated. Each open question must have a person responsible and a decision deadline compatible with the project. If the scope changes, record the modification, its reason and its consequences on the implementation before accepting it.

Checklist before transmitting the specifications

• The profiles concerned and their main tasks are identified.
• Observed needs are distinguished from hypotheses.
• Essential uses have acceptance criteria.
• Errors and special situations are described.
• Data, content and dependencies have a person responsible.
• The excluded scope is written, not left implicit.
• The person who validates each use is designated.

Limitations and common errors

A detailed document does not exempt you from discussing the uses with the people concerned. It can even freeze a bad hypothesis if no one checks it. Other errors: copying a competitor's site without understanding how it works, confusing graphic preference and business need, or adding functions without modifying the reception criteria. Include the visual constraints already known, such as the graphic charter or the expected readability, then refine the choices during the design. Describing uses does not mean excluding accessibility, security, performance or maintenance requirements from the specifications. Also make scope changes explicit.

Frequently asked questions

Should we delete the list of pages?

No. It is used to understand the organization of the content. Simply relate each page to the tasks it facilitates, rather than treating it as a sufficient requirement.

Should we already choose a technology?

Only if a real constraint imposes it. Otherwise, describe the uses and necessary interfaces, then ask the service provider to justify their technical choice.

Who must validate the criteria?

The person who knows the business task, with the team who will carry out the tests. The manager arbitrates the priorities, but must not guess the daily functioning alone.

Next step: describe an essential task

Choose a use without which the site would not provide the expected service. Write the form, its exceptions and its criteria, then have it reread by the person who is carrying out this task today. To situate this work in support, consult the web services of 4SYSTEM.

Sources and resources

• GOV.UK: understanding users and their needs.
• GOV.UK: writing user stories and acceptance criteria.
• CNIL: minimize the data collected.