How to prepare a web application brief

Distinguish information from working with it

A business website presents your offer. A web application helps someone complete a task in a browser: book an appointment, process a job or share materials with a client. Both can exist together. For the brief, identify where reading information is enough and where someone needs to do something with it.

Start with a recurring situation that takes time or causes confusion. You do not need to redesign the whole business at once.

Write down the current steps

Choose one typical job. Who receives it, records the details, passes them on and checks completion? Mark where information gets copied, people wait for replies or progress becomes unclear. Include a simple sketch or spreadsheet example with fictional data. Real personal or sensitive records are unnecessary for an initial explanation.

Talk to the people who will use the tool. Their everyday exceptions may influence the design more than a long wish list.

Decide who can see and change what

List user groups and their tasks. An employee might process assigned jobs, a manager review progress, and a client follow only their own project. For each group, explain what they can read, edit, approve or share. Roles help shape both the screens and controls over access to information.

Include adding a new person, changing their responsibilities and removing access when their involvement ends.

Identify data sources and common exceptions

For important information, establish where it originates and which version should be treated as correct. If another system already manages customers or stock, explain what the application should receive from it and send back. Assign a person or role to each handover. This prevents different people from expecting updates in different places.

Include corrections, cancellations and returning to an earlier step. Real work does not always move in one direction.

Choose a complete starting point

Separate what is necessary for one usable process from improvements that can come later. The first version should let people finish a real task, rather than simply view a few screens. Describe how you will check the result: for example, a job can be received, assigned, completed and its history reviewed. This example helps with design, testing and acceptance.

What to send with your enquiry

Prepare a short description of the problem, current process, user roles and systems you work with. Add the main expected benefit and one example situation. You do not need to understand databases or programming languages. A useful brief explains what should change in everyday work and how you will know the change has helped.