Does your business need a website or portal?

What tasks do visitors need to complete online?

Choosing a web solution starts with asking what people actually want to do on your website, not which homepage you like. Visitors may want to find a service description, compare options, request a quote or track an order they have already placed. List these activities from the user's perspective, because your company's internal structure may mean nothing to them. For each activity, specify what information people need and what outcome they should reach. This will help you decide whether public content is enough or whether the website also needs to let users carry out tasks specific to them.

Next, distinguish the needs of occasional visitors from those of people who return regularly to complete a specific task. First-time visitors generally need an explanation, information that builds trust and a clear way to contact you. Returning users may want to view their documents, update their details or pick up where they left off without sending another email. Map out the journey for both groups, from their first visit to the desired outcome, and note where essential information is currently missing. This helps avoid a situation where all the attention goes to introductory content while the practical steps remain unclear.

Do not assume, however, that every recurring task immediately calls for a separate portal or a complex online self-service system. First, explore whether clearer instructions, a suitable form or an existing tool could do the job. If users have to enter the same information repeatedly or wait simply because data needs to be forwarded manually, it is worth reviewing the process in more depth. Your choice should be based on the user's goal and the company's ability to keep the necessary content and working processes up to date. The following questions are a useful starting point for discussion, helping turn wishes into specific requirements without committing to a solution too early.

• What does the visitor want to achieve?
• What information do they need to do this?
• Does the task require personal data?
• Who will manage the content and processes?

When is a standard website enough?

A standard website is often enough if your main goal is to introduce your company's services and help interested visitors get in touch. Service descriptions, explanations of how you work, frequently asked questions and a contact form may cover the entire user journey without requiring a login. What matters is not the number of pages, but whether visitors can find answers to their questions and understand the next step. Even a large content library can work as a website if the information is public and its use does not depend on who the visitor is. A larger volume of content therefore does not, in itself, mean you need to develop a portal.

A website also works well when communication following an enquiry takes place through another channel and visitors do not need to check its status online. For example, a form can collect the information needed to prepare a quote without requiring the interested visitor to create an account first. The form should ask only for what you genuinely need to handle the enquiry and explain what happens after it is submitted. If the process requires a personal discussion, moving it to a portal may not make anything easier for the user. A sensible solution supports your existing service process rather than adding an unnecessary extra step.

Even when choosing a simpler web solution, it is worth considering who will update the text, images and service descriptions later. Content management needs to suit the actual tasks involved, so that everyday changes do not require unnecessary technical intervention or unclear working arrangements. The content structure should also allow new topics to be added while keeping the menu and the relationships between pages easy to understand. If self-service may be needed in future, describe that possibility in the project brief, but distinguish it from the functionality you need now. That way, you do not have to commission a portal simply on the assumption that you might need one someday.

When do you need a portal with user accounts?

A portal with user accounts makes sense when people need to view or edit information online that relates specifically to them. This could include applications, documents, orders or other tasks they need to return to later. The purpose of an account is not simply to recognise a visitor, but to give them appropriate access and let them manage ongoing tasks securely. If company employees also need data from the same activity, the portal must support their work just as much as the user's. Otherwise, what looks like self-service may still conceal extensive manual work behind the scenes.

Before planning a portal, describe which user groups will use it and what each group is allowed to see and do. A representative of one organisation may need access to shared documents, while another user may only need access to the data they have submitted and the actions they have taken. You also need to decide how accounts are created, who approves their permissions and what happens when a user's role changes. These questions affect both ease of use and data protection, so they should not be left until after the design stage. The need for a portal comes from having to handle tasks with different levels of access, not simply from wanting to add a login button to a website.

Choosing a portal also means committing to maintaining user accounts, access permissions, notifications and the workflows behind them for as long as the solution is in use. Think through who will help people use their accounts and who will handle situations where the information displayed needs correcting or updating. If information comes from other systems, establish which source holds the correct information and how any errors will be explained clearly to the user. When weighing up a portal against a website, consider not only the development work involved but also the day-to-day administration and support required. The right choice gives users a meaningful way to get things done while leaving you with a manageable way of working.

Web design starts with content and the user journey

When planning a website's design, first set out what content visitors are looking for and what action it should lead them to take. A service overview, a comparison table and an application form each need a different structure because people read and use them for different reasons and in different situations. Place the information needed to make a decision where the question arises, rather than on a separate page that visitors have to guess how to find. The design should help distinguish the essential from the secondary and make the next step clear even to a first-time visitor. This lets you assess the purpose of each design choice by whether it helps people understand the content and take the intended action.

Describe the user journey as a specific task, such as finding the terms of a service, sending an enquiry or checking the status of an application online. Then review what information people need at each stage and which choices might make them hesitate. Button text should say what will happen when it is clicked, and form fields should ask only for the information needed. If an action requires preparation, explain which documents or details are needed before people start filling in the form. Test the journey using clearly defined tasks and ask the person testing it to explain what guides their choices.

Build mobile layouts and accessibility into the design from the outset, as they affect both the order of content and the controls. Check whether users can comfortably enlarge text, navigate with a keyboard and understand form error messages without relying on differences in colour. Essential information conveyed by images must also be available as text, so that understanding it does not depend solely on sight. For longer content, descriptive subheadings and clear paragraphs help people find answers without reading the whole page. The same logic should apply to both the public website and the logged-in view, even if the available features differ.

Integrations and access permissions need careful planning

When planning integrations, start with the flow of data: where information comes from, what it is used for and which system it is updated in. If the same contact details are stored in several places, decide which source takes precedence when changes are made. Otherwise, information displayed on the website may differ from what an employee sees in their usual work tool when handling an enquiry. Also document whether data needs to be transferred immediately or whether periodic updates are sufficient. The choice should be guided by the workflow, not by a desire to connect every application in use simply because it is technically possible.

When defining access permissions, describe actions, not just user titles, as people with the same title may have different needs. One person may need to view documents, another to edit them and a third to approve changes before they are published online. Give each user only the access they need to carry out their tasks, and plan how permissions will be changed later. Account closure, temporary cover and situations where someone acts on behalf of several organisations need particular attention. If the portal handles personal data, the purpose of collecting it must be clear, and access to it must be justified by the task involved.

An integration specification must also cover situations where the other system fails to respond or sends incomplete data. Decide what users will see in these cases and how the system will prevent the same request or payment from being repeated by mistake. An error message should explain whether the action succeeded, was left incomplete or requires the user to try again once the problem has been resolved. Technical logs must allow the cause of an error to be investigated, but should not accumulate unnecessary personal data or secrets. Before development begins, also agree who is responsible for configuring external services, managing access and communicating changes.

• Data sources and flow direction
• User actions and access restrictions
• Error handling and responsibilities

Website maintenance starts at the planning stage

Website maintenance starts with deciding what content and functionality you can realistically keep up to date alongside your daily work once the site is live. Every form, content type and integration you add needs checking, even if users never see this behind-the-scenes work. It therefore makes sense to distinguish what you need for launch from features you can develop later when a clear need arises. A simpler solution does not necessarily mean a less ambitious design; it can mean fewer exceptions and a clearer approach to administration. For every additional feature, ask who will use it, who will maintain it and what happens if it fails.

For content management, define who can edit information, who reviews it and when outdated content is removed from public view. Editors should be able to make routine changes without breaking the layout or having to ask for technical help each time. Content templates with clearly defined fields help achieve this, making it clear which information is required and why. Maintenance also includes software updates, backups and checks to ensure that essential forms and user journeys still work after changes. Having a backup is not enough on its own if you have not planned how to use it to restore the service.

Before choosing a solution, consider not just the development work but also the time needed to manage it and its dependence on external services and their terms. A standard website may be enough if visitors need public information and an easy way to contact you at a time that suits them. A portal makes sense when users need to work securely with their own data or carry out recurring tasks in a personal area. In either case, the content structure, permissions and maintenance should support the same clearly defined user task, rather than a preference for a particular technology. Choose a solution whose purpose you can explain in terms of what users need to do, and whose upkeep you can manage.