Where does a good design really begin?
In previous parts we reached an important conclusion - we don't design a website just because the company needs a "new website".
We design a tool that is meant to solve a specific problem.
Sometimes the problem is poor sales. Sometimes too few inquiries. Sometimes customers can't find information. Other times salespeople answer the same questions every day because the site doesn't convey basic information. It can also happen that the company simply grew and the existing site stopped matching its real scale.
Therefore the first stage should not be Photoshop, Figma or choosing a framework.
The first stage should be a conversation.
First we learn the business
A good UX designer doesn't need to become an expert in every industry they design for. They do need, however, to understand the client's business well enough to know what problems it is trying to solve.
That's why we ask questions that at first may seem unrelated to design;
- Where do customers come from?
- Why do they choose this company?
- Why do they leave?
- What do they most often ask before purchasing?
- What does the sales process look like?
- Who handles inquiries?
- What happens to a lead after submitting a form?
- Which products are most important?
- Which services have the greatest potential?
- Does the company want to increase the number of inquiries, the value of orders, the number of customers, or primarily improve its image?
Only answers to such questions allow us to determine what we should actually be designing.
Discovery - before the first mockup
In digital projects the term Discovery is often used.
It's the phase of learning the problem, users, business goals, constraints and technological possibilities before starting actual design and development.
This is not a "waste of time before starting work." In a well-run project Discovery is meant to reduce the risk of building something that looks good but doesn't solve the real problem.
We may discover, for example, that the client doesn't actually need a new website.
They may need better information architecture.
Or simplification of the purchase process.
Or integration of the site with a CRM.
Or automation of inquiry handling.
Or a completely different way of presenting the offer.
And that's precisely why it's sometimes worth pausing before starting production.
UX doesn't start with appearance
UX, or User Experience, means the user's experience when using a product or service.
For a website it includes much more than the visual look of the interface.
It also includes:
- how the user moves around the site,
- ease of finding information,
- clarity of messages,
- the purchase process,
- forms,
- content hierarchy,
- task completion speed,
- system response to user actions,
- accessibility,
- sense of security and trust.
That's why UX begins before anyone draws the first screen.
First you must understand what the user is trying to achieve.
User Flow - how should the user reach the goal?
One of the fundamental UX design tools is the User Flow. It's a description of the path a user takes to complete a specific task.
For example, in a shop it might look like: ad → product page → select variant → cart → delivery → payment → order confirmation.
In a service company: Google → service page → case studies → testimonials → form → contact with salesperson.
For a manufacturer: search → product → technical specifications → documentation → request for quote.
Each of these paths requires different design decisions.
If the user's main goal is to purchase, we cannot force them to read a dozen screens of text. If the product is expensive, complex and requires consultation, pushing them too quickly to a form can also be a bad solution.
UX is, among other things, about finding the right level of guidance for the user.
Wireframe - before we start "beautifying"
Another possible stage is a wireframe, a simplified diagram of a screen showing the layout of content and functions.
A wireframe doesn't have to be pretty. And that's fine. At this stage it's not about whether the button color will be perfect.
It's about answering questions:
- What will the user see first?
- What will be most important?
- What should be placed higher?
- Where will we put supplementary information?
- How will the user move to the next step?
- What happens after a click?
It's a bit like designing an apartment.
First we decide where walls, doors and rooms will be. Only later do we think about wall colors.
Design system - so the project isn’t a jumble of random elements
In larger projects another important element appears - the Design System.
It's an organized set of rules, components and patterns that define how to build the interface.
It may include, among other things:
- colors,
- typography,
- buttons,
- forms,
- cards,
- tables,
- messages,
- icons,
- spacing,
- responsiveness rules,
- component behaviors.
Why? — To keep the interface consistent.
If a button behaves one way on one subpage and completely differently on another, the user has to relearn the interface every time.
A Design System also helps the development team. Instead of building a component from scratch each time, they can reuse previously defined elements.
This translates into greater consistency, easier development and often lower maintenance costs.
And where does technology fit into all this?
Technology should appear early enough, but it should not dictate the entire project. That's an important distinction.
A designer might come up with a great feature that makes sense from a business perspective. A developer might notice, however, that implementing it will be very costly or cause performance issues.
On the other hand a developer might propose a technological solution that is very convenient to implement but from the user's perspective doesn't solve the problem well enough.
That's why the best projects happen where UX, design, development and business talk to each other from the beginning.
Not in the sense: "Designers first, developers later."
But: "Together we consider how best to solve the problem."
Technology shouldn't be chosen just because it's trendy
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, native app, PWA... you can list technologies for a long time.
But the client isn't buying technology. They're buying a solution.
So the question: "Which framework will we use?"
is often much less important than: "What problems should the system solve?" Only later can we choose the appropriate architecture.
A simple corporate site needs a different technology than a store handling thousands of orders, and a different one than a B2B platform with extensive integrations and custom user permissions.
Technology should follow requirements, not requirements follow technology.
Backend, frontend and the place the user doesn't see
Remember that a website is not only what we see in the browser.
Frontend is responsible for the part of the application the user interacts with directly.
Backend is responsible for server-side logic — data processing, database communication, process handling and integrations.
And between them there are often quite a few additional elements;
- CRM.
- ERP.
- Payment system.
- Mailing platform.
- Warehouse system.
- API.
- Analytics.
- Automations.
- Customer service system.
If we design a new site without considering this ecosystem, we may create a beautiful frontend that functions as an isolated island.
But the goal should be something entirely different.
A good site can do much more than just "collect forms"
A modern website can be part of a larger business process;
- A user sends an inquiry.
- The system recognizes its topic.
- The lead goes into the CRM.
- A salesperson receives a notification.
- The customer receives an automatic confirmation.
- Data is assigned to the appropriate category.
- The system can check product availability.
- It can prepare information for the salesperson.
- It can start a specific workflow.
In a shop an order can automatically progress through fulfillment stages. In B2B a customer can have access to personalized prices, documents and order history.
Then the site stops being merely a "business card." It becomes part of the business infrastructure.
What about AI?
AI can also be an element of such a system. But again — it shouldn't be added just because "everyone has AI now."
If a chatbot doesn't solve any real problem, it will just be another pop-up on the site.
If, however, AI helps the user faster find the right product, configure a service, get an answer to a question or go through a selection process, then the technology starts to have justification.
The same applies to personalization.
We can show different content based on behavior, source or stage of the purchase process. We can analyze data and better predict customer needs.
But we should always start with the question: "What problem are we solving?"
Only later: "Is AI the best way to solve it?"
We test not only whether it works
One of the most common mistakes is testing the site only at the end. Then we discover that the form is too long, the purchase process is unintuitive, and the user can't find the most important information.
The later we discover such a problem, the more expensive its fix will be.
That's why it's worth testing the design in stages. We can test a prototype. We can observe user behavior. We can conduct usability tests. We can analyze data from Google Analytics or other analytics tools. We can use session recordings or heatmaps if implemented in accordance with privacy requirements. We can also simply talk to salespeople.
The latter is often underestimated.
A salesperson hears customers' questions every day; they know what users don't understand. They know what customers fear. They know what information must be provided before purchase.
That's huge design knowledge.
MVP doesn't mean anything goes
In digital projects the term MVP - Minimum Viable Product often appears.
It's the first version of a product that includes the minimal set of features needed to validate assumptions and deliver value to users.
MVP shouldn't mean: "Let's do anything and we'll see later."
A good MVP should answer: "What is the smallest version of the solution that allows us to check if we're heading in the right direction?"
This is also very important for websites and apps.
Instead of building thirty features at once, it's sometimes better to launch the five most important and see how users use them. Later we develop the system based on real data, not only assumptions from the first meeting.
The site doesn't end on launch day
This is another thing we often forget.
The moment the site is published is actually the beginning of its real life. Only then real users appear. Only then do we see which content works. Only then do we know which elements are ignored. Only then can we check whether the number of inquiries, sales, time spent on site or other metrics we previously agreed on have increased.
Therefore the project should be continuously developed;
- Analysis.
- Conclusions.
- Change.
- Test.
- Re-analysis.
It's more like a cycle than a one-time event.
What should actually be measured?
It depends on the project's goal.
For an online store these might be:
- conversion rate,
- average order value,
- cart abandonment,
- revenue,
- customer lifetime value.
For a service company:
- number of valuable leads,
- form conversion rate,
- number of scheduled consultations,
- cost per lead,
- quality of inquiries.
For an informational portal:
- finding specific information,
- user engagement,
- return visits,
- material downloads.
You don't have to measure everything. You do need to know what matters.
Because if the company wants to increase the number of valuable inquiries, simply increasing traffic to the site doesn't necessarily mean success. You can have ten times more visits and not a single additional customer.
The biggest mistake? Designing without answering "why?"
You can create a visually great site.
You can use a modern tech stack.
You can prepare perfect animations.
You can care about every pixel.
And yet the project may not bring the business expected results. Why?
Because the most important question was missing: Why are we doing this?
If the answer is: "Because the old site is ugly",
that's a bit insufficient.
If instead it is: "We want to increase the number of inquiries from B2B clients, shorten the path to the right service and free the sales team from answering repetitive questions",
suddenly we have a concrete problem to solve.
And we can design a solution.
At Web24 we don't just hand over websites
It's the difference between performing a task and technological partnership.
If a client comes with a specific idea, it doesn't mean our job is to implement it uncritically.
We must also say: "This makes sense."
Or: "We can do this better."
Or: "Technically we can build this, but we don't see the business justification."
Or: "Before we do this, we'll check whether users actually need it."
Sometimes the best design decision is to add a feature. Sometimes to remove it. Sometimes to change assumptions completely.
And that's what the team's experience is about — not that we can build everything, but that we can recognize what is really worth building.
No two projects are the same
This brings us back to the starting point.
We may have two clients in the same industry. Two manufacturers. Two shops. Two law firms. Two software houses.
Their sites may look similar. But they shouldn't be identical just because they operate in the same category.
Because they differ in people. Strategy. Sales process. Offer. Budget. Technology. Customers. Goals.
And that's why each project requires its own decisions.
Not always spectacular. Not always groundbreaking. But conscious.
A website as a tool, not decoration
A well-designed site should be more to the company than a digital business card.
It should help the user make a decision. It should facilitate sales. It should answer questions. It should build trust. It should support employees. It should integrate with other systems where it makes sense.
And above all it should achieve a specific business goal.
That's why there is no single answer to: "What does a good website look like?"
A better question is: "How should this particular company's site work to help it achieve its goals?"
And that question is where every good project should begin.
Finally - the most important rule
We don't design a site so the client can say: "But it's pretty."
We design it so that after a few months the client can say: "This really helps us run the business."
Because the difference between a pretty site and a good digital product is often not visible on the first screen.
You see it only in the results.
Summary of the whole series
In this series we looked at why we don't design two identical websites.
We started from a simple assumption: the same industry doesn't mean the same business.
We then showed how company strategy, sales method, target group and user needs affect UX, information architecture and functionality.
In the final part we went through the design process — from Discovery and learning the business, through User Flow, wireframes and Design System, to technology, integrations, testing, analytics and further development.
Because a custom design doesn't simply mean a "different look."
It means different decisions resulting from a different problem.
And that's why every company should receive a solution designed for it, not for the "average company in the industry."
