By the end of the lesson, you can recognize that the appearance, label, and behavior of an interface element together signal how it is to be used. You consciously choose a known interaction pattern, and you can justify when a solution departing from the familiar helps or obstructs the user's goal. You distinguish between affordance and signifier.
Why design interaction separately?
The wireframe shows what is where. Interaction design asks what happens when the user does something. A button has behavior while being pressed, after, and in case of a failed action. These behaviors determine whether the user trusts the system or doubts it. Interaction design is the field that deals with shaping the actions and responses between the user and the system.
Affordance and signifier
Two concepts are often confused, though their meanings differ. Following the design-theory work of Donald Norman:
An affordance is the possibility of use offered by an object. A door handle can be pulled, a button can be pressed, a slider can be slid. An affordance arises from the relationship between the object and the user: a handle offers a different possibility to an adult and to a small child.
A signifier is the sign that shows that the possibility is there and how it can be used. The label "Pull" on a door, the shadow and label on a button, the faint "Type your name here" text in a field are all signifiers.
You do not need to draw every element as a big, shadowed button. The point is that meaning and behavior match. A "Details" link is navigation; a "Submit registration" button starts a state change. If these are swapped, it is not just a visual inconsistency: it creates a wrong expectation in keyboard and assistive technology use too.
A few common signifiers
Signifier
What does it say?
What to watch for?
Filled, high-contrast rectangle with a label
"Click here" (main action)
The main button should be unique on the screen
Underlined or colored text
"Link"
Do not mark other text next to text in a similar way
Downward arrow
"Expandable"
The arrow should rotate when open
Faded element
"Not available now"
Explain why (chapter 3)
Cursor / focus ring
"This is selected"
Should always be visible
Known patterns and innovation
An interaction pattern is a repeating solution form that is familiar to users. Known patterns reduce the learning cost (Jakob's law: users spend most of their time on other sites, so they expect yours to work the same way). Users know the search field, going back, closing, or submitting a form from many systems.
Departing from them is not forbidden, but the departure must bring a clearly larger benefit. A creative menu animation is not good if it hides where the main navigation is; a novel gesture is not good if it has no visible alternative.
Use the pattern according to the task, not blindly. A deletion needs a different confirmation than changing a filter, because the consequence is different. Too many confirmation windows can cause "alert blindness": the user automatically clicks yes, and the safety step loses its value. A better solution is often undo: "Deleted. Undo" – the user can work quickly, but the safety net remains.
Common interaction patterns
Selection and filtering: checkbox, slider, filter group.
Pop-up element: modal window, tooltip, context menu; each needs a clear way to close.
List and details: clicking a list item opens a detail page or an expanding section.
Drag and drop: only where there is an alternative with keyboard or button.
Feedback during interaction
A state change is an interpretable modification of the system or interface after an interaction. Feedback is the system's response to the user's action. Every action should have a perceivable response. On click, on selection, during drag and drop, or with a long action, the user should know that the system has received their intention. Feedback should not be only animation: it should also signal the content state change. If after selecting an appointment the summary updates, the connection should be visible and understandable.
Three moments of the interaction worth thinking through separately:
Before: the signifier shows that it can be clicked (default state, hover, focus).
During: immediate indication that the system received it (pressed state, loading).
After: a visible result (new state, summary, message).
Worked example: gray events in Mai program
In Mai program some of the gray events can be registered for, some cannot, but the difference becomes clear only after clicking. The problem: the faded element carries two different meanings, and the signifier does not distinguish them. The better solution signals availability in advance (the label of a full event is "Full", the card is faded but clickable for the details), the reason for the disabled state, and the consequence of the choice. The user thus does not learn the system by trial and error, but reads its possibilities from the interface.
Common misconceptions
Claim
Clarification
"If an element is beautiful, its use is self-evident."
Visual attractiveness is not the same as an understandable role.
"Innovation needs a new gesture."
A good innovation eases the task, it does not teach the user new behavior without reason.
"Affordance and signifier are the same."
The affordance is the possibility, the signifier is the sign showing the possibility; digital design mostly shapes signifiers.
"Every action must be confirmed."
Too many confirmations cause alert blindness; undo is often better.
In brief
The affordance is the possibility of use, the signifier is the sign indicating it; on a digital interface we design the signifiers.
The signifier and the behavior should match: a link navigates, a button starts an action.
Depart from a known pattern only for a larger benefit; undo is often better than confirmation.
For every action design a signal before, during, and after.
Review questions
Do the appearance and behavior of your main elements promise the same thing?
Which familiar pattern could help in your project?
Where would more direct feedback be needed after an action?
Which of your signifiers offers a possibility that does not exist?
Interaction patterns, affordances, and signifiers
Objectives
By the end of the lesson, you can recognize that the appearance, label, and behavior of an interface element together signal how it is to be used. You consciously choose a known interaction pattern, and you can justify when a solution departing from the familiar helps or obstructs the user's goal. You distinguish between affordance and signifier.
Why design interaction separately?
The wireframe shows what is where. Interaction design asks what happens when the user does something. A button has behavior while being pressed, after, and in case of a failed action. These behaviors determine whether the user trusts the system or doubts it. Interaction design is the field that deals with shaping the actions and responses between the user and the system.
Affordance and signifier
Two concepts are often confused, though their meanings differ. Following the design-theory work of Donald Norman:
You do not need to draw every element as a big, shadowed button. The point is that meaning and behavior match. A "Details" link is navigation; a "Submit registration" button starts a state change. If these are swapped, it is not just a visual inconsistency: it creates a wrong expectation in keyboard and assistive technology use too.
A few common signifiers
Known patterns and innovation
An interaction pattern is a repeating solution form that is familiar to users. Known patterns reduce the learning cost (Jakob's law: users spend most of their time on other sites, so they expect yours to work the same way). Users know the search field, going back, closing, or submitting a form from many systems.
Departing from them is not forbidden, but the departure must bring a clearly larger benefit. A creative menu animation is not good if it hides where the main navigation is; a novel gesture is not good if it has no visible alternative.
Use the pattern according to the task, not blindly. A deletion needs a different confirmation than changing a filter, because the consequence is different. Too many confirmation windows can cause "alert blindness": the user automatically clicks yes, and the safety step loses its value. A better solution is often undo: "Deleted. Undo" – the user can work quickly, but the safety net remains.
Common interaction patterns
Feedback during interaction
A state change is an interpretable modification of the system or interface after an interaction. Feedback is the system's response to the user's action. Every action should have a perceivable response. On click, on selection, during drag and drop, or with a long action, the user should know that the system has received their intention. Feedback should not be only animation: it should also signal the content state change. If after selecting an appointment the summary updates, the connection should be visible and understandable.
Three moments of the interaction worth thinking through separately:
Worked example: gray events in Mai program
In Mai program some of the gray events can be registered for, some cannot, but the difference becomes clear only after clicking. The problem: the faded element carries two different meanings, and the signifier does not distinguish them. The better solution signals availability in advance (the label of a full event is "Full", the card is faded but clickable for the details), the reason for the disabled state, and the consequence of the choice. The user thus does not learn the system by trial and error, but reads its possibilities from the interface.
Common misconceptions
In brief
Review questions