By the end of the lesson, you can separate the outcome the user wants to achieve, the provider's goal, and the constraints on the solution. You will be able to describe a conflict so that it is visible who gains what, who bears what risk, and which claim is proven and which is only assumed.
Why do we need several perspectives?
In the previous lesson we saw that the experience runs from the user's goal to the consequence. A digital product, however, never belongs only to the user. Someone commissioned it, someone operates it, someone pays for it, and someone builds it on top of an old system. If we see only the user's perspective, we design a solution that nobody can serve. If we see only the organization's, we design one that nobody wants to use. A good designer therefore keeps three things in mind at once: what the user wants, what the organization wants, and what constrains the solution.
Three perspectives, one decision
The user goal
The user goal is not an interface action but the desired outcome. The user does not want to click the "Book" button; they want to get a firm appointment that fits into their day. The click is only a means. The difference matters because if we narrow the goal to the action, the range of solutions stays narrow too: the user could reach the same goal with a reminder, calendar synchronization, or even by phone.
A test for a good user goal: can it be formulated without referring to the interface? "Registering on the site" is not a user goal, because registration is a step the organization asks for. "Finding out what is on in the city tonight" is.
The organizational goal
The organizational goal (also called the business goal) is the outcome desired by the provider or the client. It can be revenue, but it can also be fewer customer service calls, higher satisfaction, lower fraud risk, or better data quality. It is important that the organizational goal is legitimate: a service has to work in order for the user to be able to reach it at all. The designer's job is not to "defeat" the organizational goal, but to see where it meets or collides with the user's.
Example: the operator of Mai program wants as many events as possible on the site, because only then is it worth using. The student wants the event data to be accurate. The two goals are compatible, but they tend to collide: if uploading data is too complicated for the organizer, fewer events or incomplete data get posted, which the student later experiences as an error.
The constraint
A constraint is a fact limiting the room for maneuver of the solution. It can be technical (an old system updates only at night), legal (data protection), organizational (an approval process), financial, or time-related. A constraint is not the same as an excuse. "Technical constraint" is often too general a sentence, worth breaking down:
Which system cannot do something?
What data is missing, and who manages it?
Until when can the process be changed, and who can decide about it?
What is the smallest workaround that is still acceptable for the user?
An old student information system, for example, may update capacity data only at night. This does not mean the user has to guess. You can indicate how fresh the data is ("Last updated last night"), provide alternative information, or confirm the critical decision. The constraint thus becomes part of the design task, not its end.
Why is mixing up the goals dangerous?
If a team calls its own metric a user benefit, it easily creates a manipulative or only short-term solution. For example, to increase newsletter sign-ups, it puts a pop-up on every page. In the short term this may yield more email addresses, but it interrupts the first reading of the content, especially on mobile or with a screen reader.
This does not follow from every organizational goal being bad. Rather, the effect of the decision has to be named. If some data is mandatory to provide the service, say why, when it will be used, and what happens without it. A clear justification is not only an ethical question: it also reduces uncertainty and the chance of wrong data entry.
The decision table
To organize the three perspectives, use a table with three columns. In the first, the user goal; in the second, the organizational goal or operational need; in the third, the constraint and its source. Then give each row an evidence label:
research data: you heard it from someone or observed it;
brief: the client wrote it down;
professional rule: a law, standard, or established practice;
assumption: it seems logical, but you have not verified it.
This is useful because it prevents an assumption from later ending up in the presentation as a fact. For Mai program, for example:
User goal
Organizational goal / need
Constraint
Evidence
Quickly find out what is on tonight
As many events as possible in the system
Event data comes from several places, there is no unified format
assumption
See only events that fit the price and language
Accurate event data
Organizers do not always provide a price
brief
Know for sure whether advance registration is needed
Fewer cancellations
Registrations are handled by an external system
assumption
The "assumption" labels mark the task of the next chapter, user research.
Worked example: the price of registration
The operator of Mai program would like everyone to register before use, because that lets them provide personalized recommendations and measure campaigns. The organizational goal is understandable. The student, however, only wants to decide whether there is anything interesting for them tonight. If registration stands before any use, the first step of the task is the hardest.
The design question is therefore not "is registration needed?", but for which value is identification really necessary? Public browsing can work without logging in; saving favorites and buying tickets can ask for an account. The design thus supports the organizational need as well (personalization is tied to saving), but does not make the first task unjustifiably hard.
Common misconceptions
Claim
Clarification
"More data always gives a better experience."
Only if the data is relevant, its benefit is understandable, and the request is proportionate to the situation.
"Because of the constraint, there is no design decision."
The constraint marks the room for maneuver; the state, explanation, and workaround communicated to the user can still be designed.
"The organizational goal and the user's interest are always opposed."
Often the same good task completion, such as an accurate booking, serves both. The conflict must be identified, not assumed.
"The user goal is what the user asks for."
The requested feature is often a solution proposal. The goal lies behind it (we will cover this in chapter 4).
In brief
The user goal is a desired outcome, not an interface action.
The organizational goal is legitimate but not the same as the user's; name the conflict.
The constraint is part of the design task; break down who can change what and until when.
Evidence labels (research data, brief, professional rule, assumption) protect against an assumption becoming a fact.
Review questions
Why is "registering on the site" not a user goal?
With what questions can a vague technical constraint be broken down?
Give an example of an organizational goal that may have an unwanted user consequence.
Which claim in your project is an assumption that should be checked with research or consultation?
User goal, organizational goal, and constraint
Objectives
By the end of the lesson, you can separate the outcome the user wants to achieve, the provider's goal, and the constraints on the solution. You will be able to describe a conflict so that it is visible who gains what, who bears what risk, and which claim is proven and which is only assumed.
Why do we need several perspectives?
In the previous lesson we saw that the experience runs from the user's goal to the consequence. A digital product, however, never belongs only to the user. Someone commissioned it, someone operates it, someone pays for it, and someone builds it on top of an old system. If we see only the user's perspective, we design a solution that nobody can serve. If we see only the organization's, we design one that nobody wants to use. A good designer therefore keeps three things in mind at once: what the user wants, what the organization wants, and what constrains the solution.
Three perspectives, one decision
The user goal
The user goal is not an interface action but the desired outcome. The user does not want to click the "Book" button; they want to get a firm appointment that fits into their day. The click is only a means. The difference matters because if we narrow the goal to the action, the range of solutions stays narrow too: the user could reach the same goal with a reminder, calendar synchronization, or even by phone.
A test for a good user goal: can it be formulated without referring to the interface? "Registering on the site" is not a user goal, because registration is a step the organization asks for. "Finding out what is on in the city tonight" is.
The organizational goal
The organizational goal (also called the business goal) is the outcome desired by the provider or the client. It can be revenue, but it can also be fewer customer service calls, higher satisfaction, lower fraud risk, or better data quality. It is important that the organizational goal is legitimate: a service has to work in order for the user to be able to reach it at all. The designer's job is not to "defeat" the organizational goal, but to see where it meets or collides with the user's.
Example: the operator of Mai program wants as many events as possible on the site, because only then is it worth using. The student wants the event data to be accurate. The two goals are compatible, but they tend to collide: if uploading data is too complicated for the organizer, fewer events or incomplete data get posted, which the student later experiences as an error.
The constraint
A constraint is a fact limiting the room for maneuver of the solution. It can be technical (an old system updates only at night), legal (data protection), organizational (an approval process), financial, or time-related. A constraint is not the same as an excuse. "Technical constraint" is often too general a sentence, worth breaking down:
An old student information system, for example, may update capacity data only at night. This does not mean the user has to guess. You can indicate how fresh the data is ("Last updated last night"), provide alternative information, or confirm the critical decision. The constraint thus becomes part of the design task, not its end.
Why is mixing up the goals dangerous?
If a team calls its own metric a user benefit, it easily creates a manipulative or only short-term solution. For example, to increase newsletter sign-ups, it puts a pop-up on every page. In the short term this may yield more email addresses, but it interrupts the first reading of the content, especially on mobile or with a screen reader.
This does not follow from every organizational goal being bad. Rather, the effect of the decision has to be named. If some data is mandatory to provide the service, say why, when it will be used, and what happens without it. A clear justification is not only an ethical question: it also reduces uncertainty and the chance of wrong data entry.
The decision table
To organize the three perspectives, use a table with three columns. In the first, the user goal; in the second, the organizational goal or operational need; in the third, the constraint and its source. Then give each row an evidence label:
This is useful because it prevents an assumption from later ending up in the presentation as a fact. For Mai program, for example:
The "assumption" labels mark the task of the next chapter, user research.
Worked example: the price of registration
The operator of Mai program would like everyone to register before use, because that lets them provide personalized recommendations and measure campaigns. The organizational goal is understandable. The student, however, only wants to decide whether there is anything interesting for them tonight. If registration stands before any use, the first step of the task is the hardest.
The design question is therefore not "is registration needed?", but for which value is identification really necessary? Public browsing can work without logging in; saving favorites and buying tickets can ask for an account. The design thus supports the organizational need as well (personalization is tied to saving), but does not make the first task unjustifiably hard.
Common misconceptions
In brief
Review questions