Web development
Web Design: How to Decide What to Solve Your Website
Imagine a service company that receives visits on its website, but the queries arrive irregularly. Those who enter do not quickly identify what the company offers, who works for or what the next step is. The team proposes a redesign because the page "has remained old", although that phrase still does not explain what should change.
This case is hypothetic, but it is a frequent doubt: does web design consist of renewing appearance or sorting information so that the site helps the company? By finishing you will be able to distinguish which decisions belong to the design, what it is worth defining before asking for a proposal and how to check that the website responds to the objective set.
Scenario initial situation
The fictional company offers several specialized services. Its current website gathers useful information, but it is distributed without a clear order: the home page lists many services, some pages repeat messages and the contact form appears at the end without explaining what will happen after sending it.
The person in charge of the business wants a more current website. However, when reviewing the usual queries there appears a more concrete need: to facilitate a possible client understanding the right service and to start a conversation with the minimum context necessary.
Here the web design is not limited to deciding typography, images or colours. It includes the information architecture — how pages are grouped and prioritized — the routes followed by a visit and the way each screen leads to an understandable action.
Observable problem
The problem is not that a website has little visual movement or that it uses an earlier style. It forces the person visiting the page to interpret too many things on their own.
In this hypothetical example, concrete signs are observed:
- Services are presented with internal names that a new client may not understand.
- The main page does not clarify what type of need each service responds to.
- The same call to contact is used for very different requests, without guiding what information each person should provide.
- The content has been added over time, but there is no visible priority between the essential and the secondary.
These signals allow the problem to be formulated usefully: the website does not accompany a person well enough from his initial doubt to a reasoned query.
Expressing it thus changes the conversation. Instead of asking for a "more modern" design, you can decide what someone should understand, compare or do at every point of the site.
Objective analysis
Before choosing a visual solution, it is best to separate three layers: objective, scope and solution. This distinction prevents an aesthetic preference from becoming, without reviewing it, the main reason for the project.
| Layer Application in the hypothetical case | |
|---|---|
| Objective | Help a potential customer identify the relevant service and request contact with sufficient information. |
| Scope | Reorganize main pages, clarify messages, define paths and configure a coherent contact path. |
| Solution | Decide the appropriate structure, visual components, editing system and technical implementation. |
The objective should describe an observable change. "Transmitting professionalism" may guide visual decisions, but it is ambiguous if it does not translate into behaviours: for example, that the visitor recognizes the service, finds a relevant explanation and knows how to continue.
It is also important to decide who the priority user is. A website may have several audiences, but not everyone needs to see the same information or follow the same route. In the case raised, a person comparing providers needs clarity about the services and how to contact; who already knows the company may only look for a specific data. The design should sort those needs without converting the home page into an indiscriminate catalogue.
Proposed scope
With the objective defined, the initial scope of the hypothetical case could focus on what is necessary to meet it:
Econtent structure. Delimit which pages explain the proposal, which pages develop each service and what information should be left out of the main navigation. 2.
Jerarchy of each page. Decide what should be understood first, what tests or details help to continue and where it makes sense to propose contact. 3.
Messages and Content. Prepare texts that explain the problem that each service, its scope and reasonable doubts attends before contacting.The design cannot compensate for a message that no one has defined or approved. 4.
Contact tour. Set which fields the form needs, who receives the requests, and what confirmation the person will see after sending it. 5.
Adaptation to different devices. Check that the main information and actions remain usable on small screens, not just on a computer. 6.
Edition later. Determine who will update the contents and which parts should be able to change without altering the structure of the site.
Not everything should be entered in a first version. A private area, integration with other tools, multiple languages or complex migration may be necessary in another context, but it is appropriate to treat them as independent decisions. Include them without defining rules, responsible and dependencies can expand the project without clarifying its objective.
Solution and verification
In the hypothetical scenario, the application starts by sorting out the web around questions that a potential customer really needs to solve: what does the company do, what type of need fits each service, what information can you consult before contacting and what is the next action.
From there, the design transforms that structure into coherent pages and components. A component is a reusable piece, such as a service card, a contact block or a call to action. Reusing them with criteria helps the site maintain the same visual language and its contents do not seem unrelated.
The test should not remain in "design likes." This assessment matters, but it is not enough to validate the objective. In this case criteria such as these could be agreed:
- A person who arrives at the home page can locate the main services and distinguish them.
- Each service page explains who it can serve and what information it is worth to provide when contacting.
- The form shows a visible confirmation after a correct shipment and addresses the request to the agreed destination.
- Important actions can be identified and used on mobile and computer.
- The person responsible for updating the website can edit the intended content without relying on improvised changes in the structure.
These criteria should be validated with people who know the business, content and subsequent operation. It is also necessary to review specific aspects when applying: data processing, required accessibility, external tools, access permissions or migration conditions. Web design may order experience, but does not replace those business, legal or technical decisions.
Transferable learning
The case leaves a practical idea: a good starting point for web design is not "what style do we want?", but "what should a person be able to do and understand when visiting our website?".
The visual part still plays an important role. It gives consistency, facilitates reading and helps to recognize the identity of the company. But it works better when it responds to an already agreed structure and objective.
Before starting your project, try to specify four elements: the main action that should facilitate the website, the priority audience, the available content and who will take care of reviewing and keeping them. If those answers remain open, it is preferable to make them visible rather than assume them in the design.
When you need to convert those decisions into a sustainable website, you can learn about the Web development approach for companies of AVSISTEC and explain your project with the goal, doubts and scope you have defined.