How Do You Write Website Redesign Requirements? From Business Goals to a Feature List You Can Verify

How much detail do website redesign requirements need for designers and developers to understand them accurately? A practical standard is that implementers can understand the problem to solve, those responsible for acceptance can judge whether the work is complete, and the people operating the website afterward know how to use and maintain it.

“Make the pages look more polished,” “make the admin system easier to use” and “increase inquiries” can all start a discussion. Before they become project scope, however, define the users, tasks, content, functional boundaries and completion criteria. A few reference images alone still leave sections, language versions, admin operations and material preparation to be confirmed individually.

The following steps explain how to write a website redesign requirements document in the order of preparation before redesign. An improvement to JVDS Design Studio’s own admin system illustrates how an operational problem can become a verifiable delivery result.

Identify the problem before deciding how much to change

When organizing requirements, first record specific obstacles in the old website. Visitors may be unable to find product information on mobile, different business lines may share one section, or content staff may need to keep opening detail pages to publish articles. With this level of description, the team can discuss whether the problem concerns content, page structure or functionality.

If problems are concentrated on a few pages or one admin task, assess a targeted adjustment first. If business positioning, section structure and maintenance practices have all changed, requiring several pages to change together, consider a complete redesign. Scope should follow the problems; otherwise, time may go into visual updates while the original operational obstacles remain.

“Increase inquiries” also needs further breakdown. Is the inquiry entry hard to find, is service scope unclear, or do submissions fail to enter a follow-up process? These causes require different work. The first two may involve page content and entry-point design; the last requires checking forms, records and notifications. Confirm the current situation before deciding what to add.

This stage is complete when the team can jointly explain who faces which problem, what this project intends to improve and what will remain for now. Judgments without supporting data can be recorded as questions to verify. Check them before expanding the redesign scope.

Prepare materials before redesign to reduce repeated requests for information

Keep the section inventory together with its actual content

When organizing the old website, also list the content belonging to each section: product categories, case study materials approved for publication, service pages needing updates, and who supplies images and copy. A “product center” may contain only a few introductions, or require categories, specifications, downloads and filters. A section name alone rarely defines the work.

Mark the status and owner of content that is not ready. On a bilingual website in particular, approved Chinese content with English still awaiting translation affects page checking and launch arrangements. Delivery can happen in stages, but agree beforehand what goes live in this release, what is deferred and how deferred content is handled on the page.

Record old URLs and routine admin tasks

Before redesign, retain existing page URLs and identify which will stay unchanged, change or be merged. If URLs change, map old addresses to new ones and arrange checks and redirects instead of delivering only a new set of pages. This is also a preparation step in Google’s site migration guidance. URL migration guidance

Organize admin information around work tasks: who updates products, who publishes articles, whether review is needed and which operations are frequently repeated. Involving the actual admin users in confirmation reveals specific needs more effectively than simply listing “a content management system is required.”

Specify how language versions are managed too: whether they are maintained independently or share some materials, whether they are published together and how missing translations are handled. Before delivery, establish who holds domain, hosting and admin management access, and how subsequent handover will work. These arrangements directly affect continued maintainability.

Each redesign requirement should define its task, boundaries and completion criteria

Use this sentence as a starting point for a requirement:

[User] performs [specific action] on [defined scope] in [task context] to obtain [expected result]. Handle [exceptions or limitations] as agreed, and have [owner] confirm completion through [checking method].

“Defined scope” is particularly important. Publishing one article, publishing articles selected on this page and publishing all drafts in the current filtered results are three different operations. The more specific the requirement, the easier it is for implementation and acceptance to use the same criteria.

For a hypothetical inquiry feature, a requirement could state: after a visitor submits the necessary information on a mobile service page, they can see the submission result; the admin system saves the corresponding record; and the designated owner receives a notification. Check the submission message, saved record and notification receipt separately. If the originating page should also be identifiable, include source recording in the scope.

Requirements do not have to prescribe the technical solution in advance. The business first explains tasks and limitations, and implementers assess how to deliver them. If the old admin system should remain, specify which information and operations must be retained and whether new features require migrating existing data, rather than merely writing “keep the existing admin system.”

Use observable results for completion criteria wherever possible. “A good mobile experience” can become: sections expand on the agreed devices, buttons work, forms accept input and submissions, and long titles and tables do not obscure key content. “Deliver the admin system” should define management access, editable content, operating instructions and training scope.

Actual example: turn “publish all drafts” into bulk publishing requirements

This improvement to JVDS Design Studio’s own admin system began with a request to publish all existing draft articles. After further confirmation, the requirement became a reusable multi-selection publishing feature so content staff could continue handling articles by defined scope.

First define selection scope. Selecting one article, selecting the entire current page and selecting every draft in the current filtered results need separate wording. “Select all on this page” covers only the visible page, whereas selection across pages may include articles not currently displayed. Showing the selected count before execution lets users verify the scope.

Article states are another boundary. Requirements need to cover how published content appears, whether it can be selected again and whether the button is available when filtering returns no drafts. The same multi-selection button becomes a sustainable workflow only when these states are addressed.

Publishing Chinese and English together also has conditions. Both can be published when the English materials are complete. If they are insufficient, specify whether Chinese publication continues, what state English retains and how missing content is flagged. “Bilingual support” cannot replace these rules.

Bulk operations also need progress and result feedback. If some items are not completed, users should be able to identify those items and the reasons, then verify or continue handling them. Consider these exceptions during requirements review instead of confirming only the buttons and messages shown after a normal completion.

After this operation was completed on the live system, the results showed that 385 Chinese articles and their 385 corresponding English versions had been published. Refreshing the list showed 0 remaining drafts. Acceptance checked both the execution result and the actual state after refresh, giving “published” a verifiable basis.

Apply this example to tasks such as bulk product editing and material imports: when writing requirements, consider selected items, execution scope, state restrictions, exception handling and result checks together. They determine whether the feature genuinely suits routine use.

Set priorities and agree how to verify delivery and handle changes

Define the current scope by business dependencies

When prioritizing requirements, discuss three questions for each: can the core task be completed without it, does it affect several pages or workflows, and are the materials and conditions needed to implement it available?

Prioritize problems that prevent core tasks, such as inquiries that cannot be saved, product information that cannot be updated or existing content that cannot be accessed normally. Schedule visual details and infrequently used features around the launch plan. Give a reason for every deferred requirement so both parties understand the same scope during acceptance.

Late materials also need handling rules. If product copy, translation or approval is unfinished, define whether the affected page is deferred, who supplies the materials and when checks will be rescheduled. Confirm the conditions on which the launch date depends when planning the schedule where possible.

Use acceptance records to check delivery and ongoing data to observe outcomes

Run acceptance through real tasks: log in with the agreed role, edit one content item, complete a publication or submission and check the result. Keep brief records for key requirements, identifying what was tested, problems found, handling status and the confirmer. When issues occur, describe the conditions so implementers can reproduce the checks accurately.

Beyond page and admin checks, confirm the agreed deliverables: editable design files, source code, content materials, account permissions and operating instructions. Different engagement models may cover different deliverables. Record them in the checklist beforehand instead of reopening the discussion at the end of the project.

If the goal includes increasing inquiries, record existing page visits, inquiry counts and how valid inquiries are assessed before redesign. Continue observing under the same definitions after launch, while recording changes such as channel investment and content updates. This supports discussion of factors that may affect results instead of directly attributing inquiry growth to one interface change.

When requirements change, record the additions, reasons, affected pages or features, and effects on scheduling and acceptance, then confirm whether they belong in the current scope. Put the agreed decisions in the same requirements document so different people do not each retain a separate version.

To begin preparing for redesign, gather the old website’s URL inventory, specific problems and a draft task list. Check each item: do implementers know what to do, do those accepting the work know how to check it, and do content staff know how to maintain it afterward? Anything still unclear is a requirement to clarify in the next round.

Frequently asked questions

Does a website redesign requirements document need to sound highly technical?

No extensive technical terminology is needed. Defining users, tasks, scope, expected results and acceptance methods is more useful than listing feature names. Implementers can assess unresolved technical options before both parties confirm them together.

If the old website has few problems, does it still need a complete redesign?

Check the impact first. If only a few pages or one admin task are involved, assess a targeted adjustment. Consider a complete redesign when sections, content and maintenance practices all need to change together.

Can the existing admin system remain during redesign?

Assess whether it can support the new content, operations and permission requirements. List the information and workflows to retain in the requirements, and have implementers confirm extension conditions and migration scope.

Can a multilingual website launch before all language content is ready?

A phased launch can be discussed, but specify each language’s content scope, corresponding pages, publication conditions and future owner. Do not assume other languages can be published directly once Chinese content is approved.

Does passing website acceptance mean the redesign goals have been achieved?

Features, pages and deliverables can be checked as agreed. Business outcomes such as inquiry quality and content usage need continued post-launch observation and comparison with pre-redesign data using the same definitions.