How to Write a Website Development Brief That Prevents Rework
A website brief prevents rework when it defines business objectives with measurable outcomes, states who the site is for and what they…
Define roles before screens
A portal serving customers, partners or employees needs an explicit role model: who each user is, which organisation they belong to, what they may view, and what they may change. This determines navigation, data access, integration scope and a large share of the build effort.
Designing screens first produces layouts that assume a user can see things they should not, and the correction usually restructures the interface rather than adjusting it. Define the role matrix, agree it with the business, then design.
- Role definitions with the business purpose of each
- Data visibility per role, including organisation-level boundaries
- Actions each role may perform, and any approval requirements
- How a user is granted, changed and removed from a role
- Whether users can manage other users in their own organisation
- What an administrator can see and do on a user’s behalf
Establish system of record per data object
A portal displays data owned by other systems. For each object, decide which system is authoritative, whether the portal may write to it, and how conflicts are resolved. Portals that store their own copy of customer or order data without a defined authority produce disagreements that undermine trust quickly.
Where the portal must hold data of its own, such as preferences or submitted documents, that is fine, provided it is explicit and the portal is understood to be the system of record for those objects.
| Data object | Questions to answer |
|---|---|
| Customer and contact | Which system is authoritative; can the portal write? |
| Orders and transactions | Read-only view or submission point? |
| Documents | Stored in portal or referenced from source? |
| Pricing | Live lookup or cached, and with what tolerance? |
| User identity | Portal-managed, corporate directory or federated? |
| Preferences and settings | Usually the portal itself |
Integration shape determines the experience
Portal responsiveness is largely a function of how many back-end calls a screen requires and how those systems perform under concurrent load. A screen assembling data from four systems sequentially will be slow regardless of front-end quality.
Decide per data object whether it is fetched live, cached with a defined staleness tolerance, or synchronised on a schedule. Live lookups against a system not designed for external concurrency are a common cause of portals that work in testing and fail at launch.
Identity lifecycle and support
Registration, verification, password reset, role changes, organisation transfers and deactivation together represent significant build effort and are routinely underestimated because they are not the interesting part of the portal.
They also generate most of the support load after launch. Decide who handles a locked-out user and how they verify identity before the portal goes live, or that decision gets made under pressure by whoever answers the phone.