By the end of the lesson, you can tell the visual quality of an interface apart from the whole user experience. You can name several touchpoints of a digital service, and you can describe a problem not as a screen defect but as the relationship between a user task and its consequence.
Why start here?
Someone hearing about UX/UI design for the first time often thinks of "beautiful apps": rounded buttons, clever colors, subtle animations. This is understandable, because this is what we see. The larger part of design, however, is invisible: understanding who wants to achieve what, where they get stuck, what they misunderstand, and what happens when something fails. If we skip this foundation, even the most beautiful interface is just uncertainty wrapped in a nice box. This is why the goal of the first lesson is to have precise concepts of what we are actually designing.
What does UX mean?
Take an everyday example: a student signs up for an exam. Their experience does not begin at clicking the "Sign up" button. It begins when they try to find out when the exam period is and where to sign up. It includes whether they understand the conditions, whether they can fill in the form without errors, whether they get a confirmation, and whether two weeks later they can look up which time slot they signed up for. If they are uncertain at any point of the process, that is part of the experience, even if the screen in question looks good on its own.
UX is therefore process and consequence, not a momentary impression. Three questions help keep this in mind:
What does the person want to achieve? (goal)
What happens along the way? (steps, decisions, obstacles)
What happens in the end: what do they know, what do they feel, what awaits them? (consequence)
What does UI mean?
UI, or user interface, is the layer through which the user sees and operates the process: headings, buttons, fields, navigation, icons, colors, spacing, and feedback. The UI matters because the system becomes understandable through it. If buttons do not look like buttons, or the error message is unreadable, even the best process will not work.
The relationship between UI and UX is well shown by the following analogy. The UI is like a restaurant's furnishing, plates, and menu. The UX is the whole dinner: the reservation, the arrival, the waiting, the order of the dishes, the bill, and whether the guest felt good. You can serve a bad dinner on beautiful plates, and you can have an excellent evening in simple surroundings.
A practical consequence: "let's make it more modern" is, by itself, not a design goal. The question is rather: which person, in what situation, cannot yet perform which task confidently, quickly, or fairly enough? The interface provides tools for solving this.
We design a process, not a screen
A task flow is the series of steps, decisions, and states needed to reach a goal. Let us look at an example that will accompany us through the whole course.
On the home screen of Mai program there could be a big, impressive search field. The real experience, however, consists of several steps:
The student decides to go out tonight, and with whom.
They try to find something that is close, cheap, and fits their mood.
They compare a few events: time, price, language, registration requirements.
They decide and, if needed, register or buy a ticket.
Later they find the details: where and when it starts, what to bring, how to cancel.
If we design only the screen of the third step, the preceding and following steps are easily lost. An "Available" label is not enough if it is unclear what time the event starts, how much admission costs, and whether advance registration is required. Good UX does not mean everything is visible at once; it means that at the moment of decision, the necessary information is available and understandable.
flowchart LR
A["Goal:<br>I'm going out tonight"] --> B["Search"]
B --> C["Compare"]
C --> D["Decide and register"]
D --> E["Confirmation"]
E --> F["Before the event:<br>details, cancellation"]
C -.->|"finds nothing suitable"| B
In the diagram, the dashed arrow shows that the user's path is rarely linear: they step back, search again, change their mind. Good design takes this into account too.
Touchpoints and service experience
Service experience is the experience of the whole customer journey, which reaches beyond the digital interface. A touchpoint is any moment or channel of the service where the user meets information, an interface, or the organization.
Even with a digital product, it is common that part of the user's journey happens outside the interface. A touchpoint can be an application screen, but equally an email, a push notification, a customer service reply, an automatically generated invoice, a physical location, or another organization's system. In Mai program, for example, the touchpoints are: the search interface, the event page, the registration confirmation email, the reminder before the event, and the organizer who welcomes you at the entrance on site.
Why does this matter? Because the user does not perceive that different teams or systems run these. If the interface promises that your registration was successful, but the email never arrives, the service remains uncertain for the user. From their point of view there is one service, not ten touchpoints.
This does not mean that in a student project every channel has to be designed in full detail. It means that you need to identify the critical points: those where an error or uncertainty makes the user abandon the task or make a wrong decision. A task can be considered closed when the user also knows what happened, what will happen next, and where to ask for help.
UX, UI, and product design
The term product design usually covers understanding the problem, shaping the solution, and aligning it with product goals. Not every organization uses role names the same way: in some places a "UX designer" researches and draws wireframes, elsewhere a "UI designer" does the visual style, and elsewhere a single "product designer" carries the whole thing through. The essence is constant: a design decision is not only taste. It weighs evidence about research, operational constraints, business goals, technology, and the user.
In a login flow, for example, the organization wants to reduce abuse, the developer wants secure identification, and the user wants to log in quickly. A good design does not simply pick one goal over the others. It examines how big the risk of error is, which step is justified, and how the necessary security can be communicated in an understandable way.
Worked example: where is the problem?
In a team's heads, the first idea of Mai program sounds like this: "We need a modern, map-based event app." Not a single word in this sentence is about the user. Before drawing anything, it is worth asking: what can the student not yet do confidently, quickly, or fairly enough?
It may be that students today search through Facebook events, posters, and friends' messages. The main difficulty may not be that there is no map, but that data must be collected from many sources, and it often turns out only on site that the event's price or language is not suitable. If this is true, a "more modern map" does not solve the problem, but "one place with comparable data" does. Whether this is true can be established with the research methods of the following chapters.
Common misconceptions
Claim
Clarification
"UX is research, UI is drawing."
Research is an important UX activity, but the prototype, the copy, the error state, and testing also shape the experience. A UI designer also needs to understand the user's task.
"If the user eventually reaches the goal, the process is good."
Not necessarily. They may have got there with too much uncertainty, with detours, or with an error risk that will put them off next time.
"The user always knows what they need."
They know their own situation and difficulty well, but designing the right form of solution is the job of research and iteration.
"UX applies only to digital products."
Every service has a user experience. The digital interface is only one part of it.
In brief
UX is the whole experience from goal to consequence; UI is the layer through which the user sees and operates the process.
We design a process, not a screen; touchpoints exist outside the interface too.
"More modern" is not a goal; the goal is that a specific user task can be performed better.
A design decision is built on evidence, not taste.
Review questions
What is the difference between UX and UI in a specific digital service that you also use?
Name three touchpoints that are not the main application screen itself.
Why is it not enough to formulate a problem as "the interface is outdated"?
What information does a user need to feel sure that a task has ended?
UX, UI, and service experience
Objectives
By the end of the lesson, you can tell the visual quality of an interface apart from the whole user experience. You can name several touchpoints of a digital service, and you can describe a problem not as a screen defect but as the relationship between a user task and its consequence.
Why start here?
Someone hearing about UX/UI design for the first time often thinks of "beautiful apps": rounded buttons, clever colors, subtle animations. This is understandable, because this is what we see. The larger part of design, however, is invisible: understanding who wants to achieve what, where they get stuck, what they misunderstand, and what happens when something fails. If we skip this foundation, even the most beautiful interface is just uncertainty wrapped in a nice box. This is why the goal of the first lesson is to have precise concepts of what we are actually designing.
What does UX mean?
Take an everyday example: a student signs up for an exam. Their experience does not begin at clicking the "Sign up" button. It begins when they try to find out when the exam period is and where to sign up. It includes whether they understand the conditions, whether they can fill in the form without errors, whether they get a confirmation, and whether two weeks later they can look up which time slot they signed up for. If they are uncertain at any point of the process, that is part of the experience, even if the screen in question looks good on its own.
UX is therefore process and consequence, not a momentary impression. Three questions help keep this in mind:
What does UI mean?
UI, or user interface, is the layer through which the user sees and operates the process: headings, buttons, fields, navigation, icons, colors, spacing, and feedback. The UI matters because the system becomes understandable through it. If buttons do not look like buttons, or the error message is unreadable, even the best process will not work.
The relationship between UI and UX is well shown by the following analogy. The UI is like a restaurant's furnishing, plates, and menu. The UX is the whole dinner: the reservation, the arrival, the waiting, the order of the dishes, the bill, and whether the guest felt good. You can serve a bad dinner on beautiful plates, and you can have an excellent evening in simple surroundings.
A practical consequence: "let's make it more modern" is, by itself, not a design goal. The question is rather: which person, in what situation, cannot yet perform which task confidently, quickly, or fairly enough? The interface provides tools for solving this.
We design a process, not a screen
A task flow is the series of steps, decisions, and states needed to reach a goal. Let us look at an example that will accompany us through the whole course.
On the home screen of Mai program there could be a big, impressive search field. The real experience, however, consists of several steps:
If we design only the screen of the third step, the preceding and following steps are easily lost. An "Available" label is not enough if it is unclear what time the event starts, how much admission costs, and whether advance registration is required. Good UX does not mean everything is visible at once; it means that at the moment of decision, the necessary information is available and understandable.
flowchart LR A["Goal:<br>I'm going out tonight"] --> B["Search"] B --> C["Compare"] C --> D["Decide and register"] D --> E["Confirmation"] E --> F["Before the event:<br>details, cancellation"] C -.->|"finds nothing suitable"| BIn the diagram, the dashed arrow shows that the user's path is rarely linear: they step back, search again, change their mind. Good design takes this into account too.
Touchpoints and service experience
Service experience is the experience of the whole customer journey, which reaches beyond the digital interface. A touchpoint is any moment or channel of the service where the user meets information, an interface, or the organization.
Even with a digital product, it is common that part of the user's journey happens outside the interface. A touchpoint can be an application screen, but equally an email, a push notification, a customer service reply, an automatically generated invoice, a physical location, or another organization's system. In Mai program, for example, the touchpoints are: the search interface, the event page, the registration confirmation email, the reminder before the event, and the organizer who welcomes you at the entrance on site.
Why does this matter? Because the user does not perceive that different teams or systems run these. If the interface promises that your registration was successful, but the email never arrives, the service remains uncertain for the user. From their point of view there is one service, not ten touchpoints.
This does not mean that in a student project every channel has to be designed in full detail. It means that you need to identify the critical points: those where an error or uncertainty makes the user abandon the task or make a wrong decision. A task can be considered closed when the user also knows what happened, what will happen next, and where to ask for help.
UX, UI, and product design
The term product design usually covers understanding the problem, shaping the solution, and aligning it with product goals. Not every organization uses role names the same way: in some places a "UX designer" researches and draws wireframes, elsewhere a "UI designer" does the visual style, and elsewhere a single "product designer" carries the whole thing through. The essence is constant: a design decision is not only taste. It weighs evidence about research, operational constraints, business goals, technology, and the user.
In a login flow, for example, the organization wants to reduce abuse, the developer wants secure identification, and the user wants to log in quickly. A good design does not simply pick one goal over the others. It examines how big the risk of error is, which step is justified, and how the necessary security can be communicated in an understandable way.
Worked example: where is the problem?
In a team's heads, the first idea of Mai program sounds like this: "We need a modern, map-based event app." Not a single word in this sentence is about the user. Before drawing anything, it is worth asking: what can the student not yet do confidently, quickly, or fairly enough?
It may be that students today search through Facebook events, posters, and friends' messages. The main difficulty may not be that there is no map, but that data must be collected from many sources, and it often turns out only on site that the event's price or language is not suitable. If this is true, a "more modern map" does not solve the problem, but "one place with comparable data" does. Whether this is true can be established with the research methods of the following chapters.
Common misconceptions
In brief
Review questions