By the end of the lesson, you understand that a component is an interface unit with a repeating role and rules, not just a copyable graphic box. You can design the essential states of a component and the responsive behavior of a screen from the point of view of the task.
Why do we think in components?
If the "Register" button appears on ten screens of a project and you drew each separately, there are two problems. One: if you want to change it, you have to do it ten times. The other, the more serious: the ten buttons are made with small differences, and the user does not know whether they mean the same thing. The component approach asks you to think the repeating element through once and record its rules. This is the foundation of design systems, which we deal with in chapter 9.
What is a component?
A component is an interface unit with a repeating role and documented behavior. Repetition is not an end in itself. If two cards support different tasks, there is no need to force the same form. If, however, a "Register" button signals a different consequence in three places, the user cannot use their earlier knowledge.
A component usually consists of layers: an event card, for example, of an image, a title, a time row, a price indicator, and a button. The designer decides which part is mandatory, which optional, and what happens if it is missing (for example there is no image).
Documenting states
Component states are the smaller-scale counterparts of the UI states learned in chapter 3. A component state is the appearance and operation of the component belonging to a given situation. Make a state list for every critical component. For a text field, for example: default, focus, filled, valid, error, disabled, and loading.
Component
Typical states
Button
default, focus, pressed, disabled, loading
Text field
default, focus, filled, error, disabled
Event card
default, selected, full (unavailable), missing data
Notification
information, success, warning, error
Do not design only a color change: the change should be visible, understandable, and also communicable with a screen reader. For a disabled button, say which condition is missing; for an error state, the way to fix it should also be clear.
Also think of extreme content: a very long event title, a missing image, six tags at once, a two-line price. A component is good as long as it does not break in these cases either.
Responsive behavior
Responsive design is the adaptation of the interface to the screen and the conditions of use, fitted to the task. Responsiveness is not the desktop layout becoming smaller. On a small screen the priority, the order, the input mode, and the available attention can change.
Method: the mobile first approach. First decide what the non-losable core of task and information is on the smallest screen, then build the extensions of the larger view on it. This is good because it forces prioritization.
The places of larger view changes are marked by breakpoints: the widths at which the layout changes meaningfully (for example from one column to two). You do not need many; two or three (mobile, tablet, desktop) are usually enough for a course project.
Common responsive patterns:
Stacking: two columns go one below the other on mobile.
Collapsing: secondary content becomes an expandable section.
Transformation: the horizontal menu turns into a bottom tab bar or a hamburger menu.
Hiding / relocating: a non-essential element moves to a secondary layer; important information should not be lost.
Zoom is also a responsive situation: if at 200% the content is cut off or the action becomes unreachable, the interface is not device-independent (see WCAG in chapter 3).
Worked example: the event card of Mai program
On desktop an event card appears with an image, a title, a description, tags, and two buttons. On mobile the two buttons and the long description crowd out the time and place that are needed for a quick decision. The responsive version keeps the title, time, place, price, language, and registration requirement, and the main action; the detailed description and the secondary action can be opened separately. This is not content loss, but prioritization according to the task.
Component states: default, saved (with a highlighted marker), full (grayed out, with an explanation: "Full, notify me"), missing price ("Price unknown").
Common misconceptions
Claim
Clarification
"A component is only a visual element."
A component carries a role, behavior, and state too.
"Responsiveness is about scaling."
Priority, order, and interaction change too.
"States are the developer's job."
The designer decides what states exist and what they show.
In brief
Component: an interface unit with a repeating role and documented behavior.
Every important component needs a state list and a check against extreme content.
In responsive design, mobile first: first the non-losable task core, then the extension.
Review questions
Which component is used repeatedly in your project?
Which of its states have you not designed yet?
What is the non-losable information core of your screen on mobile?
Components and responsive states
Objectives
By the end of the lesson, you understand that a component is an interface unit with a repeating role and rules, not just a copyable graphic box. You can design the essential states of a component and the responsive behavior of a screen from the point of view of the task.
Why do we think in components?
If the "Register" button appears on ten screens of a project and you drew each separately, there are two problems. One: if you want to change it, you have to do it ten times. The other, the more serious: the ten buttons are made with small differences, and the user does not know whether they mean the same thing. The component approach asks you to think the repeating element through once and record its rules. This is the foundation of design systems, which we deal with in chapter 9.
What is a component?
A component is an interface unit with a repeating role and documented behavior. Repetition is not an end in itself. If two cards support different tasks, there is no need to force the same form. If, however, a "Register" button signals a different consequence in three places, the user cannot use their earlier knowledge.
A component usually consists of layers: an event card, for example, of an image, a title, a time row, a price indicator, and a button. The designer decides which part is mandatory, which optional, and what happens if it is missing (for example there is no image).
Documenting states
Component states are the smaller-scale counterparts of the UI states learned in chapter 3. A component state is the appearance and operation of the component belonging to a given situation. Make a state list for every critical component. For a text field, for example: default, focus, filled, valid, error, disabled, and loading.
Do not design only a color change: the change should be visible, understandable, and also communicable with a screen reader. For a disabled button, say which condition is missing; for an error state, the way to fix it should also be clear.
Also think of extreme content: a very long event title, a missing image, six tags at once, a two-line price. A component is good as long as it does not break in these cases either.
Responsive behavior
Responsive design is the adaptation of the interface to the screen and the conditions of use, fitted to the task. Responsiveness is not the desktop layout becoming smaller. On a small screen the priority, the order, the input mode, and the available attention can change.
Method: the mobile first approach. First decide what the non-losable core of task and information is on the smallest screen, then build the extensions of the larger view on it. This is good because it forces prioritization.
The places of larger view changes are marked by breakpoints: the widths at which the layout changes meaningfully (for example from one column to two). You do not need many; two or three (mobile, tablet, desktop) are usually enough for a course project.
Common responsive patterns:
Zoom is also a responsive situation: if at 200% the content is cut off or the action becomes unreachable, the interface is not device-independent (see WCAG in chapter 3).
Worked example: the event card of Mai program
On desktop an event card appears with an image, a title, a description, tags, and two buttons. On mobile the two buttons and the long description crowd out the time and place that are needed for a quick decision. The responsive version keeps the title, time, place, price, language, and registration requirement, and the main action; the detailed description and the secondary action can be opened separately. This is not content loss, but prioritization according to the task.
Component states: default, saved (with a highlighted marker), full (grayed out, with an explanation: "Full, notify me"), missing price ("Price unknown").
Common misconceptions
In brief
Review questions