Why address UX/UI design from the start of a custom software development project?

A corporate system may contain all the required functionality and still slow down everyday work. If processing a single order requires moving through several screens, repeatedly entering the same data or providing additional explanations for less common situations, the problem may not lie in the functionality itself, but in the design of the user flow.

The software can therefore be technically functional yet operationally inefficient. This is precisely the difference addressed by UX/UI design.

What is the difference between UX and UI

UX and UI are often used together, but they do not mean the same thing.

Area	What it addresses
UX – user experience	How a user completes their task through the system
UI – user interface	What a specific user interface looks like and how it works

 

UX design addresses workflows, navigation, information architecture, the logic of individual steps, error prevention and system feedback.

UI design translates these principles into a specific interface: screens, forms, buttons, typography, visual hierarchy and the states of individual elements.

Good UI is therefore not merely a “nice appearance”. It must support the task the user wants to perform. And good UX does not mean that a specialised corporate system requires no training. A complex warehouse, financial or production system may require knowledge of the work process itself. However, users should not need training to understand unclear buttons, inconsistent navigation or unnecessarily complicated steps.

Poor UX is not just a matter of comfort

If the system is difficult to use, the consequences gradually carry over into day-to-day operations. A user may:

• take more steps than the task actually requires,
• enter data incorrectly or omit it,
• ask colleagues or support for help more often,
• create their own instructions and aids,
• record information outside the system,
• avoid certain functions altogether.

The problem then concerns more than user comfort. The time needed to perform the work increases, the error rate rises and the company loses control over how the process is actually carried out.

For example, if employees regularly export data to Excel so that they can continue working with it, this may be an interface problem. However, it may also be a broader sign that the system no longer reflects the company's current processes. We discuss other similar situations in the article 5 warning signs that your current software is no longer sufficient.

UX begins before the first line of code

One of the most common mistakes is the assumption that the functionality is created first and the user interface is “finished” at the end. However, UX is not a graphic layer placed over a completed system.

It begins with questions:

• Who will use the system?
• What does the user need to achieve?
• How do they perform this task today?
• Where do they lose time while doing it?
• Which information do they need to make a decision?
• What exceptions may arise during the process?
• What should the system do automatically and what should be confirmed by a person?

The design of the user experience therefore naturally follows on from the analytical phase of the project. As an ANASOFT analyst also explains in the interview “Analysis is not a document, but a process”, the essence of analysis is understanding needs and use cases, from which a functional system is then created. UX translates these findings into workflows and an interface that the user will actually work with.

Good design does not begin with the question of where to place a button

If a manager says, “We need a button on the main screen to create a report,” a designer can draw the button. However, a better approach is to first determine:

• Who uses the report?
• What do they need to see in it?
• How often do they create it?
• What do they then base their decision on?
• Does the report need to be created manually at all?
• Should the system display important information automatically?

The result may be a completely different solution from the originally requested button. This ability to formulate the problem correctly is also important in product design. An ANASOFT product designer discusses connecting user, business and technology needs in the interview “The most important thing is knowing how to ask the right questions”.

How UX design for custom software is created

The specific process depends on the project, but user experience design typically goes through several levels.

1. Understanding users and their work

First, it is necessary to determine who will use the system and in what context. An accountant who spends most of the day at a computer needs a different interface from a service technician using a phone in the field.

Different needs also apply to:

• a warehouse worker using a scanner,
• an administrative employee processing dozens of similar records,
• a manager who mainly monitors exceptions and results,
• a customer who logs in to the portal only a few times a year.

UX is therefore not designed for an abstract “user”, but for specific roles, tasks and working conditions.

2. User flows

Next, the way the user should move through a specific task is designed. For example:

receiving a request → checking data → making a decision → confirmation → the next process.

This can reveal:

• unnecessary steps,
• duplicate data entry,
• unclear decisions,
• missing information,
• process exceptions.

The goal is not to achieve the fewest possible clicks at any cost. Four clear and safe steps may be better than one overcrowded screen. What matters is removing steps that provide no value to the user, the process or control.

3. Wireframes

A wireframe is a simple screen design that shows the layout of information and elements without the final visual design. It helps verify, for example:

• which information must be visible,
• what should take priority on the screen,
• how the user moves to the next step,
• which functions belong together.

At this stage, the focus is primarily on logic.

4. Interactive prototype

A clickable prototype can be created from wireframes, allowing the use of the future system to be simulated even before it is programmed. The user can try, for example:

• create an order,
• find a customer,
• approve a request,
• resolve an error,
• complete a specific workflow.

The team therefore receives feedback not on an abstract list of requirements, but on something that already resembles the future system.

5. User testing

The prototype should be tested by the people who will actually work with the finished system. Instead of asking: “Do you like this screen?” it is more useful to assign a specific task: “A new order has arrived from an existing customer. Try to record it and pass it on for processing.” The focus is on whether the user:

• knows where to start,
• understands the available options,
• finds the necessary information,
• makes errors,
• completes the task without help.

A problem discovered in the prototype can be corrected before it becomes part of the implemented solution.

What user-friendly corporate software looks like

There is no single interface that is right for everyone. However, good UX usually follows several basic principles.

Displays information according to the task and role

A warehouse worker does not need complete financial analytics on their work screen. A manager, in turn, does not need to monitor every individual warehouse movement. The interface should primarily show the user what they need for their work and decision-making.

Reduces repetitive manual work

If the system already knows a certain piece of information, it should not force the user to enter it again without reason. Data can, for example, be:

• filled in automatically,
• retrieved from another system,
• pre-filled according to context,
• offered for confirmation.

Prevents errors

A good interface does not first allow the user to make a mistake and only then inform them that something is not working. It can show them in advance:

• which data is missing,
• what format is expected,
• what the operation will result in,
• which options do not make sense in the given situation.

Uses the user's language

The names of functions and fields should correspond to the terminology people use at work. The application's internal technical structure does not have to determine the vocabulary of the user interface.

Takes the environment into account

An interface used in an office on a large monitor can contain more data than a mobile application used in the field. Similarly, the design must consider readability, contrast, keyboard operation, the size of interactive elements, error states and other aspects of accessibility. Usability arises in the context of real work.

How to tell that the UX of an existing system is not working well

Problematic UX may not manifest itself as an obvious system error. More often, it is revealed by user behaviour.

Users create their own workarounds

Excel, notebooks, personal lists or parallel records often arise because users cannot easily do what they need in the system.

Common tasks prompt repeated questions

If support staff or experienced colleagues keep answering the same questions, it is worth checking whether the problem can be solved directly through the interface design.

Routine activities cause errors

Repeated errors in the same place may indicate that the wording, sequence of steps or system feedback is not sufficiently clear.

New employees learn the system, not their job

A complex process may naturally require training. However, if a large part of the training consists of explaining where functions are located and how to work around the interface's peculiarities, there is room to improve the UX.

Part of the system is practically unused

A function may technically work, but if it is too complicated or unnatural for the real workflow, users will find another way.

How to measure whether UX has actually improved

Usability does not have to be assessed only by feeling. Specific indicators can be monitored before and after a change.

Indicator	What it can reveal
Task completion time	Unnecessarily complicated steps
Error rate	Unclear or risky parts of the process
Task success rate	Whether the user can complete the process
Support requests	Areas users do not understand
Training time	Difficulty of learning the system

 

It is important to measure tasks that have real significance for the company. In an order system, order processing time may be important. In internal approval, the number of returned requests. In a customer portal, the proportion of tasks that the customer completes without contacting support. In this way, UX is linked to specific process performance.

The most common mistakes in UX/UI design

We will develop the functions first and deal with the design later

If the technical architecture has already predetermined the user flow, changing the interface later may be more difficult than if the scenario had been verified before implementation.

We will copy the old system

During modernisation, it may be tempting simply to transfer existing screens to a new technology. However, this may also carry old inefficient processes into the new system.

The interface is designed only by management or the project team

A manager, analyst and end user see the process from different perspectives. A design created without users may be logical from the project's point of view, but impractical in day-to-day operations.

UX is confused with graphic design

A new colour scheme or more modern icons will not fix a poor workflow. If the user still performs seven unnecessary steps, a visually more attractive version remains a seven-step problem.

Testing begins only after development is complete

The later the company discovers that the workflow does not suit users, the more other parts of the system may already be built on that decision.

1. That is why prototyping is one way to reduce unnecessary complexity before implementation. We discuss a similar principle in the article on how to avoid unnecessarily complicating a custom software project.

Good design does not mean more design. It means less rework

UX/UI design in custom software is not intended to create as many screens as possible or the most striking interface. Its purpose is to verify whether the proposed system:

• supports the real workflow,
• provides the user with the necessary information,
• does not require unnecessary manual work,
• helps prevent errors,
• works for different user roles,
• and can be reasonably developed along with the company.

That is precisely why it is worth addressing UX before programming begins. The sooner a company verifies how people should work with the system, the sooner it can identify an incorrect assumption, an unnecessary step or missing information. The result is not only more pleasant software. It is a system better adapted to the work it is meant to support.

Do you have a system that people use differently than you planned?

Excel workarounds, repeated questions, incorrect data entry or complicated everyday tasks may have a common cause: the software no longer reflects how the company actually works.

When designing custom software, it is therefore advisable to first map work scenarios, user roles and processes, and only then decide which functionalities and interfaces need to be created. ANASOFT also provides , which help translate business needs into the design of a future solution.

Frequently Asked Questions