Maybe you were asked to complete twenty fields in one go. You carefully filled everything out, hit Submit — and only then were you told that your password didn't meet some hidden, unspoken requirement. A requirement that was never communicated upfront.

Instead of helpful guidance, you were met with a vague message: “Invalid input." Invalid how, you wonder?

Required fields weren’t marked. There was no real‑time validation. No helpful red outline showing which field was wrong. Just a generic prompt telling you to “go back and correct missing information,” as if you’re supposed to magically know what the system wants.

So you scroll.

You search.

You guess.

And you're now getting frustrated.

The reason you're frustrated is simple: no one enjoys repeating a task they thought they had already completed — especially when the mistakes could've been prevented with clear guidance along the way.

You manage to fill in the form and you tap the Submit button.

Nothing happens.

No loading spinner.

No subtle animation.

No confirmation message.

No success screen.

Just silence. For a brief moment, you’re left wondering: Did it go through? So you tap again. And maybe… one more time.

At this point, you become fed up and you either postpone the signup process to when you have the time, or you may not ever return.

Even if you haven’t experienced this exact scenario, you’ve almost certainly felt the same kind of friction: that moment when a digital interface makes you pause, hesitate, or wonder what you’re supposed to do next.

These frustrations often arise because frontend developers either overlook or are unaware of the essential design principles and theories that underpin a smooth, intuitive user experience.

As a frontend developer, your interface should minimise cognitive load, provide immediate clarity, and guide users effortlessly through every task.

In this handbook, I'll introduce the academic theories that should inform and elevate your frontend decisions.

Table of Contents

• 1.0 Fitts’s Law:

  • 1.1 Use padding wisely

  • 1.2 Use infinite targets

  • Design Takeaway from Fitts Law:

• 2.0 Hick's Law:

  • Design Takeaway from Hick's Law

• 3.0 Gestalt Principles:

  • Key Gestalt Principles:

  • 3.1 Proximity

  • 3.2 Similarity

  • 3.3 Continuity

  • 3.4 Closure

  • 3.5 Figure/Ground

  • 3.6 Common Fate

  • 3.7 Focal Point

  • Design Takeaways from the Gestalt Principles

• 4.0 Von Restorff Effect (The Isolation Effect):

  • Design takeway from Von Restorff

• 5.0 Jakob’s Law

  • Design Takeaway from Jakob's Law

• 6.0 Miller’s Law

  • Design Takeaway from Miller's Law

• 7.0 The Goal-Gradient Hypothesis

  • Design Takeaway from Goal-Gradient Hypothesis

• 8.0 Zeigarnik Effect

  • Design Takeaway from Zeigarnik Effect

• 9.0 Tesla’s Law:

  • Design Takeaway from Tesla's Law

• 10.0 Peak End Rule:

  • Design takeaway from Peak End Rule

• 11.0 Postel’s Law:

  • Design Takeaway from Postel's Law

• 12.0 Doherty Threshold:

  • Design Takeaways from Doherty Threshold

• 13.0 Serial Position Effect (Primacy and Recency):

  • Design Takeaways Serial Position Effect

• 14.0 Occam’s Razor:

  • Design Takeaway from Occam's Razor

• 15.0 Parkinson's Law

  • Design Takeaway for Parkinson's law

• Conclusion

• References

You might wonder what academic theories have to do with frontend development.

The answer is simple. Academic theories aren't abstract ideas. There are the result of rigorous scientific investigation — controlled experiments, validated models, and decades of research into how humans think, learn, perceive, and interact with information.

Because these theories are grounded in evidence rather than opinion, they offer reliable guidance for building interfaces that align with how the human brain actually processes information.

Applying them to frontend development means you're not designing by guesswork or personal preference. Instead, you're applying tested, scientific insights to create clearer, faster, more humane user experiences.

In other words, when you build with academic theory in mind, your frontend becomes more than just visually appealing — it becomes cognitively efficient, behaviourally aligned, and measurably easier for users to navigate.

You can use the following laws and principles to guide your development work. Let’s start by looking at Fitt’s law.

1.0 Fitts’s Law:

Fitts’s law is the brainchild of Paul Fitts. He was among the early psychologists who recognised that many human errors result from flawed design rather than simple human weakness.

During World War II, he studied airplane cockpit layouts and concluded that numerous incidents attributed to pilot error were actually caused by poor design decisions (Hall, 2023; Budiu, 2022).

Here's the formula:

$$T = a + b \cdot \log_2\left(1 + \frac{D}{W}\right)$$

T = Movement Time

D = Distance to the target

W = Width (size) of the target

a, b = Empirically determined constants

Based on his findings, Fitts postulated that the time required to acquire/reach a target is determined by the distance to the target and the size of the target.

Fig 1.0: Illustration of Fitts Law.

From the above, between Target B and Target C, it will be faster to interact with Target C than Target B simply because of the distance (Target B is farther away). Interestingly, though Target A and Target C are at the same distance, Target C will still be faster to interact with and less error-prone because of its larger size.

In simple terms, Fitt’s Law tells us that the time required to move to a target depends on two main factors: the distance to the target and the size of the target. The farther away an element is, the longer it takes to reach. The smaller it is, the more precision it demands, which increases the interaction time and the likelihood of errors.

Conversely, closer and larger targets reduce cognitive load, motor effort, and frustration.

In a nutshell, Fitts’s main message to developers is to reduce the distance users must travel on the screen and to make important buttons large and visually dominant.

Fig 1.1: Showing Call-to-Action buttons are the largest and most visually prominent elements on each screen.

From the image above, you can see that the Call-to-Action buttons on each of the screens are the most visually dominant button and largest in size. They're also placed within the natural region. This makes them faster/easier to interact with.

You should also place your Call-to-Action button within the natural zone. This is a zone on a mobile phone where it's easy to reach with the thumb (as most people use their thumbs to select things on a phone screen). Here's a diagram showing the "natural zone" on a typical smartphone. It's much faster for a user to interact within the "natural zone" than the "hard zone" (see figure).

Fig 1.2: Showing three different zones for buttons placement (natural, stretching and hard region)

1.1 Use Padding Wisely

Fitts' law can be applied to your development by increasing padding wisely. You can also use padding to increase the interactive area. By doing this, you're increasing the size of the targets.

This is important, because imagine a menu that disappears the moment your cursor drifts a few inches away. You’re weren't trying to close it — you simply moved slightly, and suddenly the entire menu collapses. That tiny slip forces you to start the interaction all over again. It’s a small mistake, but it creates a disproportionately frustrating experience.

This happens because the interactive area is too narrow.

That’s why effective padding — or more broadly, generous interactive zones — is essential. By increasing the clickable or hoverable area around a menu, you are increasing the size of the targets, which makes the interaction more stable, more forgiving, and far less cognitively demanding.

This ensures users can move naturally without fear of accidentally “falling off” the target.

1.2 Use Infinite Targets

Another fundamental principle that emerges from Fitt’s Law is the idea of infinite targets. When an interface element is placed at the very edge or corner of a screen, it becomes effectively “infinite” because the cursor can't move beyond the screen boundary. The edge acts as a physical barrier, allowing the user to fling the mouse in that direction without precision or careful aiming.

As a result, corners and edges become the fastest, easiest, and most reliable places for users to access important controls.

This is why operating systems such as Apple’s macOS and Microsoft Windows position their most essential menus and buttons at these locations. The macOS Apple Menu sits in the top‑left corner, Windows historically placed the Start button in the bottom‑left corner, and both systems anchor taskbars, docks, and notification areas along screen edges.

These placements reduce cognitive load, minimise motor effort, and increase interaction speed because users do not need to slow down or correct their cursor movement. The screen itself “catches” the pointer.

In essence, infinite targets transform small interface elements into large, easy‑to‑hit zones simply by leveraging the geometry of the screen.

What this means for you: place your most important and frequently used actions where users can reach them with the least effort. Screen edges and corners act as natural stopping points, meaning users can't overshoot them.

Design Takeaways from Fitts Law:

Place Primary Actions Where the Task Ends:
Placing a submit button at the top‑right forces users to travel all the way back after completing a long form. This increases interaction cost and breaks flow. The best place for a submit button is at the bottom of the form — exactly where the user finishes the task. This aligns with natural reading and interaction patterns.

Keep Related Actions Physically Close:
Separating “Add to Cart” and “Check Out” across opposite sides of the screen forces unnecessary thumb movement. Group related actions to reduce effort and speed up decisions.

Make Primary Targets Large and Visually Dominant:
Your main CTAs (“Subscribe Now,” “Pay Now,” “Create Account,” “Sign Up”) should be the most recognisable elements on the screen. Large, high‑contrast targets reduce errors and improve speed.

Place High‑Value Actions at Screen Edges and Corners:
Edges and corners act as “infinite targets” because the cursor can’t overshoot them. This makes them the fastest, easiest, and most reliable places for critical controls.

A tiny icon in the middle of the screen is hard to hit. The same icon placed at an edge becomes effectively huge because the boundary “catches” the pointer. Also, actions like navigation, primary CTAs, or global controls should live where users can reach them with minimal effort. Avoid burying important actions in the centre of the screen.

Increase Target Size With Generous Padding:
Small interactive zones force users to aim with pixel‑level precision. Adding padding expands the clickable or hoverable area, making interactions easier, faster, and more forgiving.

Prevent Accidental “Fall‑Off” With Larger Hit Areas:
Menus that collapse the moment the cursor drifts slightly create frustration. A wider interactive zone keeps the menu open during natural mouse movement, reducing accidental resets.

Users don’t move perfectly. Interfaces should accommodate slight slips without punishing them. Larger targets reduce cognitive load and eliminate unnecessary frustration. so by increasing the effective size of buttons, menus, and controls, you create interactions that feel stable and predictable, and users can move confidently without fear of losing their place.

To Sum Up: The farther away an element is, the longer it takes to reach. The smaller it is, the more precision it demands, which increases the interaction time and the likelihood of errors. Conversely, closer and larger targets reduce cognitive load, motor effort, and frustration.

2.0 Hick's Law:

Hick’s Law is a psychological principle that describes the relationship between the number of choices presented to a user and the time it takes them to make a decision. It was formulated by William Edmund Hick in 1952 (Yablonski, 2022; Proctor & Scheider, 2018).

The law states that as the number of options increases, the decision time increases logarithmically. In simple terms, more choices slow users down, while fewer choices speed up decision-making.

$$T = a + b \cdot \log_2(n + 1)$$

Where:

T = time to make a decision,

n = number of choices,

b= a constant that depends on the task and the individual

Figure 2.0 illustrates the relationship between user experience, reaction time, and the number of actions.

This is how users feel, for example, when they encounter a form that asks for too much information upfront. The longer the form gets, the more frustrated they become.

Examples of this are overloading menus with too many items, presenting long, unorganised forms, giving too many calls-to-action on one screen, and building nested menus with excessive depth.

All of these create friction and can lead to cognitive overload.

Design Takeaway from Hick's Law

Avoid Overloading Users With Too Many Actions:
Too many buttons, menu items, or choices at once increases cognitive load and slows decision‑making. Users freeze when everything competes for attention.

Keep Navigation Clean and Focused:
Cluttered menus hurt both usability and SEO. Search engines struggle to track overly complex navigation structures, and users struggle to find what matters.

Use Progressive Disclosure to Reduce Complexity:
Hide advanced or rarely used options under “More” or expandable sections. Reveal complexity only when the user needs it.

Break Complex Tasks Into Smaller, Manageable Steps:
Progressive disclosure works beautifully for multi‑step forms and decision flows. Smaller steps reduce overwhelm and improve completion rates.

Group Related Options Into Logical Categories:
Organising actions into meaningful clusters helps users process information faster. For example, placing “Edit” and “Delete” together leverages natural mental grouping.

Video 2.0: Video description of Progressive Disclosure.

From the video above, instead of showing all the menu details at once, it is better to hide them initially. As you can see, the additional information only appears when the arrow down button is pressed. This approach prevents overwhelming the user and keeps the interface clean and focused.

You should also reduce decision anxiety, as too many choices create doubt and friction (as they say, the more you ask from a user, the less you get).

Beyond this, try to use recommended labels, show brief descriptions, provide visual previews, and use comparison tables wisely to show comparison between products especially when they have many characteristics. An example of a comparison table is shown below:

Figure 2.1: A comparison table being used to simplify complex information.

Also, rather than showing advanced configuration options by default, display only the most commonly used settings. Advanced options can be hidden under an expandable section like “Advanced” or “More Settings. This makes your interface less cluttered and more visually organized.

And speaking of visual organization, this is the perfect moment to introduce Gestalt principles — the psychological rules that explain how users naturally group and interpret what they see.

To Sum Up: As the number of options increases, the decision time increases logarithmically.

3.0 Gestalt Principles:

In the 1920s, a group of German psychologists – Max Wertheimer, Kurt Koffka, and Wolfgang Köhlern – introduced what are now known as the Gestalt Principles. Their work sought to understand how humans perceive and interpret visual information (Bustamante, 2023).

The word “Gestalt” is German for “unified whole,” reflecting the core idea behind the theory: people naturally perceive objects as organised patterns and complete forms rather than as separate, disconnected parts.

These principles explain how the human mind structures visual elements to make sense of the world. Over time, they have become highly influential in fields such as design, user experience (UX), psychology, and data visualization, where understanding perception is critical.

Key Gestalt Principles:

3.1 Proximity

Elements that are placed close to each other are perceived as a group, while those spaced far apart are seen as separate. This is why labels are placed directly next to their corresponding input fields.

For example: In a blog feed, the "Title," "Author," and "Date" should have small margins between them (8px), while the space between one blog post card and the next should be much larger (40px). This tells the user's brain: "These three text strings belong to this specific post."

Fig 3:0 Illustration of proximity (Gestalt Principle)

From the fig above, the spacing within the blog feed plays a powerful role in how effortlessly users interpret what they see. When elements sit close together, the brain instinctively treats them as belonging to the same unit. This is why placing the author credit just 8px beneath the title creates an immediate mental link. The viewer doesn’t need to pause or decode who wrote which article; proximity does the cognitive work automatically, forming a tight, intuitive grouping.

Equally important is the generous 40px gap between individual cards. This larger spacing introduces “visual breathing room.” Without it, a feed can quickly collapse into a dense wall of text, overwhelming the user and discouraging exploration. The wider margin establishes a clear boundary—a natural stop-and-start rhythm—that makes each card feel distinct and the entire layout more scannable.

Finally, subtle spacing differences can guide behaviour, not just perception. The slightly larger 12px margin above the read‑more link separates it from the passive information above it. This spacing cues the user that the link represents an action rather than another piece of descriptive text. It’s a small adjustment, but it shifts the element’s role from informational to interactive, helping users understand what they can do next.

Together, these spacing decisions transform a simple list of posts into a structured, intuitive, and behaviourally clear interface—one where the user never has to think about the layout, because the layout is already thinking for them.

Proximity controls meaning: move elements closer to show connection, separate them to show difference.

3.2 Similarity

We naturally group elements that share similar visual characteristics, such as color, shape, size, or orientation.

For example, even if buttons are spread across a page, if they're all the same shade of blue, the user understands they perform similar functions.

If your primary "Submit" button is blue with rounded corners, every other primary action on your site should look exactly the same. If you suddenly use a square red button for a primary action, the user will be confused because the "similarity" is broken.

Fig 3:1 : illustration of similarity (Gestalt principle)

As you can see from above, the layout clearly demonstrates how the Gestalt Principle of Similarity works by showing two different visual situations: one where everything matches, and one where a single element breaks the pattern.

All three product cards share the same visual characteristics:

• Same card shape

• Same border and shadow

• Same image size and placement

• Same blue “Add to Cart” button

• Same font style and spacing

Because these elements look alike, your brain automatically groups them as one category — “products that belong together.”
You don’t have to think about it; the similarity creates instant visual unity.

This is the Gestalt Principle of Similarity in action.

In the second row, everything is still similar except one button:

• The middle product’s button is orange, not blue

• It has square corners, not rounded

• The text is italic, not regular

• The label changes to “Quick Buy”

Because this button breaks the shared pattern, your brain immediately notices it and treats it as different or special.

Developers can use broken similarity to intentionally highlight featured items, promotions, or urgent actions.

When similarity is broken, the different element stands out and draws attention.

3.3 Continuity

The human eye prefers to follow a continuous path or curve rather than jagged or broken lines. We perceive items aligned on a line or curve as being related. This is often used in navigation menus or horizontal carousels to guide the user's gaze.

For example, you might have a horizontal carousel where the last visible card is slightly "cut off" at the edge of the screen. This visual break creates a path that encourages the user to keep scrolling as their eyes follow the line of cards.

Fig 3:2: illustration of continuity (Gestalt principle)

As you can see, all four form fields — First Name, Last Name, Email Address, and Phone Number — are perfectly aligned along one continuous horizontal path. Because the human eye naturally prefers to follow an unbroken line, your gaze moves smoothly from left to right across the fields without effort.

The final field is slightly cut off at the edge, which creates a subtle visual cue that the line continues beyond the visible area. This encourages the user to keep scrolling or swiping, because their eyes are already following the direction of the form.
when elements are arranged along a straight path, curve, or flow, the brain automatically treats them as connected and expects the pattern to continue.

Another example is Instagram Stories, which are arranged in a smooth horizontal line at the top of the app. Instagram reinforces this by slightly revealing the next story circle at the edge of the screen. That tiny “peek” acts as a continuation cue — your eyes expect the line to keep going, so your finger follows.

Fig 3:3: illustration of continuity (Gestalt principle)

As you can see from above, all the circular story icons are arranged in a straight horizontal line, and your visual system instinctively follows that line from left to right without effort.

The slight visibility of the next story at the edge of the screen strengthens this effect, signaling that the sequence continues beyond what's currently shown. Also, because the icons share the same size, spacing, and shape, there are no visual interruptions, allowing your eyes to glide across them in one continuous motion.

This seamless flow is exactly what continuity describes: the tendency of the human eye to follow the direction of a line or pattern, assuming it continues even when part of it is out of view.

Continuity is the tendency of the human eye to follow the direction of a line or pattern, assuming it continues even when part of it is out of view.

3.4 Closure

Closure refers to the mind’s ability to perceive a complete, unified form even when parts of that form are missing. Rather than requiring every boundary, line, or shape to be explicitly drawn, the brain instinctively fills in the gaps. When used intentionally, closure allows interfaces to feel cleaner, more elegant, and more cognitively efficient.

When we look at a complex arrangement of visual elements, we tend to look for a single, recognisable pattern. If an image is missing parts, our brains fill in the gaps to "close" the shape.

One of the most celebrated examples of closure in visual identity design is the panda symbol used by the World Wide Fund for Nature (WWF). This logo demonstrates how strategic omission can produce a memorable, emotionally resonant, and universally recognisable mark.

At first glance, the panda illustration appears simple, composed of a few bold black shapes arranged against a white background.

Yet a closer look reveals that the panda is not fully drawn. There are no outlines defining the body, no complete contours around the head, and no explicit boundaries separating limbs from background. Instead, the designer uses a series of carefully placed shapes (ears, eye patches, nose, and partial limbs) to imply the rest of the animal. The viewer’s mind fills in the missing information, completing the silhouette effortlessly.

This is closure at its most effective: the brain constructs a whole from fragments, creating a sense of completeness without visual overload.

Fig 3:4: illustration of closure (Gestalt principle)

For example, a "hamburger menu" (three lines) isn't a literal drawer, but our brains "close" the shape to understand it represents a menu.

Fig 3:5: illustration of closure (Gestalt principle)

An example of closure in practice can be seen in step indicators commonly used in checkout flows. These components often rely on partial shapes, implied boundaries, and incomplete outlines to guide the user through a sequence of actions.

For instance, upcoming steps may be represented by dashed circles. Although the circles aren't fully drawn, the viewer immediately recognises them as complete shapes. The brain resolves the missing segments, allowing the interface to communicate progression without heavy borders or fully rendered icons. This subtle use of closure reduces visual clutter while preserving clarity.

Closure refers to the mind’s ability to perceive a complete, unified form even when parts of that form are missing.

3.5 Figure/Ground

This principle describes the mind's tendency to separate an object (the figure) from its surrounding area (the ground or background). In web design, using a "modal" or "pop-up" relies on this: by blurring the background, you force the user to see the pop-up as the focal figure.

When a user clicks "Login" on a modal/lightbox, the background site often dims (the "Ground") while the login box stays bright and centered (the "Figure"). This immediate depth change tells the user exactly where their attention belongs.

Video 3.5.0 Video description of Figure/Ground (Gestalt Principle)

From the video above, you can see that when the Quick View button is clicked, the selected figure stands out while the background darkens. This contrast guides the user’s attention and helps them focus on the figure. Developers can use this technique to direct users’ attention to what matters most or to what they want users to notice.

This principle describes the mind's tendency to separate an object (the figure) from its surrounding area (the ground or background).

3.6 Common Fate

Elements that move in the same direction are perceived as more related than elements that are stationary or move in different directions. Think of a dropdown menu: when all sub-items slide down together, they are clearly part of the same "unit."

For example, when you click a FAQ header and five sub-items slide down at the exact same speed and direction, the "Common Fate" tells the user that all those items belong to that specific category. If they flew in from different directions, the relationship would be lost.

Video 3.6.1 Video description of common fate (Gestalt Principle)

Video 3.6.2 Video description of common fate (Gestalt Principle)

From the video shown above, the e‑commerce animation example demonstrates these principles clearly by using two distinct motion patterns: a group of regular products that move upward together, and a pair of special‑category items that enter dramatically from the left. Through these contrasting movements, the interface communicates category differences without relying on text labels or explicit instructions.

Therefore, developers can use this motion‑based differentiation as a design strategy to guide users’ perception—allowing the interface to signal hierarchy, category structure, and product importance purely through animated behaviour rather than through static visual labels.

Elements that move in the same direction are perceived as more related than elements that are stationary or move in different directions.

3.7 Focal Point

Whatever stands out visually will capture and hold the viewer’s attention first. This is essentially the principle of emphasis. A bright "Sign Up" button in a sea of gray text acts as the focal point, directing the user's primary action.

For example, an alert banner or a pricing table should stand out from its surroundings. Beyond this, in a three-tier pricing table (Basic, Pro, Enterprise), the "Pro" column is often slightly larger or a different color. This creates a focal point that draws the eye to the "recommended" option immediately.

Fig 3:7: illustration of closure (Gestalt principle)

In visual interface design, the Gestalt principle of Focal Point plays a crucial role in directing user attention toward the most important element on a screen.

A focal point is created when one element breaks the established pattern of surrounding elements, making it stand out immediately.

In e‑commerce interfaces, this principle is often applied to highlight primary actions such as purchasing, subscribing, or upgrading. The “Buy Now” button provides a clear and practical example of how focal points function within a layout.

From the example above, the first two buttons share the same visual characteristics: neutral colours, and regular weight text. This repetition establishes a visual pattern that the user quickly becomes familiar with.

But the “Buy Now” button intentionally disrupts this pattern. It uses a bright colour, which contrasts sharply with the muted tones of the other buttons. This colour difference alone is enough to draw the eye, as humans are naturally sensitive to changes in hue and saturation within a uniform environment.

The Focal Point may sound like it's similar to the principle of Similarity, but the two operate in completely opposite ways within perceptual psychology.

Similarity explains how the mind naturally groups elements that share visual characteristics – such as colour, shape, or size – into coherent units. Once this grouping is established, the interface gains structure and predictability.

Focal Point, on the other hand, works by intentionally breaking that structure. Instead of reinforcing uniformity, it introduces a deliberate contrast – through colour, scale, brightness, or motion – to draw the viewer’s attention to one specific element.

In other words, Similarity creates the background pattern, while Focal Point identifies the one element that must stand out against that pattern.

Whatever stands out visually will capture and hold the viewer’s attention first.

Design Takeaways from the Gestalt Principles

Use Spacing as Your Primary Grouping Tool:
Elements that belong together should sit closer to each other than to anything else. Spacing communicates structure faster than borders or boxes. Use tight internal spacing (6–12px) for related items and wide external spacing (24–48px) to separate groups.

Build a Strict, Consistent Visual System — and Stick to It:
Define clear rules for button types, text styles, icon sizes, and alignment patterns. Consistent left‑aligned text blocks, predictable carousel lines, and stable flow patterns reduce cognitive load and make interfaces feel trustworthy.

Guide the Brain With Spacing, Alignment, Consistency, Contrast, and Motion:
The human brain is always trying to group, follow, and prioritise what it sees. Your job is to guide that instinct through intentional layout decisions, not fight against it.

4.0 Von Restorff Effect (The Isolation Effect):

This is the brainchild of Hedwig von Restorff, posited in 1933. In principle it states: An item that stands out is more noticable and more likely to be remembered than other items (Hunt, 1995).

So unique or visually distinct elements grab attention and are more memorable – in other words, distinctiveness dictates memory. When a user interacts with an interface, their brain naturally seeks patterns to minimize cognitive effort.

While consistency is generally a virtue in design, a perfectly uniform layout can lead to "banner blindness" or habituation, where the user stops noticing details.

By strategically breaking a pattern through changes in color, size, shape, or spacing, the developer can "isolate" an element, triggering a biological response that flags the item as high-priority.

Note that although the Focal Point principle may initially seem similar to the Von Restorff Effect, they describe two different psychological processes.

Focal Point is a Gestalt visual principle that explains how one element becomes the centre of attention within a composition because it carries the strongest visual contrast – through size, colour, brightness, position, or motion. Its purpose is to guide the viewer’s eye toward the most important element in the layout.

The Von Restorff Effect comes from cognitive psychology, not Gestalt theory. It states that an item that is noticeably different from a group of similar items is not only more attention‑grabbing but also more memorable.

So Focal Point is about where the eye goes first, while the Von Restorff Effect is about what the brain remembers later.

Design takeaways from Von Restorff

Use Isolation to Make CTAs Impossible to Miss:
On a page filled with neutral text and standard links, a single high‑contrast button (like a bold “Primary Blue” or “Emergency Red”) instantly becomes the standout element. This leverages the Von Restorff Effect to pull the user’s eye toward the most important action.

Create a Visual “Hitch” in the Scan Path:
A distinct CTA interrupts the user’s natural left‑to‑right, top‑to‑bottom scanning rhythm. This makes actions like “Buy Now” or “Sign Up” the first thing they notice and the last thing they forget.

Make Critical Actions Visually Distinct:
Because users naturally notice the one element that breaks a pattern, your most important actions should use deliberate contrast — color, size, shape, weight, or motion. Isolate key information instead of letting it blend into surrounding UI noise.

Avoid Over‑Differentiation — or Nothing Stands Out: If every button is loud, animated, or uniquely styled, the interface becomes chaotic. The Von Restorff Effect only works when there is a clear, stable pattern — and you break it once, intentionally.

To Sum Up: An item that stands out is more noticable and more likely to be remembered than other items.

5.0 Jakob’s Law

Jakob’s Law states that users spend most of their time on other sites, so they expect your interface to behave like the ones they already know.

Familiar patterns — hamburger menus, top navigation, search icons, and clickable top‑left logos — reduce cognitive load because users don’t have to interpret anything new.

But while Jakob’s Law is foundational to UX, I think it can also unintentionally suppress innovation.

When developers over‑prioritise familiarity, they fall into a standardisation trap: endlessly optimising conventional patterns instead of exploring fundamentally better ones.

The Pie Menu is a perfect illustration of this. According to Fitts’s Law, the time required to reach a target depends on its distance and size. Linear menus place the last item much farther from the cursor than the first, creating uneven interaction costs.

Radial menus position every option at an equal distance from the centre, and their wedge‑shaped targets effectively grow larger as the pointer moves outward.

Mathematically, pie/radial menu are faster to interact with and more efficient — yet they remain rare in mainstream web design because they violate users’ expectations. In other words, Jakob’s Law keeps us locked into a familiar but suboptimal pattern simply because “that’s how it’s always been done.”

But the challenge is not choosing between familiarity and innovation, but balancing them.

This is where the Aesthetic–Usability Effect becomes powerful. Research shows that users perceive attractive interfaces as easier to use, and they are more forgiving of minor usability friction when the design is visually pleasing.

A beautifully crafted Pie Menu, for example, can encourage users to invest the small amount of learning required to use it. By applying aesthetic delight strategically, developers can introduce innovative patterns without overwhelming users.

The principle that emerges is simple: Be conventional where it matters, and innovative where it delights.

Design Takeaway from Jakob's Law

Keep Trust‑Critical Elements Predictable:
Navigation, search, authentication, and other high‑stakes interactions must follow established conventions. Users rely on these patterns for speed, confidence, and safety — this is where Jakob’s Law should be respected without exception.

Experiment Only in Low‑Risk, High‑Creativity Areas:
In creative or productivity‑focused zones — like editing tools in a photo app — you can safely introduce new interaction models such as radial menus, gesture wheels, or context‑aware tool selectors. These areas invite exploration and benefit from efficiency‑driven innovation.

To Sum Up: Be conventional where it matters, and innovative where it delights.

6.0 Miller’s Law

Miller’s Law originates from George A. Miller’s classic paper “The Magical Number Seven, Plus or Minus Two.” It states that the average person can hold only about 7 (±2) chunks of information in working memory at any given moment (Miller, 1956).

Crucially, Miller emphasised that the brain doesn’t store isolated items — it groups them into meaningful units called chunks. Because working memory is so limited, developers must structure information in ways that respect this cognitive boundary.

This principle has direct implications for interface design. Long, unbroken strings of information overwhelm users, whereas chunked formats are far easier to process.

For example, instead of displaying a phone number as 1234567890, formatting it as 123‑456‑7890 transforms ten digits into three manageable chunks. The same logic applies to navigation: aim for five to nine primary menu items, and if you need more, group them into categories. Users remember the category as a single chunk rather than each individual link.

Miller’s Law also explains why long forms are so intimidating. When a user sees 30 fields on one page, their brain interprets it as a single, massive task — far beyond the 7±2 limit.

A progressive stepper solves this by breaking the form into smaller stages of 5–7 fields each. This reduces cognitive load, creates a sense of progress, and significantly lowers abandonment rates.

The same principle applies to product listings or search results. Expecting users to compare 50 items at once is unrealistic. Instead, provide strong filtering tools so users can narrow the set to a manageable size — ideally within the range their working memory can meaningfully evaluate.

In essence, Miller’s Law reminds developers that humans don’t process information in bulk. They process it in structured, meaningful chunks.

Fig 6.0: Illustrating progressive stepper

In the example above, the interface uses both a progress bar and a stepper to guide the user through multiple stages of a task. After completing the first page and selecting “Continue,” the user moves to the next step, and the progress bar updates accordingly. This creates a clear sense of forward movement and accomplishment.

By breaking the process into smaller segments, the interface prevents cognitive overload. If all the information were presented on a single page, users might feel overwhelmed, unsure where to begin, or discouraged by the sheer volume of work.

A step‑by‑step flow transforms a large task into a sequence of manageable actions, increasing the likelihood of completion.

Design Takeaway from Miller's Law

Respect the 7±2 Working‑Memory Limit:
Users can only hold about seven chunks of information at once. Long, unbroken content overwhelms them, while chunked information is instantly easier to process.

Chunk Information Into Meaningful Units:
The brain doesn’t store isolated items — it groups them. Format data (like phone numbers), menus, and settings into clear, memorable chunks instead of long, flat lists.

Keep Navigation Within 5–9 Primary Items:
If you need more than nine options, group them into categories. Users remember the category as a single chunk, not each individual link.

Break Long Forms Into Smaller Steps:
A 30‑field form feels like one giant task. A progressive stepper with 5–7 fields per step keeps users below the cognitive overload threshold and dramatically reduces abandonment.

Reduce Comparison Load With Strong Filters:
Expecting users to compare 50 products at once is unrealistic. Provide filtering tools that shrink the decision set to something the working memory can actually handle.

Design for Chunked Thinking, Not Bulk Processing:
Humans don’t process information in bulk — they process structured, meaningful groups. Interfaces that respect this limitation feel lighter, faster, and more intuitive.

To Sum Up: A step‑by‑step flow transforms a large task into a sequence of manageable actions, increasing the likelihood of completion.

7.0 The Goal-Gradient Hypothesis

This is the perfect moment to introduce the Goal‑Gradient Hypothesis, originally proposed by behaviorist Clark Hull in 1932 (Yablonski, 2022). The hypothesis states that people become more motivated as they get closer to achieving a goal. In other words, users naturally accelerate their engagement when they sense they are nearing completion.

This principle is incredibly powerful in UX design, especially for progress tracking, gamification, and reward systems.

The takeaway is straightforward: Because users are more motivated near the finish line, progress indicators should be prominent and meaningful.

Percentages, progress bars, and step counters reinforce momentum. Micro‑achievements — such as badges, checkmarks, or subtle confetti — amplify motivation by celebrating small wins.

Tasks should be broken into measurable milestones so users can see themselves advancing.

This is why e‑learning platforms display messages like “You’ve completed 8 of 10 lessons — almost there!” and why fitness apps highlight progress with prompts such as “3 km done, 2 km to go.” These cues leverage the goal‑gradient effect to keep users engaged, energized, and eager to finish.

By combining progressive steppers with clear progress feedback, developers create interfaces that feel lighter, more encouraging, and far more motivating — ultimately improving completion rates and overall user satisfaction.

But what happens when a goal isn't completed? Why do we sometimes feel uncomfortable leaving things unfinished? That discomfort is explained by another psychological principle called the Zeigarnik Effect — the tendency for people to remember and feel tension about incomplete tasks. We will look at this next.

Design Takeaway from Goal-Gradient Hypothesis

Make Progress Visible to Boost Motivation:
According to the Goal‑Gradient Hypothesis, users naturally speed up as they sense they’re nearing completion. Prominent progress bars, percentages, and step counters tap into this instinct and keep momentum high.

Celebrate Micro‑Achievements to Reinforce Engagement:
Badges, checkmarks, subtle confetti, and “step completed” cues reward small wins. These micro‑rewards amplify motivation and make long tasks feel lighter and more achievable.

Break Tasks Into Measurable Milestones:
Users stay motivated when they can see themselves advancing. Divide complex flows into clear steps so progress feels tangible rather than overwhelming.

Use Progress Feedback to Drive Completion:
Messages like “8 of 10 lessons completed — almost there” or “3 km done, 2 km to go” leverage the goal‑gradient effect to energise users and pull them toward the finish line.

Combine Steppers With Clear Feedback for Maximum Impact:
Progressive steppers paired with strong visual feedback create interfaces that feel encouraging, structured, and motivating — dramatically improving completion rates.

Video 8.0 : Video illustrating goal gradient

To Sum Up: People become more motivated as they get closer to achieving a goal.

8.0 Zeigarnik Effect

The Zeigarnik Effect is a psychological principle stating that people remember unfinished or interrupted tasks better than completed ones (Cherry, 2024).

Memory begins with sensory input, which is processed into short-term memory. Unfinished tasks persist in our thoughts, leading to active recall. This ongoing engagement can turn them into long-term memories, enhancing recall until resolved. This increases engagement, encourages task completion, improves retention, and drives conversions.

So because people remember unfinished tasks better than completed ones (Zeigarnik Effect), developers use progress indicators to make users aware that something is incomplete and motivate them to finish it.

In your designs, you can break long forms into multi-step processes to encourage completion and display profile completion percentages (for example, 70% complete) to push users toward 100%.

This is the main reason why e-commerce platforms send abandoned cart reminders to bring users back to complete their purchases. It's also why apps use streak systems to encourage daily engagement and habit formation and learning platforms show course completion bars to motivate users to finish modules.

Design Takeaway from Zeigarnik Effect

Unfinished Tasks Stay Active in Memory — Use That to Drive Completion:
Because incomplete tasks linger in working memory (Zeigarnik Effect), users naturally keep thinking about what they haven’t finished. This tension boosts recall, engagement, and the likelihood of returning to complete the task.

Make Incompleteness Visible With Progress Indicators:
Progress bars, percentages, and step counters remind users that something is still unfinished. This gentle psychological pressure motivates them to continue until the task is complete.

Break Long Flows Into Multi‑Step Processes:
A massive form feels overwhelming, but a stepper with smaller chunks keeps users moving. Showing “70% complete” nudges them toward finishing the last stretch.

Use Reminders to Re‑activate Unfinished Intent:
Abandoned cart emails, streak reminders, and “continue your lesson” prompts work because the unfinished task is already active in the user’s mind. The reminder simply pulls them back into the loop.

Celebrate Completion to Close the Cognitive Loop:
Checkmarks, confirmations, and completion badges give users closure. This resolves the mental tension created by the unfinished task and reinforces positive behaviour.

To Sum Up: Unfinished tasks persist in our thoughts, leading to active recall.

9.0 Tesler’s Law:

This law was proposed by Lawrence Tesler. He was a computer scientist known for his work on human-computer interaction, and he contributed significantly to making software more user-friendly, including work on cut, copy, and paste functionality.

This law is otherwise known as the Law of Conservation of Complexity. The core Idea here is every process has a certain amount of “inherent complexity" that can't be removed. You can only decide who handles it: the user or the system.

Some examples of these inherent complexities might be:

• translating user actions into correct operations behind the scenes,

• handling unreliable or slow network connections,

• connecting with third-party APIs, services, or legacy systems,

• sorting large datasets quickly,

• performing complex search operations

• managing version changes and compatibility issues,

• managing state, interactions, and animations without confusing the user.

All of these can be inherently complex, but it's the job of the developer to deal with the complexity.

As a developer, you should always try as much as possible to push complexity to the system. For example, instead of making a user type their full address manually, use an Auto-complete API (Google’s Places and Map is best for this). The complexity of finding and validating the address still exists, but the software handles the work for them.

Here's a practical example: let’s say you're designing a student platform that requires users to enter their university name. A practical approach would be to store an array of all universities in the UK in your codebase (This is the hard part Tesla hinted at).

As the user types, they don't need to enter the full name, and their full university name is shown (relating to what they have typed). For instance, if they intend to type “University of Sheffield,” simply typing “Sheff” should prompt the system to display the full university name, which they can then select.

In Dart, you can use a package like fuzzysearch to implement this kind of intelligent matching.

The advantage of this approach is greater than it first appears. It improves data consistency because users often enter the same information in different ways. For example, some users might type “Uni of Sheff,” others “Sheffield University,” and others “Uni of Sheffield,” while all are referring to “University of Sheffield.”

This is how messy data is created, and it creates more work for data analysts. Little wonder that data analysts spend up to 70% of their time cleaning data.

If developers invested more time in structuring how data is collected to ensure consistency, there would be far less work downstream for analysts. This same logic should be applied in how we collect date, time, and other information.

So apart from people's names and email addresses, you should try to standardize the data your app collects as much as possible. Use date and time pickers, stepper controls, input masks, checkboxes, dropdown menu and radio buttons, toggle switches. and so on.

The essence of removing complexity from the user is not only about improving usability, but also about ensuring that the data collected is standardised, structured, and consistent.

Design Takeaway from Tesler's Law

Push Complexity to the System, Not the User:
Every process contains unavoidable complexity. Your job is to handle it behind the scenes so the user experiences the simplest possible interaction.

Automate Tasks Users Shouldn’t Have to Think About:
Use tools like autocomplete, fuzzy search, intelligent defaults, and validation APIs to remove manual effort. The complexity still exists — but the system absorbs it instead of the user.

Standardise Inputs to Prevent Messy Data:
Users enter the same information in wildly different ways. Use pickers, dropdowns, input masks, radio buttons, and toggles to enforce consistent, structured data collection.

Handle Inherent Technical Complexity Internally:
Network issues, API quirks, large dataset sorting, search optimisation, state management, and animation logic are all developer responsibilities. Users should never feel this complexity.

To Sum Up: Every process contains unavoidable complexity. Your job as a developer is to handle it behind the scenes so the user experiences the simplest possible interaction.

10.0 Peak End Rule:

In 1993, Daniel Kahneman, Barbara Fredrickson, Charles Schreiber, and Donald Redelmeier invited volunteers into a lab for what sounded like a simple experiment. The task was straightforward: place a hand into a container of painfully cold water (Kahneman et al., 1993)

In the first round, participants kept their hand in 14°C water for 60 seconds. It was uncomfortable, sharp, and unpleasant but after one minute, it was over.

In the second round, they again endured 60 seconds in 14°C water. But this time, they were asked to keep their hand in for an extra 30 seconds. The temperature was raised slightly to 15°C. Still cold. Still unpleasant. Just slightly less intense.

Objectively, the second experience was worse. It lasted 90 seconds instead of 60. More total pain. More suffering.

Later, the researchers asked a simple question:

If you had to repeat one of the trials, which would you choose?” Surprisingly, most participants chose the longer one.

Why would anyone choose more pain?

The researchers realised something profound: people don’t remember experiences by calculating total discomfort. Instead, the mind summarizes the experience using just two key moments — the most intense point (the peak) and the final moment (the end).

In both trials, the peak pain was the same: 14°C. But the longer trial ended slightly better, at 15°C. That small improvement at the end reshaped how the entire episode was remembered. The participants’ “experiencing self” suffered more during the longer trial. But their “remembering self” preferred it because it ended on a less painful note.

From this, the researchers introduced what became known as the Peak–End Rule: we judge experiences largely by their most intense moment and how they finish, not by how long they last.

Since people largely judge an experience by how it ends, developers should focus on designing satisfying confirmation screens and smooth exit interactions. You should concentrate less on making every single moment perfect and instead prioritise optimising the peak and final moments.

A negative ending can overshadow an otherwise good experience, so carefully avoid frustrating final steps such as unexpected fees or confusing confirmations.

Emotional intensity strongly shapes memory, which is why many apps incorporate celebration animations, rewards, or success messages at key moments to leave a lasting positive impression.

Design takeaway from Peak End Rule

People Judge Experiences by the Peak and the Ending — Not the Total Duration:
Users don’t remember every moment. They remember the most intense point and how the experience ends. A slightly better ending can completely reshape how the entire interaction is remembered.

Prioritise Strong, Positive Endings in Your UX Flows:
A smooth final step, a clear confirmation, or a satisfying success screen leaves a disproportionately strong impression. A bad ending can overshadow an otherwise great experience.

Design for Emotional Peaks at Key Moments:
Celebration animations, rewards, checkmarks, and success messages create memorable emotional spikes. These peaks anchor the experience in the user’s memory.

Don’t Try to Perfect Every Moment — Perfect the Right Moments:
Optimise the peak and the end of the journey. These two moments define how users recall the entire interaction.

Avoid Negative Surprises at the Finish Line:
Unexpected fees, confusing confirmations, or friction at the last step can ruin the memory of the whole process. Protect the ending carefully.

To Sum Up: We judge experiences largely by their most intense moment and how they finish, not by how long they last.

11.0 Postel’s Law:

Jon Postel’s famous principle – “Be conservative in what you send, be liberal in what you accept” –  is a philosophy of kindness in software design. At its core, the principle argues that systems should be generous with what they accept from users, yet disciplined and predictable in what they output.

When developers follow this approach, users feel supported and understood. When they don’t, users feel punished for being human.

A user’s input is rarely perfect. People type quickly, make mistakes, follow their own habits, or rely on formats familiar to them. A robust system embraces this reality. It accepts messy, human input and quietly transforms it into clean, standardized data.

Real people don't think in strict formats. They write dates the way they learned in school, type phone numbers the way they say them aloud, and enter names and addresses in whatever structure feels natural to them.

A rigid system will reject anything that doesn’t match its narrow expectations, but a robust system, by contrast, adapts to the user.

Consider dates. A brittle interface might demand MM/DD/YYYY and reject everything else. A more humane system accepts a wide range of formats — “1 May 2024,” “2024‑05‑01,” “05/01/24,” or “May 1st, 2024” — and quietly converts them into a standard internal representation. This is where the complex handling described by Tesla's Law comes into play (Shifting complexity to the system, rather than the user).

Phone numbers follow the same pattern. People might enter (555) 123 4567, 555‑123‑4567, 5551234567, or +1 555 123 4567. A fragile system throws errors. A robust one parses all of them using libraries like libphonenumber and moves on.

Addresses are equally varied. “221B Baker St,” “221‑B Baker Street,” and “221 Baker St., Apt B” all refer to the same place. A forgiving system normalizes these instead of rejecting them.

Even names can be surprisingly complex. Hyphens, apostrophes, multiple words, and titles are all part of real human identity. Rejecting “O’Connor,” “Jean‑Luc,” or “Dr. Sarah Lee” is not just technically incorrect — it's disrespectful to the user.

Search bars offer another clear example. A strict search bar demands perfect spelling and exact phrasing. A robust one handles typos (“restuarant”), partial words (“resta”), synonyms (“food places”), and natural language (“where can I eat nearby”). It meets the user where they are instead of forcing them to think like a machine.

Currency should be normalized to a clear format such as GBP 5.00, no matter whether the user typed “£5,” “5 pounds,” or “5 GBP.”

Even file uploads benefit from standardization: whether the user uploads .jpeg, .jpg, .JPG, or .JPEG, the system should store everything as .jpg.

Error messages follow the same principle. Vague feedback like “Invalid password” leaves users confused and frustrated.

A clear, conservative message — “Incorrect password. Please try again.” — respects the user’s time. And instead of hiding password requirements, the system should state them upfront: minimum eight characters, at least one uppercase letter, at least one number.

Predictability reduces friction.

Because users inevitably make mistakes or enter data in unexpected ways, developers should design input fields that are tolerant rather than brittle. This means accepting flexible formats, offering autocorrect or intelligent parsing, and using forgiving validation rules that interpret the user’s intent instead of rejecting their effort.

Clear instructions, tooltips, and visible requirements should appear before submission so users understand what the system expects without trial and error.

When errors do occur, the interface should handle them gently—never crashing, and never forcing the user to start over.

Even simple variations, such as phone numbers typed with spaces, dashes, or parentheses, should be accepted and normalized behind the scenes.

By embracing flexibility on the input side and clarity on the output side, developers create systems that feel humane, resilient, and respectful of the way real people actually behave.

Design Takeaway from Postel's Law

Accept Messy Human Input, Output Clean Structured Data:
Users type dates, names, phone numbers, and addresses in unpredictable ways. A humane system accepts this variability and quietly normalises it into a consistent internal format.

Rigid interfaces punish users for being human. Robust interfaces interpret intent — handling typos, partial matches, synonyms, and natural language without complaint.

Also accept variations in spacing, punctuation, casing, and structure. Let users type naturally — the system should handle the complexity, not them.

Be Flexible With Input, Be Strict With Output:
This is the heart of Postel’s Law. Let users express information naturally, but ensure your system stores and displays it in a predictable, standardised way.

Use Intelligent Parsing and Autocorrection to Reduce Errors:
Libraries like libphonenumber, fuzzy search, and natural‑language parsers allow systems to accept a wide range of formats while still producing clean, reliable data.

Normalise Everything Behind the Scenes:
Dates, phone numbers, currency, file extensions, and addresses should all be standardised internally. This prevents messy data and reduces downstream cleanup work.

Provide Clear, Predictable Feedback:
Error messages should be specific and helpful. Requirements should be visible upfront. Users should never be surprised, confused, or forced to start over.

Combine Postel’s Law With Tesler’s Law:
Shift complexity to the system. Intelligent handling of messy input reduces cognitive load, improves usability, and ensures consistent, high‑quality data.

To Sum Up: A rigid system will reject anything that doesn’t match its narrow expectations, but a robust system, by contrast, adapts to the user.

12.0 Doherty Threshold:

The Doherty Threshold is a principle in human–computer interaction which proposes that systems should respond quickly enough to keep users actively engaged (Mod 2024).

When response times stay below a certain limit, users remain focused and productive. But once performance already meets this optimal responsiveness level, making the system even faster or adding extra capability doesn't significantly enhance satisfaction or efficiency.

The idea was introduced by Walter J. Doherty in 1976 in his paper “A Comparison of Programming Systems and Doherty Threshold.” His research showed that maintaining rapid system feedback fast enough to sustain continuous interaction has a stronger impact on productivity than simply increasing system power or features beyond that point.

Doherty proposes that this shouldn't be greater than 400ms Rule: If the system responds within this window, the user feels in total control. If the response takes longer, the user's attention begins to wander, and their "train of thought" is broken.

The challenge, of course, is that not every operation can realistically complete within 400ms. Some tasks require heavy computation, large network calls, or complex rendering. This is where the concept of perceived performance becomes essential.

Even when the system can't finish the work quickly, it can feel fast by responding instantly at the UI level. Developers can achieve this illusion of speed through a combination of thoughtful design patterns and disciplined engineering practices.

On the technical side, performance begins with reducing unnecessary work. Keeping the number of HTML elements low helps the browser render faster. Rendering only the visible portion of long lists prevents the Document Oject Model (DOM) from becoming bloated. Splitting scripts and deferring non‑critical code ensures that essential interactions load first.

Using CSS transforms and opacity changes avoids expensive layout recalculations. Lazy‑loading images, videos, and scripts ensures that the interface becomes interactive long before all assets are downloaded.

These optimizations don’t just improve raw speed — they create the foundation for interfaces that feel responsive.

Design Takeaways from Doherty Threshold

Instant Feedback: When a user clicks a button, provide a visual change (like a button press animation or a spinner) immediately, even if the background task takes longer.

Skeleton Screens: Use placeholder blocks that mimic the layout of the page while data loads. This makes the app feel like it is responding instantly.

Progressive Loading: Load text and basic structures first, then "pop in" high-resolution images later.

Optimistic UI: When a user hits "Save," don't wait for the server. Update the UI instantly (Doherty) and handle the "messy" data formatting on the backend (Postel).

Live Inline Validation: Show a green checkmark or a helpful error message as the user types. This keeps them below the 400ms "thought-break" limit.

Debouncing: In search bars, start showing results after a few keystrokes so the user feels the app is "predicting" their needs.

To Sum Up: When response times stay below a certain limit, users remain focused and productive. But once performance already meets this optimal responsiveness level, making the system even faster or adding extra capability doesn't significantly enhance satisfaction or efficiency.

13.0 Serial Position Effect (Primacy and Recency):

Murdock’s study investigated how the position of a word in a list affects recall, known as the serial position effect. He presented 103 psychology students with lists of 10 to 40 words, one at a time, at either 1 or 2 seconds per word (McLeod, 2025).

Participants were divided into six groups, each experiencing a different combination of list length and presentation rate, and were asked to recall as many words as possible in any order.

The results showed that participants were most likely to remember words at the beginning of the list (primacy effect) and at the end of the list (recency effect), while words in the middle were recalled less often. The recency effect persisted even in longer lists, and the middle section of the recall curve formed a flat asymptote.

Murdock explained this using the multi-store model of memory: early words were rehearsed and transferred to long-term memory, last words remained in short-term memory, and middle words were neither sufficiently rehearsed nor retained, leading to poorer recall.

The experiment demonstrated that memory performance varies systematically with the position of information in a sequence.

This is the reason why the most important information or actions should never be buried in the middle.

As a developer, you should put your most critical navigation links (like "Home" or "Dashboard") at the far left or the top of a list. In a pricing table, put the most popular or recommended plan on the Place "Final Actions" (like "Log Out," "Cart," or "Support") at the end of a menu or the far right of a navigation bar.

In a long onboarding flow, put the most exciting benefit of the app on the very last slide so the user enters the app feeling motivated.

Avoid placing highly important buttons in the middle of a row. If you have a row of 7 buttons, the user is statistically likely to overlook the 4th one.

Design Takeaways Serial Position Effect

Place Critical Items at the Beginning or End — Never the Middle:
Users reliably remember the first and last items in any sequence (primacy and recency). Anything placed in the middle is statistically more likely to be forgotten or ignored. Also, actions such as “Log Out,” “Cart,” “Support,” or “Checkout” should sit at the far right or bottom — the natural recency position.

Put Essential Navigation Links at the Far Left or Top:
Links like “Home,” “Dashboard,” or “Overview” should appear at the start of a menu, where recall and recognition are strongest.

To Sum Up: The results showed that participants were most likely to remember words at the beginning of the list (primacy effect) and at the end of the list (recency effect), while words in the middle were recalled less often.

14.0 Occam’s Razor:

Although first articulated in the 14th century by the Franciscan friar William of Ockham, Occam’s Razor remains one of the most indispensable principles in a developer’s toolkit. In fact, skipping this law while discussing other theories and principles would be like skipping the glue that holds the entire framework together.

At its core, Occam’s Razor states that “among competing explanations, the simplest one is usually the best.”

For example, if two user interfaces achieve the same goal, the one with fewer visual elements is typically superior because it requires less processing power.

The fundamental takeaway for modern developers regarding Occam’s Razor is that complexity is a tax on the user’s cognitive resources.

In an era of information density, the developer's primary role is no longer to provide "more" features – rather, it's to curate the most direct path to a solution.

In practice, Occam’s Razor becomes a reminder to keep things as simple as possible. This “less is more” mindset shapes everything from navigation to forms.

A good rule for navigation is the Rule of Five: aim for three to five main menu items instead of a long, overwhelming list. This keeps choices clear and prevents users from freezing up when they see too many options.

The same idea applies to data entry. When you ask only for the information that truly matters, you respect the user’s time and reduce the chance of “form fatigue,” which is one of the biggest reasons people abandon sign‑ups or checkout flows.

Simplicity isn’t just elegant — it’s practical, humane, and far more effective.

Design Takeaway from Occam's Razor

Choose the Simplest Effective Solution:
When two designs achieve the same goal, the one with fewer elements is almost always better. Simplicity reduces cognitive load and speeds up user decision‑making.

Simplicity Is Not Just Aesthetic — It’s Humane:
Clear, minimal interfaces respect the user’s time, reduce friction, and make the product feel effortless. Simplicity is both a design strategy and an act of empathy.

To Sum Up: Simplicity isn’t just elegant — it’s practical, humane, and far more effective.

15.0 Parkinson's Law

Occam’s Razor teaches us to prefer the simplest solution that works. But why do we so often end up with complex systems in the first place? That tendency is explained by another principle: Parkinson’s Law.

Parkinson’s Law states that "work expands to fill the time available for its completion". In design, this means projects often become overly complex or take longer than necessary if given too much time, resulting in inefficient, over-designed, or cluttered interfaces.

In design, this manifests as Feature Creep. If you give yourself three months to build an app, you will spend three months adding "nice-to-have" animations, extra settings toggles, and niche edge cases that nobody asked for and in reality, what you have added isn’t that important.

You just succeeded in adding layers of complexity that might ends up violating some of the laws we spoke about. Occam’s Razor reminds us that the simplest solution is often the most effective.

By being aware of Parkinson’s Law and the tendency for work to expand, developers can manage their time intentionally and focus only on what truly matters.

Design Takeaway for Parkinson's law

Set Clear Constraints to Keep Designs Focused:
Intentional time limits and scope boundaries prevent over‑designing. Constraints force clarity, prioritisation, and simplicity.

Build Only What Truly Matters for the User:
Parkinson’s Law reminds you to resist the urge to fill time with unnecessary features. Focus on the core experience, not the edge cases nobody asked for.

Use Occam’s Razor to Counterbalance Parkinson’s Law:
As work expands, complexity grows. Occam’s Razor pulls you back to the simplest effective solution. Together, the two principles prevent bloated, over‑engineered products.

To Sum Up: Work expands to fill the time available for its completion

Conclusion

Human-centered design is deeply influenced by a set of psychological principles that explain how users perceive, process, and interact with digital systems.

Among these, Fitts’s Law establishes that the time required to acquire a target depends on its size and distance. In practice, this means that larger and closer elements are easier and faster to interact with.

To apply this in practice, developers should make primary call-to-action elements prominent, large, and easily reachable – especially in mobile interfaces where thumb accessibility is critical.

Closely related to decision-making is Hick’s Law, which states that the more choices a user is presented with, the longer it takes to make a decision. Excessive options can overwhelm users and lead to decision fatigue.

To address this, developers should simplify interfaces, minimise unnecessary options, and guide users through processes step-by-step rather than presenting everything at once.

Another important cognitive principle discussed is Miller’s Law, which suggests that the average person can hold approximately seven (plus or minus two) items in working memory at a time. This limitation highlights the need to present information in manageable chunks.

By breaking content into smaller groups and avoiding information overload, developers can improve comprehension and usability.

User expectations are strongly shaped by Jakob’s Law, which says that people spend most of their time on other websites and therefore expect similar patterns across digital products.

Instead of reinventing basic interactions, developers should follow familiar conventions such as placing the logo in the top‑left, the shopping cart in the top‑right, and keeping scrolling behaviour predictable.

But innovation is still possible where it truly adds value. As we discussed with the Aesthetic‑Usability Effect, users are far more tolerant of new or unusual design patterns when the interface is visually appealing and thoughtfully crafted.

The Gestalt Principles provided additional insight into how users visually organise information. The principle of proximity suggests that objects placed close together are perceived as related, so grouping related elements improves clarity. Similarity indicates that elements with consistent colours, shapes, or styles are seen as belonging together, reinforcing visual hierarchy and function. Closure explains that users can perceive incomplete shapes as complete, allowing for minimalistic designs where the brain fills in missing details. Continuity highlights that users naturally follow smooth visual paths, meaning layouts should guide the eye logically through alignment and structure.

We also looked at The Von Restorff Effect which emphasizes that elements which stand out are more likely to be remembered. By using contrast in colour, size, or design, important features such as buttons or alerts can capture user attention.

Managing complexity was addressed by Tesler’s Law, which asserts that every system has inherent complexity that cannot be eliminated but only managed.

Developers must therefore shift complexity away from the user by simplifying interfaces while handling intricate processes behind the scenes.

The Zeigarnik Effect reveals that people remember unfinished tasks better than completed ones, creating a sense of mental tension. This can be leveraged by incorporating progress indicators, checklists, and reminders that encourage users to complete tasks.

Similarly, the Peak-End Rule suggests that users judge an experience based on its most intense moment and its conclusion. Developers should create memorable highlights and ensure a smooth, satisfying ending to user journeys.

We also discussed the Goal-Gradient Effect, which explains that users become more motivated as they approach the completion of a task. By showing progress –such as indicating that a process is “80% complete” – and breaking tasks into stages, developers can encourage users to finish what they have started.

In terms of system interaction, Postel’s Law advises developers to be flexible in accepting user input while maintaining strict standards for output. This means allowing different input formats while ensuring consistent and reliable system responses.

Performance is equally important, as highlighted by the Doherty Threshold, which shows that productivity increases when system response times stay under 400 milliseconds. Fast systems keep users engaged and create a sense of ease.

This means that developers should focus on building interfaces that feel instant, even when real processing takes longer, by combining smart engineering practices with thoughtful design patterns that maintain the illusion of speed.

Memory and attention are further explained by the Serial Position Effect, where users tend to remember the first and last items in a sequence more than those in the middle. Developers should position key information or actions at the beginning or end of lists.

Simplicity is reinforced by Occam’s Razor, which argues that the simplest solution is often the most effective. Eliminating unnecessary features reduces friction and enhances usability, and we further discussed about Parkinson’s Law, which suggests that tasks expand to fill the time available, indicating the importance of setting constraints such as deadlines or timers to encourage timely action.

These principles collectively highlight the importance of simplicity, clarity, performance, and user psychology in design. By applying them thoughtfully, developers can create intuitive, efficient, and engaging user experiences that align with both human behaviour and user expectations.

References

Budiu, R. (2022). Fitts’s Law and Its Applications in UX. [online] Nielsen Norman Group. Available at: https://www.nngroup.com/articles/fitts-law/.

Bustamante, N. (2023). Gestalt Psychology? Definition, Principles, & Examples - Simply Psychology. [online] www.simplypsychology.org. Available at: https://www.simplypsychology.org/what-is-gestalt-psychology.html.

Cherry, K. (2024). The Zeigarnik Effect Is Why You Keep Thinking of Unfinished Work. [online] Verywell Mind. Available at: https://www.verywellmind.com/zeigarnik-effect-memory-overview-4175150.

DO, A.M., RUPERT, A.V. and WOLFORD, G. (2008). Evaluations of pleasurable experiences: The peak-end rule. Psychonomic Bulletin & Review, 15(1), pp.96–98. doi:https://doi.org/10.3758/pbr.15.1.96.

GUPTA, S., GUPTA, S., MAHENDRA, A. and GUPTA, S. (2006). Inverse Halo Nevus. Dermatologic Surgery, 32(6), pp.871–872. doi:https://doi.org/10.1097/00042728-200606000-00025.

‌Hall, D. (2023). Pilot Error, Chapanis and The Shape of Things to Come. [online] UX Magazine. Available at: https://uxmag.com/articles/pilot-error-chapanis-and-the-shape-of-things-to-come.

Hunt, R.R. (1995). The subtlety of distinctiveness: What von Restorff really did. Psychonomic Bulletin & Review, 2(1), pp.105–112. doi:https://doi.org/10.3758/bf03214414.

Kahneman, D., Fredrickson, B.L., Schreiber, C.A. and Redelmeier, D.A. (1993). When More Pain Is Preferred to Less: Adding a Better End. Psychological Science, 4(6), pp.401–405. doi:https://doi.org/10.1111/j.1467-9280.1993.tb00589.x.

Mod, D. (2024). Doherty Threshold: UX Law of Swift Interactions. [online] Articles on everything UX: Research, Testing & Design. Available at: https://blog.uxtweak.com/doherty-threshold/.

Miller, G.A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, [online] 101(2), pp.343–352. doi:https://doi.org/10.1037/0033-295x.101.2.343.

Proctor, R.W. and Schneider, D.W. (2018). Hick’s law for choice reaction time: A review. Quarterly Journal of Experimental Psychology, [online] 71(6), pp.1281–1299. doi:https://doi.org/10.1080/17470218.2017.1322622.

Yablonski, J. (2022). Hick’s Law. [online] Laws of UX. Available at: https://lawsofux.com/hicks-law/.

Yablonski, J. (2022). Goal-Gradient Effect. [online] Laws of UX. Available at: https://lawsofux.com/goal-gradient-effect/.

‌

‌

‌

Whether you're a designer, writer, or product builder, you’ll learn practical tips, real-world examples, and actionable principles you can start applying today.

Table of Contents

• The Problem

• So, What Exactly Is Microcopy?

• Why Designers Should Be Microcopy Maestros

• Why Does Microcopy Matter More Than You Think?

• Five Principles for Crafting Microcopy That Converts

• Everyday Microcopy Examples That Boost UX

• Wrapping Up

The Problem

Recently, my team and I were redesigning the onboarding and sign-up experience for a kids’ streaming platform that we planned to test in the market. The platform was completely free, but there was one big problem: people weren’t signing up. Many potential users seemed to assume it was just another paid streaming service and dropped off before even trying it.

During one of our team sessions, a designer suggested something simple yet powerful: “Maybe people think it’s not free. What if we just say that clearly?” So we added five little words right below the sign-up button: “No credit card required.”

That’s it.

The results? Sign-ups jumped by 19%. Not after a full redesign. Not after a marketing push. But just from one tiny line.

That, my friends, is the power of microcopy.

A few well-chosen words can smooth the path, ease anxieties, and encourage users to take action. For designers, mastering microcopy is like unlocking a secret language of persuasion, one that quietly transforms hesitant visitors into loyal users.

So, What Exactly Is Microcopy?

In simple terms, microcopy is the text that guides users throughout your product. Think of microcopy as the tiny linguistic signposts and friendly nudges that guide users within your interface. Examples of microcopy include a:

• Call to Action (CTA) on a button: "Add to Cart" vs "Get Yours Now!"

• Hint text in a form field: "e.g., name@example.com"

• Error messages: "Oops! That password isn't quite right. Try again?"

• Success messages: "Woohoo! Your order is confirmed!"

• Tooltips and helper text: "Your CVV is the 3-digit code on the back of your card."

• Loading messages: "Brewing your results..."

• Empty states: "No projects yet. Ready to create your first masterpiece?"

It’s the voice of your product, speaking directly to your user at crucial moments.

Why Designers Should Be Microcopy Maestros

“But I'm a designer, not a writer!” I hear you. And that's fair enough. But microcopy is closely tied to the user experience, so it should be part of a designer's toolkit. Here’s why:

It Sets Expectations & Provides Clarity

Good microcopy tells users what will happen next.

For instance, “Proceed” is vague, while “Pay Securely Now” is crystal clear. This clarity reduces anxiety and builds trust.

It Guides and Reduces Friction

Let’s say Bella is trying to sign up on a new platform and gets an error message. Instead of "Error 404," imagine: "Hmm, that email address is already in our system. Did you mean to log in?"

Suddenly, she now knows exactly what to do because the system has reminded her. Friction gone.

It Humanizes Your Product & Builds Brand Voice

This is where you can inject personality. Is your brand playful? "Got it! We're packing your goodies!" Serious and professional? "Your transaction has been successfully processed."

Microcopy helps establish and reinforce that voice.

It Motivates Action (Hello, Conversions!)

The right words can be incredibly persuasive. For instance, "Start Your Free Trial" is good. "Start Your 14-Day Free Trial – No Credit Card Required!" is even better because it addresses potential objections upfront.

It Can Delight and Surprise

A little charm in unexpected places (like a 404 page or a loading spinner) can turn a moment of potential frustration into a smile. For example, Mailchimp’s "This is your moment of glory" before you send a campaign? Genius.

Why Does Microcopy Matter More Than You Think?

Good microcopy…

• Reduces friction: It clearly instructs users on what to do (and what not to do).

• Builds trust: Clear copy helps users feel safe, informed, and in control.

• Encourages action: A well-crafted CTA (Call to Action) can be the nudge someone needs to take the desired action.

• Reflects your brand personality: Whether you’re fun, formal, or friendly, microcopy sets the tone.

Five Principles for Crafting Microcopy That Converts

Let’s get into the practical stuff. Here are five field-tested principles I live by:

1. Be Clear First, Clever Second

Yes, wordplay is fun. But if users don’t get it, it’s useless. Always prioritize clarity, and avoid using jargon or overly witty phrases that obscure meaning. The user's understanding comes first.

Also, remember that brevity is your friend. Every word should earn its place. If you can say it in three words instead of five, do it.

Finally, context is king. The same button may require different text depending on its location in the user flow. For example, "Sign Up" on a homepage is fine, while "Create My Profile" on the final step of a registration form might be better.

Example:
Instead of: “Oops! Something went sideways.”
Try: “We couldn’t save your changes. Please try again.”

2. Talk Like a Human

I get it, you want to be professional. But you must remember that people want to feel like they’re talking to someone who genuinely understands them. Avoid robotic language and internal jargon. Nobody outside your company knows what "Synergize User Data Stream" means on a button.

Before: “Password does not meet the required criteria.”
After: “Oops! Your password needs at least eight characters, one number, and one capital letter.”

Imagine explaining it to a friend. That’s the tone you should use.

3. Guide, Don’t Scold

Users make mistakes. That’s okay. Your copy shouldn’t make them feel dumb.

Bad: “Invalid email.”
Better: “Hmm, that email doesn’t look right. Mind checking for typos?”

Use microcopy to guide users back on track, rather than chastising them.

4. Write with Purpose

Every word should earn its place. What does the user need to know at this exact moment?

Instead of: “Click here to submit your application for review.”
Use: “Submit Application.”

Shorter. Clearer. More direct.

5. Infuse Personality (In the Right Moments)

There’s a time and place to sprinkle in your brand’s voice. Confirmation pages, 404s, empty states, tooltips, these are great moments for charm.

Example 404:
“We lost the page (and possibly our minds). Try heading home.”

Humor and friendliness create a connection. But when users are frustrated (as during an error), they tend to lean toward helpful and empathetic responses instead.

6. Be Action-Oriented

Start with a verb when possible, especially for CTAs. For example, try phrases like "Download Report," "Explore Features," and "Save Changes."

Also, inform users about what they can do, not about what the system does. "View Your Orders" is better than "Orders Will Be Displayed."

7. Anticipate Needs and Alleviate Fears

If a form asks for a phone number, a little note like "We'll only use this for order updates" can make all the difference.

For a "Delete" button, try adding text like "Are you sure? This action cannot be undone." Crucial.

8. Test, Test, Test (and Iterate!)

Don't just set it and forget it. A/B test different versions of your microcopy, especially for key CTAs or tricky form fields.

Watch user testing sessions. Where do people hesitate? What questions do they ask out loud? Those are your cues for better microcopy.

Sometimes, what you think is clear isn’t. Humility is a virtue here.

Everyday Microcopy Examples That Boost UX

Here are a few everyday examples and how minor tweaks make a significant impact:

✅ Form Labels:
Instead of: “Username”
Use: “Pick a name your friends will recognize.”

✅ Error Messages:
Instead of: “This field is required.”
Use: “Let’s not skip this, your email helps us contact you.”

✅ Onboarding Tips:
Instead of: “Step 1 of 3”
Use: “Almost there! Let’s set up your account in 3 quick steps.”

✅ CTA Buttons:
Instead of: “Submit”
Use: “Send My Application”

Instead of: “Next”
Use: “Continue to Payment”

Wrapping Up

Microcopy isn't an afterthought – it’s an integral part of the design process.

It is everyone’s job. Designers, writers, engineers, and even product managers are all part of the microcopy puzzle.

If you’re designing the experience, you’re also shaping the story. Don’t wait for a copywriter to jump in. Write it yourself. Then test it. Then tweak it. Then test again.

Start treating every word as part of the design. Because when you do, users feel seen, supported, and confident.

And that’s how you build experiences that not only work, but convert.

Well, for years, marketing and user experience (UX) have been treated as separate worlds. Marketing grabs attention and drives sales, while UX makes products easy and enjoyable to use.

It may seem that they speak different languages, but if we dig a little deeper, we may find that they share a common foundation – often telling the same story in different words.

In this article, I’ll walk you through how the classic 4Ps of marketing (Product, Price, Place, and Promotion) intersect with UX to reveal how these disciplines can collaborate to create cohesive and effective product experiences.

The Four P’s: Marketing’s Old Recipe for Success

In 1960, marketing professor E. Jerome McCarthy introduced what he called the “marketing mix,” famously distilled as the Four P’s of marketing. The four elements – Product, Price, Place, Promotion – became the cornerstone of modern marketing strategy.

This simple framework was about orchestrating everything a business offers: making the right product, at the right price, available at the right place, with the right promotion.

For decades, the 4Ps guided how companies aligned their offerings with customer needs and expectations. And even today, the 4Ps remain “a foundational model in marketing,” widely taught and practiced for one reason, which is that it works. Get each “P” right – build a product people want, price it fairly, distribute it conveniently, and communicate its value clearly – and that sets the stage for success.

Marketing hasn’t really changed at its core since McCarthy’s time. Sure, we’ve gone digital and added more Ps (like People, Process, and so on), but the heart of marketing is still understanding customers and delivering value.

What has changed is the context. As the century turned and the internet era took off, consumer behavior shifted dramatically. In this digital transformation, a new discipline rose to prominence alongside marketing: User Experience design, or just UX.

The term “user experience” itself was popularized in the 1990s by cognitive psychologist Don Norman to describe “all aspects of the end-user’s interaction with the company, its services, and its products”.

In essence, UX zooms in on how people feel when using a product or service to achieve their goals. It asks whether the product is usable, useful, and even enjoyable, and whether it meets the user’s needs without hassle.

As Norman and Nielsen famously put it, the first requirement for an exemplary UX is to meet the customer’s exact needs, without fuss or bother. And doing that well is the job of UX designers as much as it is the job of engineers, marketers, graphic designers, and interface designers.

In other words, great UX has always been a team sport, with marketing playing an important position in shaping user expectations.

Fast-forward to today, where marketing and UX are often seen as separate silos – but they’re really two sides of the same coin.

Both exist to create value for people. Both put the user (or customer) at the center of their decisions. Both aim to make a product desirable and worthwhile. The difference is that they just approach it from different directions.

Marketing is about increasing the perceived value of a product through messaging, brand, and offerings, while UX is about decreasing the effort and friction for the user through good design. Put together, those efforts determine whether a product is actually worth it to the people using it.

Two Disciplines, One Goal via Different Paths

If we think of the journey as starting from when a customer first hears about a product to when they become a loyal user, marketing tends to focus on the “before”. Its responsibilities are customer acquisition, attracting the right people, and shaping their expectations.

On the other hand, UX focuses on the “after”. It takes over once the user is in the door, striving for customer satisfaction and retention while ensuring the product delivers on its promise.

• The marketer asks, “How do we get people to notice and try this product?”

• The UX designer asks, “Now that they’re here, how do we make this experience fulfilling so they’ll stay (and come back)?”

These are two halves of a continuous cycle. If marketing sets up a great promise and UX provides a great product experience, you’ve created something powerful: trust and loyalty.

If either side falls short, say, misleading hype from marketing or a clunky product from design, the whole experience breaks down. It’s no surprise, then, that the 4Ps matter just as much to UX as they do to marketing, as the 4Ps define the context in which users experience a product.

Let’s see how each P influences the user experience:

Product: What is being offered?

This is the core of the experience. A product’s features and quality solve a problem for the user (or fail to). In marketing terms, a product is a bundle of benefits and values that fulfill a need. In UX terms, understanding the right product means researching what users truly need and designing the solution around that.

If the product doesn’t fit the user’s needs, no amount of pretty UI or even UX can fix that. McCarthy’s framework itself was about ensuring you have the “right product” to satisfy the target consumer.

Price: How much does it cost, and what is its value?

Price is more than a number on a tag that sets an expectation in the user’s mind for what the product is worth. It also represents what the user is investing (money, but also time and effort). If an app is free but demands tons of personal data or time, that’s a “price” a user pays as well.

UX designers implicitly deal with price when they consider the effort a user must exert. A key principle in UX is minimizing “interaction cost”, which is the mental or physical effort to complete a task. To put it differently, a good UX strives to make the user’s side of the value exchange as smooth and fair as possible. When the price, which could be in dollars or effort, feels too high for the perceived benefit, the experience will suffer.

Place: Where and how does the user access the product?

This is about distribution and context. From a UX perspective, the questions to ask are whether it’s a mobile app used on the go, a website used from a desktop at work, or a physical retail store.

The marketing job is to put the product where its audience can find it. UX’s job is to ensure it works well in that context. A user’s environment (noisy bus vs. quiet office, 5-minute window vs. leisurely hour) can drastically affect their experience.

The best marketing in the world won’t help if the product isn’t available where users need it, and the best-designed interface will frustrate if it doesn’t fit the context of use. “Place” is part of the experience, like a stage on which your UX plays out.

Promotion: What does the user hear about the product, and does the experience live up to that message?

Promotion is how marketing sets expectations through advertising, branding, content, and word-of-mouth. It’s the story of the product. UX, in turn, is about delivering on that story. If the marketing promises one thing and the product delivers another, users feel disappointed or even deceived. Conversely, when promotion and experience align, the product feels trustworthy.

This is the reason why modern UX teams pay attention to onboarding messaging, in-app copy, and other content: they know every touchpoint either reinforces or contradicts what the user has been told. A good promotion can draw a user in, but only a matching UX will keep them in.

As the Nielsen Norman Group notes, both marketing and UX ultimately “aim to make a product or service desirable” by increasing its perceived utility and value. Promotion creates the desire, and UX fulfills it.

Understanding these overlaps helps explain how most UX problems aren’t just UI problems or usability problems. Often, when a product fails for users, the culprit is a disconnect in one of the above areas.

Maybe the product didn’t actually solve the problem the user thought it would, which could be a product/expectation issue. Maybe the user felt the outcome wasn’t worth what they had to put in, which is a Price/value issue, with too much effort for too little reward. Perhaps they never fully understood the product’s value or got lost finding it, which is a Place/distribution issue. Or, they might have felt a little too let down because the hype didn’t match reality, which is a Promotion/trust issue.

Many of these so-called “UX issues” boil down to expectation, value, and trust, the same concerns at the heart of marketing. But these are often completely ignored by UXers because they are deemed “out of scope”. And it is no coincidence that an actual seamless user experience tends to foster brand trust and loyalty.

So, when UX and marketing are in sync, the product feels right to the user on top of it working well. It meets the expectations set, provides real value, and earns the user’s confidence.

Big picture: UX happens within a value exchange between a user and a product, and the 4Ps define many of the terms of that exchange. If a UX designer ignores things like pricing strategy or how the product is marketed, they might be missing half the story of the user’s experience.

A Shared Foundation between UX and the 4Ps and Why It Matters Today

There’s often a quiet tension in organizations between the UX team and the marketing team. Marketers might joke that designers only care about “pretty screens,” and UX designers might grumble that marketers would sell anything with a flashy ad.

But at the end of the day, both teams are trying to solve the same problem. Both try to connect people with a product in a meaningful way, using their own processes and coming at it from different angles.

If users are churning or a product flops, it doesn’t really matter whether we call it a marketing failure or a UX failure – it’s usually a bit of both. This realization is exactly why the common ground between UX and marketing is so important in today’s digital product landscape.

Thinking with a marketing mindset, in fact, can make UX design stronger and more holistic. The classic marketing questions – Who is the customer? What do they need? What will they pay or sacrifice? How do they discover us? – are strategic questions that UX designers should ask as well. They force us to zoom out from the interface and consider the entire user journey.

The 4Ps framework is about interplay, as it is about tactics in isolation to ensure we’re aligning everything from the thing being sold to how people find it, what it costs, and where they get it. It asks whether we are even solving the right problem, in the right way, for the right people. And that should be a UX concern as much as a marketing concern, as that is the central question of making any product successful.

So why does this shared space between these two domains matter so much today? It’s because designing a great product is no longer confined to just the product’s interface or just the advertising around it, but with a cohesive experience from first impression to last use.

The lines between discovery, purchase, use, and re-use have blurred. A user can see an Instagram ad (promotion), click straight into an app store (place), download and try an app (product), and decide within minutes if it’s worth paying for full features (price). If any part of that chain breaks, say the ad misleads, or the app is confusing, or the value for cost isn’t there, the user is gone.

This means that teams need a common lens. The 4Ps offer exactly such a lens, bridging strategy and design. And maybe other marketing frameworks do, too. But the most important thing to remember is that marketing and UX are really playing in the same field of contributing to the total experience a customer has.

How to Mindfully Collaborate Between UX and Marketing Teams

Getting UX and marketing to work together can be messy in practice, as we’re merging different domains – and of course we may not get it right at first. The important thing is to be mindful of potential friction points as well as opportunities for collaboration.

It’s similar to running a new campaign. The first few attempts rarely deliver results, and throwing hands up after initial failures is common, but shortsighted. Teams could instead try openly sharing failures and frustrations, which is a rare thing to do, but that is how we can find things we usually don’t.

We should let marketing look into UX’s messy usability tests, let UX dig through marketing’s failed campaigns, and ask each other simple, tough questions. Questions like, ‘What would marketing do here? How might UX solve this problem?’ It can feel awkward, even frustrating, but doing this can uncover critical insights neither team could find alone.

Realistically, meaningful collaboration won’t happen by itself and thus might mean trying joint workshops once in a while – not every week, maybe just every few months – purely to understand each other's perspective. Marketers could step into the shoes of UX designers, and UX teams could tackle marketing challenges, engaging in a role-swapping session to build empathy.

We have to acknowledge from the get-go that these sessions could get uncomfortable, but that’s exactly the point. Solving big problems means dealing with uncertainty, making mistakes, and iterating patiently until we see what works.

Engaging in activities like working in the same sandbox, swapping insights and failures, role-playing each other’s perspective, asking “each other’s” questions as well as “each other” questions could help embrace frustration.

All in all, it’ll involve leaning into each other’s domains, understanding that persistence through repeated attempts is exactly how UX and marketing teams’ amalgamation might help solve great, challenging problems.

Final Thoughts

UX and marketing have always been two voices telling the same story. But for too long, we’ve drawn an imaginary line between them when in truth, they’re team members on a shared mission.

A UX designer talks about empathy and ease. A marketer talks about value and desire. Different words, but same goal to resonate with a human need.

The classic 4Ps of marketing should be taken as a mirror for UX that reflects a more holistic way to design. This definitely isn’t about doing marketing’s job and vice versa, but rather doing our job with a wider lens and striving to realize that what we thought was “their” language was always part of our own.

Now, this article aims to help you go back to the basics and remind you of the meaning and importance of IA. So if you don't really understand the concept of Information Architecture, this is the best place to be.

We'll also explore how to do a userflow and a sitemap later in the article. Let's get started!

What is Information Architecture?

Information Architecture (IA) is the process of planning and designing how information is organized in websites and applications. It focuses on meeting user needs and business goals by creating a logical and user-friendly information structure.

Information Architecture is mostly used by designers to structure the layout of their designs, especially during the sketching/low-fidelity stage.

Importance of Information Architecture

I can't overstate the importance of Information Architecture. Below, I'll share some reasons why every UX Designer should learn what IA means and how to implement it effectively:

• Organization and Structure: Information Architecture provides a framework for organizing and structuring information. It helps you make sure your designs are logically grouped and categorized.
• Content Prioritization and Hierarchy: Hierarchy is one of the basic principles of design, and IA helps you achieve that. It enables designers to highlight key information and arrange content based on its relevance and importance to users.
• User-Centric Design: Information Architecture helps designers think of their users during the design process, by considering how users typically think, behave, and search for information. Everyone has mental models, including users, and IA helps to make sure that information is presented in a way that matches the mental models of your already existing/target users.
• Navigation: Information Architecture provides a clear way to navigate a design. It allows users to understand intuitively where they are in a site and how to move between different sections of a design.
• Business Goals: Information Architecture helps to make sure the information presentation of your design aligns with the goals and objectives of the business/firm/company.

Types and Forms of Information Architecture

There are so many types and forms of Information Architecture, especially since it's used in a lot of fields. But here we'll be looking at Userflows and Sitemaps, which are the most common ones in design.

What is a Userflow?

A userflow refers to a diagram that shows the step-by-step journey of a user through a website, application, or system.

Imagine trying to order food online. Some steps you might take include: opening the food ordering application on your phone, signing up/logging in, choosing from the list of available food, choosing how many portions you'd like, and finally making payment online.

That's a typical example of how a user flow might be structured.

Userflows illustrate the paths, interactions, and decision points users encounter as they navigate and complete specific tasks or goals. They help designers and stakeholders understand and optimize the user journey.

An example of a Userflow

What is a Sitemap?

Sitemaps are diagrams that display the layout and organization of content within a website or application.

Imagine a 2 bedroom apartment. The apartment could contain a sitting room, a kitchen, 2 bedrooms, a bathroom, and a dining room. The sitemap simply tells us how we can get to the kitchen from the sitting room/the bedroom/any place in the apartment.

In design, sitemaps provide an overview of the pages, menus, and sub-pages, helping us plan and visualize the information architecture and user experience of the system. They aid in content planning, navigation design, and website development.

An example of a Sitemap

Differences Between Userflows and Sitemaps

1. Focus and Perspective: Userflows primarily focus on the step-by-step actions and interactions a user takes within an app or website, to accomplish a task or goal. Sitemaps focus on the overall structure and organisation of a website or an application, depicting the hierarchical relationship between different pages or sections.
2. Level of Detail: Userflows provide more detailed information about each step of the user's journey, including specific actions, decisions, and possible outcomes at each stage. Sitemaps provide a high-level overview of the app's or website's structure, showing the main pages or sections, without diving into the specific interactions within each page.
3. User-Centric vs Architectural: Userflows are user-centric and primarily represents the user's perspective and actions within the app or website. Sitemaps are more architectural in nature, representing the overall structure and organisation of an app or a website from a high-level viewpoint.
4. Interactivity and Decision-points: Userflows highlight interactive elements within the app or website, illustrating the choices and options available to the user at each step. Sitemaps do not explicitly showcase interactivity or decision points.

When to Use Information Architecture

You might be wondering when knowledge about Information Architecture will come in handy.

You can use Information Architecture in any or situation at all, really – like designing a mobile app, a website, a pitch deck, and more. Information Architecture is always helpful because it helps you decide what content/information comes first, what follows and how, and so on.

Typically, you'll think about Information Architecture after conducting user research. This is because research can help you understand the goals and needs of your users, and what they would likely do when they're trying to accomplish a goal on your site.

Also, userflows usually come before sitemaps, because you have to understand how a typical user would journey through your site, before deciding on how the layout or organization of that site would look like.

How to Create Userflows and Sitemaps

You can use the same methods and tools to create userflows and sitemaps. You just need to understand the differences between them and bear in mind that the purpose of each one is different.

How to Create a Userflow

Step 1: Define your Goals and Identify Tasks

The first step is to define your goals and objectives for the project, stating what kind of Information Architecture you're trying to create (a userflow or a sitemap). You can just write this down on paper before digitalizing it.

For example: I'm working on a food ordering app, and I'd like to make a userflow showing how a typical user would order food using the app.

I would write down the typical/possible steps the user would have to go through to achieve the task of ordering food. These steps could be:

• The user opens the application on their phone.
• The user signs up or logs into the application.
• The user goes to the homepage.
• The user chooses from restaurants close to them.
• The user selects from the menu and adds food to cart.
• The user pays for the food and waits for delivery.
• The user exits the application.

Step 2: Choose a Tool

The next step is to choose a tool you want to use to create your userflow. There are lots of tools available for this, like Figjam, Miro, Whimsical, and others. I use Figjam since it's so easy to understand.

Here's what it looks like:

Figjam interface

Step 3: Sketch your design

The next thing is for you to sketch your actual flow on Figjam. Before this, you should note that every shape for a userflow has a specified meaning. You can see some shapes, flows and associations, and their meanings below.

Shapes, flows, and associations for a userflow.

The First Shape (Rounded edge rectangle): This shape represents the start/end of a userflow. It's typically used when you want to start or end a userflow. If you notice, there's also an end tag with a similar shape in the image above. Some people also use a circle to represent this.

The Second Shape (Rhombus): This shape represents a decision. It's used to show when a user has to make a decision like "login", "signup", and so on.

The Third Shape (Rectangle with dotted lines): This represents a group. A group in a userflow can contain process and data, showing that an action has been submitted to the database, and it's expecting feedback from the site.

The Fourth Shape (Parallelogram): This shape shows when the user has to make an input, like "choose how many portions of food they want to order, and so on.

The Fifth Shape (Rectangle with solid lines): This shape shows the process of the user going through the application or website. It might also include screens the user needs to pass through in order to achieve their goal.

The Sixth Shape (Cylinder): this shape represents the data running in the system, which feedback is required from.

Now that you know the different shapes and their uses, you'll need to first draw the shape for 'start':

Choosing a Shape

Next, you'll want to resize the shape if necessary, and input your text.

Resizing shape and adding text

Up next, you'll need to add another shape and draw a connector. To add a connector, you can either click on the edge of the previous shape and drag, or draw the connector directly from the Figjam tools.

Drawing a connector to the next shape.

Drawing a Connector from Figjam tools

When you do that, you then input your text. (Remember to take note of the meanings/roles of each particular shape).

You continue this way until you're done adding all the steps in your userflow diagram.

Example userflow diagram with multiple steps

Step 4: Validate and finalize

Once you're done with your userflow, the next thing is to validate the diagram. This just means reviewing the userflow to make sure it's accurate, usable, and aligns with the users' needs.

Basically just go through the diagram and consider whether it represents the intended user journey, and whether all necessary steps and decision points are included.

How to Create a Sitemap

Earlier in the article, I mentioned that the processes for creating a sitemap and a userflow are similar. The difference lies in the purpose of the two diagrams. We'll be exploring how to create a sitemap using Miro, a diagramming tool.

Step 1: Open the tool

The first step obviously, is to open your tool. If you don't have an account already, sign up at Miro and it should display your dashboard.

Miro Dashboard

Next, click on "New Board" to open a blank canvas.

Step 2: Start drawing the sitemap

Next, you start drawing your sitemap. You should already know what screens you'll be designing, and how these screens connect to each other. Your userflow might help inform this.

Click on the Shapes tool from the toolbar on the lefthand side of your screen, to bring up all available shapes.

Note that, unlike Userflows where every shape has a meaning, you can use any shape for your sitemaps. Most designers make use of rectangles when doing sitemaps. It's very easy to build and stack, especially when you have lots of pages to represent.

Choosing a shape

A plus icon will appear, and you just have to drag till the shape is to your satisfaction.

Step 3: edit the shapes

Next, you edit the shape to add colour, and your text. This could be "Homepage", "Log-in", "Signup", and so on – whatever is the first screen of your design.

When you click on the button, a sub-menu comes up. Here, you can switch your shape type, change text font and size, add text colour, align it, add a border or fill colour for the shape, and more.

Typing inside a shape

Editing a shape

Step 4: add shapes for the next screens

Next, you need to draw shapes for the next screens which the homepage branches into. This could be major items on the navigation bar, where you have to click on CTAs (Call To Actions) to open them.

To draw the next shape, you can simply click on the edges of the first one, and the outline of the shape will be displayed.

Sketching the next shape

Click on the outline to indicate that you want the shape to stay, and basically edit just like you did the first one.

Editing the second shape

Next, you need to add other shapes that represent the subpages which the homepage branches out into. Just click on the first shape like you did when making the first sub-page shape.

Adding other sub-pages

You can also change their colours to differentiate from the homepage and show hierarchy.

Step 5: draw more pages

Next, you draw shapes for the pages under the first set of sub-pages.

You just continue that way until you're done with your sitemap, and all the screens you want to design have been represented in it.

When you're done making your userflow and sitemaps, you can move on to your low-fidelity wireframes or your main design proper. The IA you've done informs your next step and decides what screens you should be designing in particular.

Conclusion

Information Architecture is very important for you to be able to organize the layouts of your designs and arrange them. This is helpful because it can really help improve the quality of your designs.

There are even templates on some softwares that could help you do your Information Architecture diagrams. Remember to practice as often as you can.

Thank you for reading!

This is where data visualization comes in. Data visualization is a very important concept we should all consider when designing for our users.

In this article, you'll learn what data visualization is, how it relates to UX Design, and challenges faced when designing for data visualization.

What is Data Visualization?

Data Visualization can be defined as being able to view data in designs. This could be done using charts, maps, tables, and so on. Data visualization simply enables users to see and understand data, without stressing their head or eyes.

By leveraging the power of visual perception, data visualization empowers individuals and organizations to gain deeper insights, and make informed decisions.

How Does Data Visualization Relate to UX Design?

You might be wondering if and how data visualization relates to UX design. After all, isn't data all about numbers?

They do relate! You see, data visualization isn't just about numbers. It's about representing these numbers in a way that makes sense to the user, and also helps them make decisions.

As UX designers, our primary goal is to solve a problem for our users. When we design for data visualization, we're reducing the strain of going through bulky amounts of data for our users, and generally making their lives easier.

Why is Data Visualization important?

Data Visualization is important for so many reasons, some of which are:

• Enhancement of understanding: Just putting out data might confuse a particular user or customer. Using visuals to interpret the data makes it easier and more fun for the users.
• Communication of insight: Data visualization helps communicate insights on a digital platform. Users will be able to understand the data, data sources and how it's being analyzed.
• Better user experience: Overall, data visualization helps in making sure your user has a better experience while interacting with your platform. You're generally trying to make their lives easier and reduce information overload.
• Informed decision-making: Helping the user understand the data better, will keep them informed, and help them make better decisions which can boost their businesses.

Challenges of Designing for Data Visualization

Data visualization is so easy to get wrong. Because of the delicate nature of data and how broad it can appear, designers might face some challenges when trying to help users visualize data. Some of these challenges include:

• Bulky/complex data: The bulky nature of the data might make it difficult to represent the data using visuals. Also, simplifying the data without losing information can be very tricky.
• Cluttered interface: Somewhat related to the previous point, the overwhelming nature of the data can make the design look cluttered. Because you're designing with a lot of data, you might end up having a messy interface, while trying to put it all on a screen. You have to find a way to make sure your user interfaces don't look cluttered with an overload of information.
• Usage of color: Despite the fact that we want the interface to look visually appealing, we have to consider the fact that colors can distract users from the overall intention, which is to communicate data to the users. Therefore, we should figure out a way to strike the balance, especially when differentiating color categories and highlighting important information.
• Background of the target audience: You should also consider the background and understanding of your target audience. Some users might not have technical knowledge so, it would be best not to use jargon while designing for them.

How to Design Efficiently for Data Visualization

To effectively design for data visualization and correctly interpret data for your users, you should consider these tips:

Define the purpose

First of all, you'll want to define your purpose for the design. This is a common step in most designs. You need to understand the purpose of the visualization – is it to convey trends, monitor business growth, and so on.

Also, consider the domain, requirements, and possible constraints. This will help you determine the best visualization type to use.

For example, say you're designing a data visualization for a social media tracking platform. The purpose here is to track the growth of the social media account, note what posts are most engaged with, and basically providing actionable insights to help the user make decisions that would further boost the account.

Know your audience

Another tip for designing effectively is to know your audience. You have to understand what your audience needs before figuring out how to help them.

You can conduct some research on the kind of people that would use the data visualization tool for the domain you're working on.

Using the same example as the first tip, your audience would generally be social media managers, brand ambassadors, or others who work primarily in the social media space. Do note that the audience may vary in terms of age, expertise, and personal preferences.

Choose the visualization type

Here, you choose the best visualization type for conveying your information. You can decide to use bar charts, tables, graphs, and so on, to represent your data.

Continuing with our example, you'd want to select visualizations that effectively represent progress over time, such as bar charts, progress charts, and so on. You might also want to analyze key data such as active followers. Would you use a bar chart or a line chart to do so? This is what choosing the visualization type entails.

Examples of some data visualization charts. Image from [OpenClassrooms](https://www.google.com/url?sa=i&url=https%3A%2F%2Fopenclassrooms.com%2Fen%2Fcourses%2F4555961-apply-metrics-to-design-decisions%2F5403056-decide-on-an-approach-to-present-information&psig=AOvVaw11EJaN3uJ8zzLGJ7VRciQd&ust=1685717146266000&source=images&cd=vfe&ved=0CBEQjRxqFwoTCKjA--nov8CFQAAAAAdAAAAABAR)_

Have an intuitive and simple layout

Here, you'd have to think of the kind of layout you want to use for your design. You would want to go for a simple layout that would help your users easily understand the visuals.

For the social media data visualization, you might want to:

• Incorporate a clear hierarchy of elements using size, colors, and placement.
• Use familiar patterns like icons or symbols, to represent different social media metrics.
• Embrace a minimalist approach by displaying essential information only.
• Design a clear navigation system so users would always understand their current location on the application.

Having an intuitive layout can help reduce information overload on your users. When elements are arranged logically, and the visualization is simple and free of clutter, your users are sure to have a great experience.

Use accessible colors

Next, choose colors that are easy on the eyes. Aside from the background and primary colors, you might use color coding to differentiate between different metrics/elements.

For example, you may decide to get the gender demography of the audience for the social media account. To represent this data, you could use a circle graph (doughnut), and choose different colors to represent the genders.

An example of a circle graph with each element differentiated by colors.

Please note that accessibility isn't only for people with disabilities. Make sure to use colors that don't distract the user from important elements and information. You can use the 60-30-10 rule to choose a color palette that improves understanding and aids interpretation.

A Data Visualization Dashboard

Example of a dashboard for a Data Visualization Tool

The image above shows a dashboard for a social media data visualization tool. The dashboard contains performance metrics, analytics of likes, followers and comments on the account. The dashboard also contains the demographics of the audience, engagement rates and posts activity.

All these are important data analytics information which are useful to the owner of the account.

You can see how charts and bar graphs are used to interpret the data. Imagine having one big list which has the demographics of each user, each like and comment posted, everyone who engaged with each posts, and so on. It would be a bit overwhelming and hard to sift through to find insights.

Conclusion

The average person consumes about 40-75 gigabytes of data per day. Now, that's quite a lot. Imagine having to take in this huge amount of data through cluttered and disorganized interfaces. This would make it difficult to understand and interpret the data.

As designers, it's our job to ease the experiences of users while interacting with our products. We have to focus and align our design choices with the purpose and audience, as well as continuously evaluate our visualizations to ensure they effectively convey insights and appropriately inform the viewers. Remember, this gets better with practice.

Thank you for reading!

UX and UI design are two technical terms that can often be confusing.

Many people may use these two terms interchangeably, incorrectly, or assume they are the same thing. But that is not the case, as they are two different fields.

In a nutshell, UX design focuses on how well the product works and how the user feels when using it, whereas UI design focuses on how that software product looks.

Both are equally important and play a vital role when creating and developing software.

Think of it like this: a pretty UI may attract visitors, but if the product is not functional, the visitors won't stick around. And if the product works properly but doesn't look good, users will feel frustrated and look elsewhere to satisfy their needs.

There needs to be a balance.

With that said, the definition above only scratches the surface.

In this article, you will learn about the differences between UX and UI design and understand what UX and UI designers do in their day-to-day work.

Here is what we will cover:

1. What is UX design and why is it important?
2. What does a UX designer actually do? The UX design process explained
   1. Understanding phase
   2. User research phase
   3. Analyze and define phase
   4. Ideate and design phase
   5. Reporting phase
3. What is UI design?
   1. What does a UI designer do?
4. UX VS UI design - what's the difference?

What Is UX Design and Why Is It Important?

UX design is short for user experience design.

The term was coined and popularized in the early 1990s by Donald Norman, an American researcher, professor, and author, during his time at Apple.

According to Norman:

User experience encompasses all aspects of the end-user’s interaction with the company, its services, and its products.

Note that the original definition of UX referred to physical and digital products. Nowadays, UX design mainly relates to digital products.

So, user experience design is a process that involves cultivating a good relationship between a company, the company's software products /services, and the company's clients/customers.

The relationship is based on how a user feels when using the company's products.

UX has to do with feelings, emotions, thoughts, behaviors, and human psychology.

Specifically, good UX depends on the following points:

• How does a person feel when using the product?
• How accessible is it for the person to navigate the product? Can everyone use it?
• How usable is the product? Does it work as intended?
• How easy is it for the person to navigate and find the necessary information?
• How well-planned and intuitive are the steps a user needs to take to accomplish a task?
• How logical is the sequence of actions a user needs to perform to accomplish their goal with ease?
• Does it make it easy for them to achieve their initial goal?
• How well structured is the content available? Does it follow a logical hierarchy?
• How useful is the product?
• How valuable is the product?
• Does it serve a purpose?

All of the above are part of what makes good UX design and contribute to the value the software offers.

UX is all about solving problems and always keeping the user in mind.

The end goal is to provide a pleasant and positive experience for the user, create digital products that a user feels comfortable using, and for the user to accomplish their task and have their needs met.

All in all, it focuses on anything and everything that affects the user's journey when trying to solve a problem they have.

Good user experience is vital for every business. If the user/customer is happy and not frustrated, they are more likely to remain loyal.

If users can't use the product with ease, this will result in them giving up on it and looking for an alternative product/service that meets their needs, resulting in a loss for the business. They are unlikely to return to a product after a bad experience.

What Does A UX Designer Actually Do? The UX Design Process Explained

The UX design process is comprised of many parts. It is a sequential process with the end user always in mind throughout all stages.

The role of a UX designer will vary from business to business and depends on the size of the team they are on.

On a small team, a UX designer will probably be responsible for the whole UX process from start to finish. On a larger team, they might be involved in only one part of the process, such as UX research.

That means a UX designer may not be part of all the stages outlined in the following sections.

Now, let's see the different phases in the UX design process in more detail.

Understanding Phase

The first step in the UX design process is understanding the brand and its users.

Specifically, it is about understanding how the project the UX designer is working on aligns with the brand's mission, vision, and goals.

And it is about understanding the brand's users/customers.

A UX designer can't make assumptions about what the users really want or what problems they are facing when using the product/service. They will only know once they ask the users directly.

The UX designer needs to understand, be in tune with, and empathize with the problems users are facing and their pain points. They need to understand their users' wants and needs.

The key word here is empathy! Empathy is the ability to understand the user's hopes, goals, frustrations, and needs.

Once the UX designer has gathered those insights and identified the goals of the brand and the problems the users are facing, they can figure out how to solve problems and provide solutions through their designs and how they can create products/services that solve those problems.

User Research Phase

As mentioned in the section above, a UX designer can't assume, and if they do, they need to question those assumptions by conducting user research.

There are two main methods for conducting user research:

• Qualitative methods
• Quantitative methods

Qualitative research methods focus on observational and non-numerical findings, human behaviors, opinions, and emotions.

They include creating customer feedback surveys and asking open-ended questions to understand the key frustrations and pain points and what needs improving.

They also include reaching out to customers directly and conducting 1:1 face-to-face or online user interviews or focus groups of 3-5 target users for usability testing.

Quantitative methods focus on numbers, metrics, and measurable data points.

They include using web analytics tools and researching how the current design is performing. For example, they might find out how many visitors of an e-commerce site are clicking on a particular item and adding it to their cart, or what is the average time spent on the checkout page.

To learn more about user research, check out the following resources:

• Why you need a UX researcher on your product team
• Use User Research to Create the Perfect UI Design
• Qualitative VS Quantitative Definition – Research Methods and Data

Analyze and Define Phase

After gathering user insights, the next phase in the UX design process is for the UX designer to analyze and make sense of all the information and define the problem they need to solve for the user.

They define what their focus should be and what would have the most impact on the users.

At this stage, it is crucial not to lose sight of the user's needs.

For this reason, the UX designer will create user personas based on the research they've gathered.

A user persona is a fictional character that will use the product/service.

It represents a typical target user and identifies their needs, frustrations, behaviors, and goals.

User personas allow UX designers to understand their users better and make wise design decisions.

At this stage, a UX designer might also create use cases.

A use case is a description of how different users might use and interact with the product or service.

Finally, a UX designer might also create journey maps.

A journey map is a visual and graphic representation of how the user will interact with the product/service from start to finish, and a map depicting the whole user journey until the user accomplishes their goal.

Journey maps are useful for understanding the different pain points a user faces when using the product and where those pain points occur, which leads to restructuring the product/service.

To learn more about user personas and use cases, check out the following resources:

• How To Write User Stories, Epics, & Personas
• Use cases and organizational structure

Ideate and Design Phase

The ideate phase is all about brainstorming and exploring out-of-the-box design ideas.

At this stage, the UX designer will come up with different creative options for how to solve the problem at hand.

They will brainstorm ideas and sketch them on paper before using any digital tools.

They will also create wireframes. Wireframes are rough prototypes and visual representations of what the UI and its various components will look like and which act as a guide and direction for the final design.

They will outline the steps and the complete path a user will take while using the product/service.

The end goal of this phase of the UX design process is to design low or high-fidelity versions of the structure and layout of the product (which may or may not be interactive) and of what the final design will look like. The first design is never the final design.

After continuously iterating the designs, adding new ideas and features, rigorous testing, and feedback, the UX designer will have a detailed and carefully crafted digital mockup.

The mockup will look almost identical to the final product, which they hand off to the engineering team. The engineering team will build and ship the real-world working product.

To learn more about creating wireframes, check out the following resources:

• What is a Wireframe? This UX Design Tutorial Will Show You.
• How to Design a Website Prototype from a Wireframe

Reporting Phase

After the product launches, the next phase of the UX design process is the reporting phase. This includes conducting usability testing, observing how users are using the end product, collecting feedback, and gaining additional insights.

This phase helps the UX designer and their teams understand if the end product solves the initial problem and if it meets the needs of their end users.

At this phase, here are some of the questions that a UX designer may ask:

• "What did we do right?"
• "What didn't we do right, and why?"
• "What did we learn?"
• "How can we improve in the future?"
• "How are users responding to the product/service? Did we solve their problems and pain points?"

With that said, the UX design process doesn't end here, since there are continuous iterations and improvements to be made.

What Is UI Design and Why It's Important? An Overview of UI Design

So far, you have seen that UX design involves every aspect of a user’s experience when using a product. So what exactly is UI design, then?

Back in the 1970s, to use a computer, you had to use a command line interface (or CLI for short), and users needed to know a programming language to communicate with the machine.

At that time, you needed a lot of technical knowledge and skills to complete a simple task with a computer.

That changed in the 1980s with the introduction of Graphical User Interfaces (or GUIs for short) and personal computers.

A mouse, application icons, buttons, menus, checkboxes, and folders replaced the cryptic command line. Anyone could use a computer. Users could easily create, update, move, and delete files and send emails – no coding required.

The people that created these early graphical user interfaces were called User Interface (or UI for short) designers.

Nowadays, the term user interface involves every visual part of a digital product/service that a user interacts with. This includes mobile apps, websites, screens, touchscreens, keyboards, and wearable technology such as smartwatches, to name a few.

You can think of it as the bridge between the user and technology.

A UI designer is responsible for designing every step that allows a user to interact with the digital product/service. This includes layouts, structure, buttons, colors, and animations.

UI design is all about the look, feel, and aesthetics of a digital product. It involves every visual aspect and appearance of the product the user interacts with.

The end goal of a UI designer is to make something visually appealing to the user that's easy to interact with.

Good UI is vital for drawing attention to potential customers and attracting new users. Everyone appreciates a well-designed, clean, intuitive, and modern design.

But how does all this relate to UX design? You can think of UI design as a subset of UX design and a small part of the UX design process. But it is a separate discipline in its own right.

What Does A UI Designer Do? UI Design Skills Definition and Examples

UI designers need to have visual design skills.

Specifically, they need to know the following concepts and disciplines:

• Color theory, creating color palettes and creating accessible contrast that ensures both usability and readability.
• Typography.
• Layout, spacing, structure, and effective placement of elements on a page.
• Graphics, icons, and illustration design.
• Interaction design principles, animation effects, and motion design.
• Branding – creating a consistent visual identity for a brand/product and communicating the brand's mission and message.
• Responsive design, and ensuring the UI looks good on all screen sizes and devices.
• Creating style guides.
• Creating design systems.
• Knowledge of industry tools such as Figma
• Wireframing and prototyping.

UX VS UI Design – What's the Difference? The Difference Between UX and UI Design Explained in Plain English

By this point, you hopefully understand what UX and UI design involves.

To summarize their differences:

UX design is how things work and how useful they are. UX design focuses on the whole experience and the journey a user takes when using a product from start to finish. It involves the overall experience a user has when trying to solve a problem.

UX requires knowledge of psychology, cognitive science, human behavior, identifying the user's pain points, and solving their problems.

UI design is how things look. UI design is a subset of UX design and is a more specialized field. It focuses only on the visual aspects that a user interacts with and creates inclusive, accessible, pleasant, and aesthetically pleasing digital interfaces.

UI design also focuses on creating a brand aesthetic that leads to an emotional connection with users/customers.

Both UX and UI design are equally important in creating useful, usable, and modern digital products and services and meeting the needs of their users.

Conclusion

This marks the end of the article – thank you so much for making it to the end!

Hopefully, this guide was helpful, and it gave you some insight into what UX and UI design are, what UX and UI designers do in their day-to-day work, and what the differences between those two terms are.

Thank you for reading!

Back in the day, web developers, front-end engineers, and UI designers had a bit of an easier job. This is because they weren't expected to rearrange their code and designs to fit so many different screen sizes.

But in today's world, if you make a decision that doesn't take responsive design techniques into consideration it can be doomed to failure.

After all, no one wants to visit a web site to stare at weird shapes, distorted images, and illegible text.

People's time is precious and limited, particularly in today's fast-paced world. A poor user experience in the form of non-responsive web design can really harm a business or brand in the blink of an eye.

This is why every developer should treat their products and websites like gemstones in their portfolio. These are literally a part of your personal brand and you don't want to ruin it with bad designs.

Illustration by Forty One

If you want to guarantee a hassle-free user experience, as a web developer or designer you're supposed to adopt certain practices that require you to play around with the layout. In this way, every single page you compose looks sophisticated and is user-friendly regardless of the screen size.

This process of creating responsive designs is deeply connected to content architecture.

There are various techniques you can use to make your website's potential users smile – or at least not feel frustrated – when they look at their screens.

Those may involve using media queries, CSS Flexbox, or CSS Grid. That being said, this article will primarily consider a method that is popular among experienced web developers.

Why Should You Adjust the Root Font Size?

In a nutshell, this technique targets the root font-size and it also has to do with why you choose 'rem' units with this set-up. If you're already curious about it, let's dive right into it.

First and foremost, you should know that the standard root font-size of browsers is 16px. This fixed value is in 'px' units by default. But 'rem' units compared to 'px' are capable of creating more responsive websites. You can read more about that in this article.

So if we try to convert px values into rem, we'll need to do some math. Suppose we want to set the font-size of an element to 4px, but we also want it to be as responsive as possible. To turn it into a 'rem' value, we need to divide it into 16px and the result will be 0.25rem. An online converter exists for this purpose as well.

Everything would be fine and dandy if we had a way to turn every 'px' value into a 'rem' figure more easily, now that rem is considered to be more responsive. Here is how our dreams can come true.

In lieu of dealing with such cumbersome calculations, we can set the root (HTML) font-size to 62.5%. In this case, you can make all the other calculations automatically through the system.

How to Change Root Font Size

Let's delve into the details to better grasp the situation. When the root font/HTML size is 100%, the font-size is 16px by default. But, if you set it to 62.5%, the new root value will be 10px.

Now, 10px (1rem) is way too tiny and is a recipe for disaster in terms of good user experience. So we should set it to 1.6rem (16x) again in the body. Everything looks the same on the surface. But still, this time, the new rem set-up will be more responsive than that of the 'px' version.

Now we're able to translate all the values into rem units. The tricky bit here is the root size calculation in the HTML section. Now, whatever size we pick for the body will be re-shaped in accordance with the pre-defined value in the root/HTML. To put it simply, the new percentage value '62.5%' in the root/html section ensures the smooth transformation of 'px' into 'rem'.

Why We Prefer the 'Percentage' Expression

At this point, you might be asking yourself why we opt for the percentage expression (62.5%) along with 'rem' units. Why bother? Isn't the 'px' version supposed to be the same? Well, not so much.

As some developers on Quora suggest, percentage-based values can scale more smoothly compared to fixed numbers. This means that not only are rem units important, but also the percentage preference in the root/HTML part matters a lot in this particular set-up.

The most effective part regarding the figure '62.5%' in the root is that even if the visitor alters the font size of the browser, they'll be able to view the page properly thanks to the related CSS set-up.

Also, it poses no threats in terms of accessibility because we also set the font-size of the body as 1.6rem in addition to the 62.5% arrangement in the root/HTML section. This way, we ensure that those two numbers go hand in hand no matter what the screen size is.

Why Accessibility is Important

It's important to elaborate on the accessibility issue. I believe it should be of the utmost importance to web developers and designers from all walks of life.

Research shows that the number of visually impaired individuals is gradually on the rise, and there are many reasons for this. But one thing is for sure: in an era of cutting-edge technological advancements, everyone should be able to enjoy the internet and access information through certain accessibility measures. And applying proper responsive design techniques is definitely one of those.

What is Bruce Lawson's Significant Message?

I remember watching an excellent talk by Bruce Lawson, an expert when it comes to web standards. During a virtual free bootcamp organised by Class Central and freeCodeCamp last year, he was a guest speaker. He explained very clearly why we as web developers are responsible for keeping everyone included and making sure that no one else is left out when coding and/or designing a website.

Shall We Test Our New Set-up?

Let's be more specific and come up with an imaginary scenario. Suppose a visually-impaired user wants to visit the webpage you've designed. To be able to see everything more clearly, they decide to make some adjustments t0 the browser's font-size in advance. For example they might set it to 18px, a bit bigger than the standard size (16px).

It is now time to examine the following code snippet closely to witness the functionality of the HTML and body-oriented set-up from the perspective of this individual.

html {
    font-size: 62.5%;
}
body {
    font-size: 1.6rem;
}

As the developer of this webpage, you chose '62.5%' for the HTML and '1.6rem' for the body as the initial font size. But remember that the browser's font-size determined by the above user is now 18px, not 16px anymore. How is it going to work out? Will this person be upset and leave the page feeling frustrated or will they keep surfing the webpage without trouble?

Here's the answer. Once the browser's font-size is chosen as 18px by the user, the font-size will instantly be re-calculated as 11.25px (18px 62.5%) by the system. As a result, the value for the body will be 18px (1.6rem 11.25px) just the way it is requested by that specific user. So this person will not be negatively affected by the situation just because they wish to see the font-size bigger than the standard version.

The good news is that all of these will be re-calculated automatically. And thanks to the percentage and rem-oriented set-up, the text on the webpage will be more responsive and user-friendly.

More Experiments

To further see the possible effects of this setup, let's now take a look at how the font-sizes of the following elements/main containers will work out for our user.

html {
    font-size: 62.5%;
}
body {
    font-size: 1.6rem;
}
header {
    font-size: 3rem;
}
section {
    font-size: 2.5rem;
}
footer {
    font-size: 2.8rem;
}

In line with the new HTML size (62.5% 18px = 11.25px), the re-calculated value of the header element's font-size will be 33.75px (3rem 11.25px ). The one for the section element will roughly be 28px (2.5rem 11.25px). And finally, the font-size of the footer will be 31.5px (11.25px 2.8rem) from the perspective of our imaginary user.

In other words, with the new arrangement involving the font-size of the HTML and body, everything else will be handled smoothly under the hood without you as the developer having to perform separate calculations for every single element.

Is This Method Bullet-Proof?

Despite the fact that the method that uses the root size '62.5%', since it's specifically a percentage value and the rem-based preference in the body section gives us a chance to play around with the general font-size dynamically, it is also not risk-free and you should use it cautiously (see this article for more info).

For instance, it may lead to some problems when 'em' values are preferred instead of 'rem' values. Plus, this technique only resizes text. So you'll need to use some other tricks (for example, when dealing with the size of the images).

That said, overriding the root font-size is still a widespread practice preferred by many developers around the world and it can be handy if used carefully.

Wrapping Up

All in all, the concepts of accessibility, responsive web design, maintainable and scalable code, and web performance are fundamental in creating a solid user experience.

Perhaps in the future, someone will come up with a better way to handle this. I just wanted to share with you the pros and cons of adjusting the root font size.

Even if you are not planning to use it at all, one of your teammates might go for it. So it is always a good idea to be aware of the arguments for and against it.

Thank you for reading. If you've liked this article, one of the best ways to support me is to share it. Should you have any questions or comments, you can always contact me via LinkedIn. I'll be more than happy to help you out with your queries.

Happy coding!

“Knowledge is power.” – Francis Bacon

This question comes from designers and developers alike. So, I figured it was time to write about it to create awareness and demystify the role.

This article will help you understand what a UX Engineer is, what their duties are, the required skillset, and it may even convince you to be come one yourself.

What Does User Experience Mean?

Before we jump into the role of UX Engineer, let's take a brief moment to define User Experience.

Most people are familiar with UI, which refers to the user interface. The user interface is most commonly the screen in which user is interacting with, for example a website or application.

UX relates to the all encompassing experiences the end user has while using a product or service, UI included.

The significance of UX is undeniable. In The User Experience Team of One, author Leah Buley notes,

“UX is a force for good. In an increasingly technological world, designing products with real people in mind helps us make sure that technology integrates in our lives in a human way. It’s a voice of reason, arguing that products and technology can support and even enrich our fundamental humanity.”

Who are UX Engineers?

A UX Engineer (UXE) is the bridge between design and development.

Icon credit: Noun Project

Engineers

UXE's are engineers first, with a working knowledge of design. Front end development skills are a prerequisite. A UXE cares deeply about the user experience and is heavily involved in impacting it.

"Developers write the code and build the systems that make the experience real. That moment when a flat concept on a page becomes a working, functioning, interactive thing is like making life. It’s incredibly rewarding. It also enables them to see and understand how it will feel and function for the enduser." – The User Experience Team of One

Designers

UXEs can be particularly useful in conceptualization stages of design. They are able to help designers understand what is feasible and how much engineering effort it may take to achieve.

Some UXE's will contribute prototypes, wireframes, and design mockups. The amount of true design work can vary from company to company.

It is common for a UX Engineer to be working within a Design System. For example, my role at D2iQ includes maintaining a design system and component library.

Advocates

A UXE will need to have empathy for both sides and be able to advocate for design or development. They may be required to push back on either side as an advocate. This is the reason they are considered the bridge between design and development.

A UXE may even need to advocate for UX itself within their organization, to create awareness and to build support for their work. This can be achieved through setting up a peer-to-peer learning community, lunch and learn meetings, and other methods to share and educate others.

You may find varying definitions of what a UX Engineer means. The lines are often blurred between UI Engineer, UX Engineer, and Design Technologist. Much of the role can depend on the company and what are the needs they want to fill with that role.

You may thrive as a UXE if you enjoy:

• Front end engineering
• Styling with CSS specifically
• Design thinking
• Occasionally flexing some design skills
• Participating in UX Research
• Working with Design Systems
• Creative leeway

We'll dive deeper on the skills required as a UXE which may clarify what exactly it entails.

Confusion within the Front End

I wanted to make a note on the confusion between UI Engineer, UX Engineer and Front End Engineer. These are often assumed to be the same role. That may or may not be the case, depending on what is in the job description. However, there are some notable differences.

UI Engineer is the most similar to a Front End Engineer. They're not entirely the same historically, but the line between the two has become blurry. They will work on the technical side of building the user interface. Working on the UI can easily start to bleed into UX topics as they are tightly coupled, which may be where the confusion arises.

On the other hand, a UX Engineer is the more design forward of the two. A UXE is a technical role that is intrinsically involved in the user's experience. They would be the one to consider "how is the user interacting with this button?", "how can I make it absolutely clear what this button does", and "how can I provider the user a better experience when using this button?"

On the other hand, a UI Engineer would generally ask themselves how to best match the design to engineer an efficient button.

This is of course glossing over the depths that each role can go into. UI Engineers can become more involved in UX if they take a conscious efforts to impact it.

The job description of UX Engineer might align more with what you would see under Design Technologist or Design System Engineer.

Overall, the term Front End can cover a broad range of individually complex topics and skillsets, which is why we are starting to see the need to define more specific roles within Front End. UX Engineer is among the more recent positions to become defined based on this.

Required Skills for a User Experience Engineer

There are many skills that a UXE may possess that aren't limited to Front End development and design. Again, much of the role can be dictated by the company’s definition of the role and responsibilities.

Below are some of the key skills that would be most commonly applicable and helpful to have.

Technical Skills

Front End Development. This includes knowledge of HTML, CSS and JavaScript. You should also know popular JavaScript libraries such as React. This could additionally include testing, debugging, build tools, and dependency managers.

CSS Specialists. It is important to note that the role requires in-depth knowledge of CSS. This could entail CSS architecture or working with preprocessors like Sass and Less. It's beneficial to have experience with CSS-in-JS libraries such as Styled Components and Emotion.

UI/UX Design. This may be a mix of design related skills from prototyping to UX Principles to wire-framing. UXE’s may produce low-fidelity or high-fidelity design mockups. It is helpful to have experience with design tools such as Figma, Sketch, or InVision. Design systems could also be lumped into this category. It's valuable to understand the benefit of design systems, and knowing how to enforce the design standards in the UI.

Storybook. Storybook is a tool to help engineers build, test, and display UI components. Working with Storybook will require additional niche technical know-how specific to this tool. There is a likelihood that if you are working with a design system and component library, the documentation is utilizing Storybook.

Accessibility. To excel in this role, you need to understand accessibility guidelines. Caring for users means inclusive design. Products should not limit the type of user. Products should account for all users. Having technical skills to test and improve the accessibility of applications will be extremely beneficial.

Responsive Design. Designers may only be able to mock up several screen size views such as mobile, tablet, and desktop. You'll be implementing those designs. There are gaps between each screen size mock which will require technical and decision making skills and for a seamless transition. These are the types of problems you will encounter and they impact the user experience.

Less Technical Skills

Empathy. This is a crucial skill for a UXE. They need to understand users in order to improve their experience. This includes having a passion for understanding how people think. Caring deeply about the impact you can have on user experiences will take you far in this field.

Communication and Collaboration. UXEs are required to do a lot of cross-functional communication. They can speak with users, designers, developers, product owners, and stakeholders. They are held responsible for translations between design and engineering teams. There is a likelihood of contributing to documentation which uses written communication skills. This could include documenting style guides, components, or guides for users.

Creativity. It may seem obvious that this would be a great skill to have based on the design factor of the role. UXE's have the opportunity to find creative solutions especially when design and development need to meet in the middle.

User Experience Principles and Theories. Understanding the psychological aspect of UX will come in handy when making design decisions. Learning psychological heuristics is essential. The Laws of UX site is a great overview of these.

Summary

As design and engineering processes mature, there is a need for roles like UX Engineer, UX Researcher, UI/UX Designer, UI Engineer, and more, each with their own set of advanced skills.

By collaborating, these roles are able to come together to create top-notch experiences for users. The need for many of these roles has been increasing in recent years, especially with the recognization of the importance of design systems within organizations.

UX Engineers fill a void that can be beneficial to the handoff between design and development. We will continue to see an increasing amount of UX Engineering roles surface as the significance of this role becomes further recognized.

I love the blend of skills that I am able to use daily as a UXE. If you are a creative individual who wants to work closer with design teams this may be the perfect role for you too.

If you would like to learn more about working as a UX Engineer, feel free to reach out on Twitter.

In this article, I will provide definitions for UI/ UX design as well as starting salary information from around the world.

What is UX design?

The term User Experience refers to how users interact with a product or service. Whenever you login into a website, or play a game on your phone, your interaction with that application is considered user experience.

If you find a product to be easy to use and understand, then that would be considered a positive user experience. But if the product is confusing and frustrating then that would be considered a negative user experience.

If you want to learn more about UX design, and find resources to start learning, then I would suggest reading my article on What is UX Design?

What is UI design?

The term User Interface refers to the look and feel of a product. For digital products, UI design focuses on all visual aspects including fonts, colors, spacing, responsive design and more.

Good UI design is considered to be simple, easy to understand and consistent. You don't want users to have to struggle with navigating through the product because it is not intuitive.

Bad UI design is considered to be inconsistent and difficult to understand. If users are confronted with low quality images, inconsistent fonts or poor contrast in visual content, then the user will want to leave the product as soon as possible.

If you are interested in learning the fundamentals of UI design, then I would suggest reading through this Per Harald Borgen article.

Resources to start learning UI/UX design

Here is a list of resources to learn UI/UX design.

• Foundations of User Experience (UX) Design
• The 2019 UI Design Crash Course for Beginners
• Figma Tutorial – A Free UI Design/Prototyping Tool
• UXpin: Free UX Ebooks

Salaries around the world for UI/UX designers

In this section, I will show you some salaries from around the around for entry level UI/UX designers.

United States

This data was pulled from indeed.com, payscale.com, and ZipRecruiter.

This data represents the national average. If you want data for your specific city, then you can search for that in these job sites.

Canada

This data was pulled from ZipRecruiter.

Mexico

This data was pulled from payscale.com and is in MXN currency.

UK

This data was pulled from uk.talent.com. The average entry level salaries for UI/UX designers would start at £35,000.

Other Countries around the world

If you want to explore other UX salaries from around the world, you can look into https://uxdesignersalaries.com/

You can also use popular job sites in your area, to find out the average entry level salary for UI/UX designers.

I hope you enjoyed this article and best of luck on your UI/UX journey.

In this article, I will explain what UX design is and talk about how to become a UX designer.

What is UX design?

The term User Experience refers to how users interact with a product or service. Whenever you login into a website, or play a game on your phone, your interaction with that application is considered user experience.

UX Design goes beyond digital applications. User Experience is relevant for any product or service that a user interacts with.

Other examples would include assembly guides for putting together furniture or a dining experience at a restaurant.

If you find a product to be easy to use and understand, then that would be considered a positive user experience. But if the product is confusing and frustrating then that would be considered a negative user experience.

Professional UX designers put a lot of thought into how a user interacts with a product to ensure that they have a positive experience. Negative experiences can lead to loss of revenue for a company if the user decides, based on their experience, to no longer use the product or service.

History of UX design

The term User Experience Design was first introduced in the early 1990's by Donald Arthur Norman. In 1993, Donald was working as a User Interface Architect for Apple when he decided to change his title to User Experience Architect.

This is what Donald had to say about inventing the term User Experience:

“I invented the term because I thought Human Interface and usability were too narrow: I wanted to cover all aspects of the person’s experience with a system, including industrial design, graphics, the interface, the physical interaction, and the manual.”

Donald is considered a leader and educator for User Experience Design. He is also an accomplished author with his best selling book The Design of Everyday Things.

Even though the term User Experience Design wasn't introduced until the early 90's, examples of UX design date back further than that.

Many people regard Walt Disney as one of the first UX designers because of his parks and resorts.

In the 1950's, Walt Disney wanted to create an amusement park that was fun for both adults and children. During those times, amusements parks were seen as dirty and seedy places that weren't appropriate for children.

But Disney wanted to change all of that and provide park goers with a positive experience. A lot of care went into the construction of the park by the designers and engineers ("Disney Imagineers").

One example of strong UX design at the parks is the number of options that attendees can choose from. The parks were designed to appeal to all types of guests.

Whether you are a teenager looking for thrill rides or a young family looking to ride Dumbo the Flying Elephant or the tea cups – there is something for everyone.

Examples of bad UX design

Anything that is considered overly complicated, confusing, and hard to navigate would be bad UX design.

One example of bad UX in websites would be broken or invalid links.

I have created an example with dummy text and links that don't go anywhere.

If this were a real website, the user experience would be pretty poor because a lot of time is wasted clicking on links that do not work. This can be frustrating because users need to access that information but it is not available.

Another example of poor user experience is constant pop up ads and messages. These types of sites make it difficult to enjoy the content because you are constantly being interrupted with popups.

In this example, I have created a fake blog site where three different pop up messages urge you to subscribe.

This is clearly annoying to the user because they can't even read the blog post and now want to leave the page.

What does a UX designer do?

UX designers will test and research to make sure that products and services create a positive user experience. When designing a new product or service, the first step is to conduct user research to better understand the audience.

During this first phase, UX designers need to understand what the user is hoping to get out of the product and identify possible challenges the user might face with the product or service.

The next phase is to create a User Persona which serves as an example persona of a customer using the product or service. This type of tool helps UX designers identify what a user is looking for from the product and produce a positive experience.

The next phase is to think about the structure and layout of the product so the user can easily find the information they are looking for. UX designers will start to focus on the user flow which is the complete process a user goes through while interacting with the product.

The last step is to create a prototype and perform user testing. UX designers will study the results from those tests and make the necessary modifications to the product.

Where to learn UX design?

There are plenty of free high quality courses you can take online to start learning about UX design.

I would suggest going through the Google UX Design Professional Certificate on Coursera. Each of the seven classes are free to audit.

You can also read this article and watch the associated YouTube course for a good introduction to UX and UI Design.

Salary for UX designers

There are many different job titles for User Experience.

Here are some common job titles:

• User Experience Architect
• User Experience Researcher
• User Experience Designer

It is important to note that salaries will differ depending on your location. You can use sites like Indeed or Glassdoor to research salaries.

These are some example salaries for UX designers based in the United States. This data is being pulled from Salary.com.

I hope you enjoyed this article and best of luck on your UX journey.

You're not the only one.

We live in a beautiful era of design, with new techniques and trends coming and going. Frontend development is also gaining increased momentum, with more and more developers getting involved in UI/UX design.

While both UI and UX design are often placed on the same pedestal, they are fundamentally different, and beginners should understand the difference between the two.

Knowing this, my team from Creative Tim and I have done a lot of research and created a comprehensive guide on the most important parts of these two huge domains:

1. UI Design — How Things Look
2. UX Design — How Things Work
3. What Are the Key Differences Between UI and UX Design?
4. What Do UI/UX Designers Do?
5. What Are the Disadvantages of a Combined UI/UX Role?
6. How Do UI/UX Designers Work Together?
7. What Are the Salaries of UI and UX Designers?
8. How Do You Become a UI or UX Expert? What Kind of Design Courses/Tutorials Should You Take?
9. Which Should You Specialize In? UI or UX Design?

UI Design — How Things Look

A UI (User Interface) deals with the application's graphical layout, which includes buttons, screen layout, animations, transitions, micro-interactions, and so on. In short, UI is all about how things look.

UI design includes the following formats:

• Graphical User Interface (GUI): GUI design involves how users interact with the visuals and digital control panels of a system. The computer's desktop is an example of a GUI.
• Voice-controlled Interface (VUI): VUI design deals with the interaction between a user and a system using voice. Smart assistants like Bixby for Samsung mobile devices and Siri for iPhones are examples of VUIs.
• Gesture-based Interface: This is mostly used in virtual reality (VR) and other gesture-based design scenarios, which deal with the engagement of users within 3D spaces. Here is an example of our fully coded simulation of the Soft UI Admin Dashboard in VR:

Source

For good UI design, you should take these characteristics into consideration:

• The design should be focused on helping users complete tasks quickly with minimum effort. Completing tasks should be a seamless experience.
• It should be enjoyable, satisfactory, and free from frustration.
• The UI design should communicate the brand value of the company/organization.

UX Design — How Things Work

UX (User Experience) design deals with how users interact with the system. Logical navigation and how smooth and intuitive the experience is all fall under UX design. In short, this type of design helps users have a positive experience.

To get a feeling of the UX process, here are the main steps:

• Interaction Design deals with how users can complete their tasks effortlessly by using the interactive components of a system (page transitions, animations, buttons, and so on).
• User Research involves conducting extensive research, collecting feedback and ideas from new or existing customers, understanding end user needs, and making design decisions based on these parameters.
• Information Architecture involves the organization of information and content that users need to do their tasks. This requires a UX designer to understand the relationship between different sets of content and present them in the most understandable way possible.

For good UX design, you should follow these practices:

• The product should be easily usable, logical, and self-explanatory.
• The product should solve users's problems.
• The product should be accessible and usable to a wide range of people.
• The product should create a positive experience for the user, allowing them to complete tasks without frustration.

Cognitive Biases

Great UX designers must be aware of the cognitive biases that we all have, as this can affect the interaction between the user and interfaces. Many marketing strategies are based on these biases:

_Source_

What Are the Key Differences Between UI and UX Design?

UI and UX design have often been used as interchangeable terms.

While the end product requires consideral input from both design methodologies, the process of designing UI and UX is very different.

UX design mostly deals with the user’s entire journey to solve a problem.

On the other hand, UI design is focused on how the product looks and feels when the problem is being solved.

Here are the main differences between UI and UX design:

• Main focus: The main focus of UI designers is to deal with the quality and visuals of the end product, and use hi-fi models as prototypes. UX designers focus more on the purpose and functionality of the end product, and care more about logic. Additionally, UI designers deal with the technicalities of the product design, while UX designers focus more on project management and analysis of the project.
• Use of color: UI designers design prototypes in full color while UX designers do so in black, white, or grey.
• Tools: UI designers use tools like Sketch, Flinto, Principle, and InVision for collaborative image designing. UX designers use wireframe-based prototyping tools like Mockplus.
• Artistic Component: UI designers have to include an artistic component in their design since it is related to what the end user sees, hears, and feels. UX design has more of a social component, as it needs to understand what a user wants to experience in the end product.

Here is an example of UX and UI prototypes for the same end product:

Source

What Do UI/UX Designers Do?

If you want to become a greate UI designer, you should develop the following skills/responsibilities:

• Working in agile teams.
• Creating user flows, wireframes, prototypes and so on.
• Visualization tools such as InVision, Sketch, Photoshop, Figma, etc. For more details about which tool to choose, check out our research in this article: InVision vs Sketch vs Figma vs Photoshop
• Frontend programming languages such as HTML5, CSS3, and JavaScript.
• Executing visual design stages from inception to final hand-off.
• Collaborating with UX designers, developers, QA, and product managers to design and implement innovative visual ideas for products.
• Communicating the branding and style of the company to users through design.
• Creating the look and feel of the product using customer analysis and research.
• Managing the responsiveness, interactivity, and animation of a product and making it adaptive to all device screen sizes.

If you want to become a great UX designer, you should develop these skills/responsibilities:

• Working in agile teams.
• A strong understanding of the UX process.
• Prototyping tools like Adobe Creative Suite, Sketch, InVision, Axure, etc.
• Problem solving skills and curiosity about everything related to design, people, life and technology.
• Stakeholder management and client interaction.
• Creating process flows, wireframes, sitemaps, prototypes, and UX deliverables.
• Collaborating closely with developers, product managers, UI designers, external stakeholders, and QA Engineers to iterate designs based on market dynamics, user feedback, and tech constraints.
• Analyzing customer needs, competitors, product structure, and strategies for designing the experience of a product.
• Creating seamless design and interaction strategies for mobile, web, desktop, and other hardware endpoints.

What Are the Disadvantages of a Combined UI/UX Role?

Having a combined UI/UX role is almost like wearing two different hats at the same time.

While most organizations advertize a UI/UX role as a single, combined role, a UI and UX designers have different skill sets. Their main focus, way of thinking, and method of prototyping a product differ greatly.

A combined UI/UX role requires constant switching between conceptualization and visualization, which is often difficult and can reduce the amount of attention that each discipline requires.

How Do UI/UX Designers Work Together?

While UI design and UX design require very different skill sets, they are both important components that must work in harmony to give the best experience to end users.

A UI design might be beautiful, but it can be clunky and confusing to navigate without a good UX design. On the other hand, the user experience of a product can be flawless, but it is nothing without a good looking user interface.

Any frontend development and design process should start with understanding the needs of the user. UX and UI designers should work in collaboration with other developers, managers, and product owners to understand what the end product should be able to do, how it should feel, and what it should look like.

UX designers are generally involved in the earlier phases of a product design since they need to design the flow of activities that take place when a user needs to solve a problem. This involves analytic and project management activities.

Later, a UI designer builds on the aesthetics and interactions based on the models provided by the UX designer.

Given this, it is safe to state that UX and UI go hand in hand. And while there are instances when the same person does both, one design principle cannot exist without the other.

What Are the Salaries of UI and UX Designers?

UI designers earn an average of 50k worldwide, with the average salary in the USA being 91k, Germany being 57k, France being 47k, and 67k in the UK.

UX designers earn slightly more, with an average of 52k worldwide. UX designers in the US earn 102k on average, with Germany paying 53k, 49k in France, and 68k in the UK. (Source: Glassdoor)

Note: All the salaries listed above are an average for the area, and are in USD.

How Do You Become a UI or UX Expert? What Kind of Design Courses/Tutorials Should You Take?

Becoming a UI or UX expert starts with being genuinely interested in UI/UX design. Once you know you're interested, you should find resources and take design courses that help prepare you for the job market.

There are online courses like the UI Design Program and Learning UI Design that can help you kickstart your journey towards becoming a UI designer.

For UX design, you can study online, paid courses, or courses from online universities. You can also look at the best online course websites to learn UI/UX so you can see which websites offer courses for free and the user feedback on these websites.

For UX design, there are a number of paid courses, of courses from online universities. You can also check out a list of the best online courses to learn UI/UX design so you can see which websites offer courses for free, and read user feedback.

Suppose you already have some of the required skills to be a UI/UX designer. In that case, you can also take a look at articles like the behavior patterns for UX design, UX methods that you can use, inspirational graphic designs from the world's best designers, and academic research papers that designers should read.

Which Should You Specialize In? UI or UX Design?

Specializing in UI or UX design is a personal preference that depends on your particular skillset.

However, there are a huge number of companies that advertise a combined UI/UX designer role.

While the roles and responsibilities of both these vary differently, there is still a niche market for UI/UX design, making it a good idea to have adequate knowledge about both.

While difficult to implement, a combined UI/UX career can prove fruitful in terms of salary compensation and importance in the company.

However, a combined UI/UX designer role is difficult to perform since it needs constant switching from one mindset to the other. So it is often a better option to specialize in one role instead.

For example, if you are artistic, know effective color combinations, and understand how products can be visually enhanced, UI design is a good choice for you.

On the other hand, if you are good with managing user and stakeholder needs, have excellent analysis skills, and understand how user experiences can be improved, UX design would be more suited to you.

Final Thoughts

User Interface and User Experience design both require an understanding of what users need.

Once you have this understanding, frontend development and design do not have to be a complex affair — there are a lot of ready-made components, tools, and kits that can make design easier and more effective.

Creative Tim offers you a huge number of free and premium, fully coded UI tools like Templates, Dashboards, and Design Systems.

If you want to build your illustrations using hand-drawn sketch components in a scalable manner, look no further than Creative Tim’s product: IRA Design.

And let's keep in touch on Twitter.

Screenshot taken moments before a rage-quit

If you're here, you're likely concerned with making your user-facing products as delightful as possible. And error messaging plays an important role in that.

Having useful error messages can go a long way toward making a frustrating scenario for an end-user as pleasant as possible.

This article is split into two parts. The first builds context around error messages and why they're important. This section should be useful, regardless of whether you're a JavaScript developer or not.

The second part is a short follow-along to help get you started managing your own error messages.

The current state of error messaging

In a perfect world, error messages would be redundant and users would be able to use anything you've built a-okay, no problem-o. But errors will happen, and your end-users will run into them.

These errors can stem from:

• Failing validation
• Server-side failures
• Rate limiting
• Borked code
• Acts of god

And when things go wrong, often the client-facing error messaging takes shape in one of two ways:

• Generic errors with no meaningful information, e.g. Something went wrong, please try again later
• Hyper specific messages from the stack trace sent by the server, e.g. Error 10x29183: line 26: error mapping Object -> Int32

Neither are helpful for our end-users.

For our users, the generic error can create a feeling of helplessness and frustration. If they get such a message, they can't complete an action, and have no way of knowing why the error happened and how (or if) they can resolve it. This can result in loss of end-user trust, loss of customer, or an angry review.

On the other hand, hyper-specific error messages are a leaky abstraction and shouldn't be seen by our end-user's eyes.

For one, these kind of errors provide implementation information about our server-side logic. Is this a security concern? probably? I'm no pen-tester.

Secondly, if we're in the business of crafting engaging user experiences, (and why wouldn't you be?) our error messages should feel human and be service-oriented. This is a sentiment shared in a number of resource I've come across, many of which of I've included in a further reading section at the end.

Why should I create sane error messaging?

To help maintain developer sanity

Hunting bugs is hard, and scanning logs is tedious. Sometimes we're provided with context about why things failed, and other times we aren't. If an end-user reports a bug it's important they can present to us as much useful information as possible.

A report from a user that says:

Hi, I was using the app sometime last night updating my profile and all of a sudden it stopped working. The error said something about a validation error, but I don't know what that means

is much less useful than:

Hi, I was using the app sometime last night updating my profile and all of a sudden it stopped working. The error said "We had trouble updating your details. Your address must be located within the EU" but I live in England

This saves us time and cuts down on red herrings. A clear and specific error message may also help an end-user understand what they themselves have done wrong, and can allow them to fix their mistake.

To help maintain organisation sanity

Sane error messages also yield benefits on an organisation level. For those working in larger companies, copy/messaging may be the responsibility of an entirely separate department. The more places in the code that require copy changes, the easier it is for the copy to get out of sync with your company's brand guidelines.

Conversely, keeping all of your error messages in a single source makes it much easier for those owning copy to adhere to those brand guidelines.

Other departments, like the support team, may be inundated with support tickets from users. If you're an engineer, why not reach out to your support team to see how many support tickets could be avoided with improved error messaging.

Fixing the problems with your messaging when a user incorrectly fills out a form, has missing data, or doesn't have permissions for a specific action could positively impact the lives of the support team.

To help maintain end-user sanity

By providing sane error messaging we hope to not leave our end users feeling helpless.

As described earlier, our messaging should be service-oriented. They should guide our user on how to complete their process, or at least let them know where they can go and get help if the problem is beyond their control.

In Jon Yablonski's book, the Laws of UX, he describes a psychological concept called the Peak-end Rule:

People judge an experience largely based on how they felt at its peak and at its end rather than the total sum or average of every moment of the experience

In the context of this article, if people become so frustrated that they rage quit your site, their lasting memory of your application is of how frustrating it is to use.

Error messages play a large part in preventing this, as they can act as the final gatekeeper preventing a user who is simply stuck from turning to one so frustrated they quit your app.

If someone is using your product for a transactional purpose like buying an airplane ticket or shopping online, and they've been stopped dead in their tracks during a task with no way to continue, the likelihood of them leaving your site for another skyrockets. Another lost customer.

While this is wholly anecdotal, I've rage quit sites often from not knowing how to complete a process – either nothing happened when I clicked a button, or I just kept getting vague error messages.

Unless these sites/apps are one of those few ubiquitous platforms (like Google, Instagram, Apple), I likely haven't have used them since. I'm sure you can even remember a time this happened to you. In fact, I'll openly welcome pictures of awful error messages via Twitter

Using sane error messaging can help offset this frustration if something doesn't go right. Surprisingly, creating a useful error message only requires a handful of qualities.

What makes a good error message?

Taken from Microcopy: A complete guide. A useful error message should satisfy these qualities:

• Explain clearly that there is a problem
• Explain what the problem is
• If possible, provide a solution so that the user can complete the process, or
• Point them to where they can go for help
• Make a frustrating scenario as pleasant as possible

This might sound like a lot to cover with just a couple of sentences, but here are some examples of what I deem to be good error messages:

• We've limited how many times you can reset your password every hour. You can try again later.
• Please log in to view this profile
• We couldn't create your profile, only UK residents can use our app.

It's worth noting that I'm not a UX researcher/designer, just a frontend developer with a keen interest in UX. It may be that my above examples miss the mark on what's required within your project or organisation.

Saying that, if you're a frontend engineer, improving your organisation's error messaging makes for an excellent opportunity to upskill and collaborate with your UXer colleagues.

How can I start writing sane error messages?

I've open-sourced a simple tool called sane-error-messages. Running the tool will generate a brand new repo designed to house your default error messaging. You can tweak the default values, add or remove messages, and then publish it to consume within your client facing apps.

sane-error-messages works by aggregating all of your messaging in to a single JavaScript object. The key is an error code, and the value is a corresponding message.

The error codes should be the same codes you receive from your server, such as POSTS_NOT_FOUND or CONFLICTING_USER_RECORD. Your error messaging repo exposes a function to get your error message from an error code.

This approach was inspired by how tools like Cypress handle their error messaging.

As long as your server returns predictable error codes, the server-side implementation doesn't matter. The following sequence is just one way of implementing sane-error-messages

Having a separate repo becomes more important the more user-facing apps you have.

In short:

• The user "views all products"
• The frontend makes a network request
• The network request fails and returns an error code "USER_NOT FOUND"
• The frontend requests the corresponding error message from your error-messages package.
• The frontend applies any relevant contextual information
• The frontend displays this information to the end user.

If you want to try something hands on, you can play with this CodeSandbox. The CodeSandbox fires off a request to a mock server which returns 1 of 12 error codes at random.

The client side will use the error code to retrieve a sane error message from the error messages repo. The client side then displays the error message to the user. If the code doesn't have a specified message, the generic fallback gets shown (and it sucks).

Some sane error messages in the wild

How to set up your error messages

Note: You can find the repo here. If you come across any problems during the tutorial process you can file a GitHub issue.

Begin by running

yarn global add sane-error-message

then

sane-error-messages create <dirName>

to scaffold your project. Doing so will create a brand new module for you to customise with your default error messages.

Your new module uses tsdx under-the-hood to handle all of the module management scripts, such as running, building, and testing.

You can learn more about tsdx here.

In short, the contents of your new package will look like this:

/* errorCodes.ts: The file that defines each error code like */
const USER_NOT_ADMIN = '403_USER_NOT_ADMIN'

/* defaultErrorMessages.ts: Maps each code to a default message */
const errorCodes {
  // your codes and messages go here...
  [USER_NOT_ADMIN]: "We're afraid only administrators have access to "
}

/* ErrorMessages.ts: The class you'll use to instantiate your error messages object in the consuming project */
class ErrorMessages {
  // You can override default messages with more specific ones
  constructor: (customErrorMessages: Partial<Record<string | number, string>>): ErrorMessages;

  // Pass through an error code to get your custom message
  getErrorMessage: (code: string | number, fallbackMessage?: string): string;

  // Checks to see if the argument is a valid error code and acts as a guard for non-ErrorCode values
  isErrorCode(code: string | number): boolean;

  // Returns the errorCodes object with your custom messages
  messages: Record<ErrorCode, string>
}

type ErrorCode = ValueOf<errorCodes>

How to consume your error messages

If you created a repo with the name custom-error-messages and published it to npm, you'd be able to consume it within your apps by doing the following:

import { ErrorMessages } from 'custom-error-messages';

const customErrorMessages = {
  '400_validation': 'Please enter the fields in your form correctly',
};

// Initialise your errorMessages object with your custom messages
const errorMessages = new ErrorMessages(customErrorMessages);

function riskyFunction() {
  try {
    // Throws an error 
    await boom();
  } catch (err) {
    // Get the error code our server sent over
    const { code } = err;

    // Get the code's corresponding message
    const message = errorMessages.getErrorMessage(code);

    // Display the message to the client
    displayNotification(message);
  }
}

You can then take all of the error codes that your server-side returns and apply corresponding messages to them.

Once you're ready, you can publish your tool to NPM, and then consume it from your client-facing apps.

Conclusion

I hope you've enjoyed learning about an often overlooked aspect of web development.

I've done a bunch of reading to learn about error messaging and I've shared some of my favourite resources below. Some are books and others are short articles, but they're all worth your time.

You can also reach out if any part of the tutorial wasn't clear, or if you feel I can streamline things. Thanks for reading.

FAQs

Why can't the server-side just return these messages?

The server shouldn't be concerned with any client-facing logic. But if you're fortunate enough to work with an API that gives useful error codes with each failed request, then you're nearly there.

Will I need to create an instance of error-messages for every API consumer?

Not necessarily. Because this package can take a list of default messages and codes, as long as it's in sync with the APIs, your frontends will be able to consume the same package.

In each client-side instance, you can pass through additional error codes, or override existing messages to tailor your frontend messaging.

I think this package should have X or do Y differently

I'm dogfooding this internally at my job, and this is a problem space I'm very new to. I would love to hear of any suggestions, or improvements to the overall architecture or feature-set of sane-error-messages.

Further Reading

Microcopy: A Complete Guide
I mentioned this book a little earlier, and it's one of my favourites when it comes to making my user-facing products a lot more personable.

The book's author Kinneret Yifrah, has graciously provided a coupon for 10% off, you can purchase it here.

Coupon code for the eBook: andrico-ebook

Coupon code for the bundle: andrico-bundle

Error messaging guidelines: NN Group
A short article on the importance of sane error messaging which shares some very useful tips on how to create sane error messaging.

In short:

• Errors should be expressed in plain language
• Indicate what the problem is
• Suggest a solution

Error Messages (Design basics): Microsoft
An in-depth article that covers both design guidelines messaging practices

Laws of UX
A short book that introduces how a handful of psychology concepts can be used to improve your products UX.

There are three core skills that every modern product designer must master: product thinking, visual design, and interaction design.

The “table-stakes” for all modern product designers.

In general, you should be good at all three, but you should be really good at two. Most designers can teach themselves visual design and product thinking through online resources, practice, and shipping real products.

As a product design lead at a FAANG company that has mentored hundreds of aspiring designers, I find that interaction design tends to be the most challenging core skill for designers to self-learn.

In this article, I provide a foundation and framework for learning and improving your interaction design skills.

The difference between UX (user experience) and IxD (interaction design).

What is Interaction Cost?

The foundational concept behind interaction design is “interaction cost,” which is often used to measure a product’s usability. Nielsen Norman defines “interaction costs” as the sum of mental and physical efforts that users must exert to reach their goals.

In general, we want to keep interaction costs as low as possible. However, this is difficult, as the more use cases your product covers, the harder this becomes.

Supporting more use cases and functionality adds complexity to your product’s information architecture (IA) and navigation. A use case is a sequence of steps, starting with a user’s goal and the result when that goal is achieved.

A more complex IA will inherently increase the number of clicks required to accomplish a user’s goal. For example, an iOS clock app has the following alarm use case goals: turn on the alarm, create a new alarm, and edit the alarm.

The more complex the IA, the more the user has to click to get to their desired screen. [Credits: Topta](https://dribbble.com/shots/4406909-The-Comprehensive-Guide-to-Information-Architecture" rel="noopener nofollow)l

The rule of thumb focuses on reducing the interaction costs for your target user’s primary use cases. Whenever a product accommodates too many use cases (for example, enterprise products with a million dropdown menus and features), it becomes harder to use.

To avoid this over-complication, choose a specific user and use case to focus on when building a brand new product.

Physical and Mental Interaction Costs

Many junior designers have the misconception that interaction cost equals the number of clicks required for a user to complete a task.

However, it goes much deeper than that. Interaction cost can be classified as mental interaction costs (MIC) and physical interaction costs (PIC), which I’ll explain below.

How to Evaluate Interaction Cost – Find the Critical User Flows First

A best practice is to identify the primary use cases (that is, the red routes) and reduce their interaction costs at the expense of secondary and tertiary use cases if necessary.

You can use a Red Route Analysis (RRA) to assess which use case interaction flows are most important to your primary users.

Red routes tend to be critical, encompass end-to-end tasks with multiple steps, are often used, are built for high volume usage, provide the most value, have clear success criteria, and tie to product metrics.

You can create an RRA from user interviews or with data if the product is live.

For instance, in the Uber app, the rider’s red route would be requesting a ride, while their normal route would be adding a payment method.

How Tesler’s Law Helps Reduce Interaction Costs

According to Tesler’s Law of Conservation of Complexity, all systems have an inherent complexity that cannot be removed or hidden.

Good design ensures that as much of the complexity burden is on the system as possible, rather than on the user.

You should begin by reducing the interaction costs within the primary use cases and shift the complexity burden towards the least important use cases.

Tesler argued that a designer and engineer should spend an extra week reducing an application’s complexity rather than making millions of users spend an additional minute.

Be careful not to simplify interfaces to the point of abstraction, though. A common pitfall is reducing the PIC at the expense of the MIC (I’m looking at you, Apple).

When the system has handled as much of the inherent complexity as possible, you should shift the rest of the complexity away from the primary use cases to the secondary and tertiary use cases.

Most digital products have complicated settings for this reason. In most cases, settings are usually a tertiary use case and are very rarely used.

Imagine if you always saw the settings screen instead of the home screen and needed to click several times to get to the screen you needed instead. You’d probably be frustrated at the unreasonable interaction costs.

Mental Interaction Costs (MIC)

Mental interaction costs (MICs) are often overlooked by new designers who only pay attention to physical interaction costs (PIC).

Common MICs that you may have noticed in products with poor usability include complex navigation, dense instructions, unconventional mental models and interaction patterns, and so on.

Attention and Memory

The two most important components of MIC are attention and memory.

When a task requires excessive attention or memory to complete, it will have a proportionally high MIC — decreasing usability.

Some common elements that increase attention costs or divert attention include pop-up banners, models, attention-grabbing visuals, and motion unrelated to the user’s current task.

Users are easily distracted. Make sure you’re not pulling their attention elsewhere when they are trying to complete a task.

Evaluating Attention

If you want to evaluate how much attention MIC your interface has, consider doing an eye-tracking study (ETS). You can use an ETS to infer not only where users look but what they’re thinking.

An example of an ETS.

The ETS examines two relevant eye movements in particular: “fixation” and “saccade.”

Fixation occurs when a user’s pupils linger over an interface element long enough to process it. A Saccade occurs when the eye is in motion — darting between various areas within your interface.

If your ETS reveals many task-irrelevant saccadic movements, it’s likely due to a distracting interface. Your ETS results can help you understand if users are missing critical elements within the interface, what’s distracting, and what’s unnecessary.

Working memory

There is an extensive classification for all the different types of memory.

For our purposes as designers, working memory (part of short-term memory) is the most relevant. The shortest type of memory is known as working memory, which typically only lasts a couple of seconds during a task.

In other words, our working memory is responsible for the information we can hold in our heads while we engage with other cognitive processes.

Miller’s Law states that the average person can only keep 5–11 items in their working memory at a time. The working memory required to complete a task within your product is proportional to the MIC burden you impose on your users.

Conversely, at no point should your task require the user to hold more than seven items in their working memory at any moment.

In rare scenarios where you require the user to hold more than 11 items in their memory, use “chunking” to reduce their mental burden. Chunking is when individual pieces of an information set are broken down and then grouped in a meaningful whole.

For example, we remember phone numbers as XXX-XXXX rather than XXXXXXX. It’s easier to remember the number in two chunks rather than a series of seven individual units.

Another factor to consider related to attention and memory is “Hick’s Law.” The law states, “the time it takes to make a decision increases with the number and complexity of choices.

The more choices there are, the longer it takes the user to make a decision.

Avoid overwhelming users with excessive choices, highlight the best option for them whenever possible. Break complex tasks into smaller steps, that is using progressive disclosure when appropriate.

Physical Interaction Costs (PIC)

I won’t go into too much detail on PICs because most designers understand them well.

Common PIC factors include reaching distance and target width (Fitt’s Law), number of user inputs and actions required to complete a task, and so on.

Fitt’s Law states that the time to hit a target (that is, clicking on a button) is a function of the distance from your input device and the target’s hit-box width.

A diagram for Fitt's Law.

For example, clicking on a button on the desktop would take much longer if your mouse cursor was far away and the button was tiny.

An excellent method to assess PIC is “task analysis” and examining usability metrics such as “task time (TT).”

The root of TA is looking at the number of tasks required to complete the user’s goal, the frequency of those tasks, the physical requirements, and the task time.

TA and usability metrics are advanced topics that warrant an entirely separate note, so I’ll save it for next time.

Common Pitfalls to Avoid

According to Nielsen Norman Group, some of the most common aspects of a product that result in increased interaction costs include the following:

• Excessive reading and scrolling
• Looking around to find relevant information user
• Comprehending information presented to the user
• Physical user inputs
• Page loads and waiting times
• Attention switches
• Memory load

Situational Interaction Costs

The pitfalls mentioned above may be more or less critical depending on the user. For example, dyslexic users find reading more challenging than the average user (pro-tip: use a dyslexic friendly font like “Dyslexie”).

[Source](https://www.dyslexiefont.com/" rel="noopener nofollow)

Users with motor impairments might find clicking much harder than reading. Even the user’s device can play an important role. For instance, a page load on a mobile device may take forever if the cellular coverage is slow.

Interaction Paths and Motivation

In some situations, there are multiple possible paths a user can take to accomplish their goal. Users decide which path to take based on the concept of “expected utility,” defined as expected utility = expected benefits — expected interaction costs.

In other words, users weigh the benefits and costs of each action and choose the path that has the best balance of benefits versus cost.

Users will gravitate towards the path that has the lowest estimated interaction cost. Even if there’s a lower-cost path, if that path is unintuitive or unfamiliar, they will end up choosing the path they are more familiar with due to lower MIC.

Users with a high motivation (for example, due to your marketing or branding efforts) are more likely to put up high interaction costs to complete their goal. For example, if Apple’s website had high interaction costs, users may still be motivated enough to complete their task.

Apple is the world’s most valuable brand for a reason.

However, if users wanted to purchase a generic product, and the checkout process had a high interaction cost, they will buy it from a competitor instead.

For more details, take a look at Nielsen Norman Group’s example of how to assess the interaction cost of a use case, “finding out where the word ‘ceremony’ comes from.”

Conclusion

Understanding interaction cost is a vital skill for any modern product designer. I encourage you to go beyond the superficial interaction design considerations and delve deeper into the numerous PIC and MIC factors.

Of course, we should strive to reduce the interaction costs as much as possible. But when push comes to shove, we should make trade-offs to ensure the primary use cases have the least friction.

An excellent first step is to create a mental model of laws, frameworks, and tests to evaluate your design’s interaction costs.

If you liked this article, join my free newsletter “The Ambitious Designer” for more career & design insights.

I also run a private mentorship group on Facebook and a design Instagram account.

I read Max Bock's article on creating a custom theme, where he explained the process quite clearly. He also really went super pro (with TEN different color schemes).

But for my case I wanted more. I wanted users to be able to change the color scheme to the different options provided.

I also wanted them to be able to change the font size. This is because I had a fixed header on my site which was kind of great, but on small mobile devices it took up quiet a lot of space – not great for UX design, right? So I also gave users the ability to turn off that fixed header.

Spruce.com.ng Theme-able static site

You can find a live preview of this on my personal site spruce.com.ng. You can also copy the source code here to save you some read time.

What I Wanted to Do

1. Ask users their preferred color scheme, font size, and header type (fixed or static)

2. Collect user choices

3. Save them in localStorage

4. Get them from localStorage and show them to the user immediately on page reload, if they switch tabs and come back, and if they close their browser and come back after a week or month, until they clear their browser storage

How I Created the Theme

In 11ty (the static site generator I'm using) you can create a JSON file in the _data folder. You can access the data globally in your template (Jekyll does this too). It's likely that your preferred static site generator (SSG) can do the same.

_data/themes.json file

[
    {
        "id": "default",
        "colors": {
            "text": "#222126",
            "text-dark": "#777;",
            "border": "rgba(0,0,0,.1)",
            "primary": "#665df5",
            "secondary": "#6ad1e0",
            "primary-dark": "#382cf1",
            "bg": "#ffffff",
            "bg-alt": "#f8f8f8",
            "overlay": "rgba(255, 255, 255, .4)"
        }
                }, 
    ... other color schemes
]

How to Generate the CSS

To use the data file, create a file called theme.css.liquid and give it a permalink where you want the CSS file to output to.

css/theme.css.liquid file
---
permalink: /css/theme.css
---
// when no theme is selected
// use default theme
:root {
    --text: {{ themes[0].colors.text }};
    --text-dark: {{ themes[0].colors.text-dark }};
    --border: {{ themes[0].colors.border }};
    --primary: {{ themes[0].colors.primary }};
    --secondary: {{ themes[0].colors.secondary }};
    --primary-dark: {{ themes[0].colors.primary-dark }};
    --bg: {{ themes[0].colors.bg }};
    --bg-alt: {{ themes[0].colors.bg-alt }};
}  
// if user preferred color scheme is dark
// use the dark theme

@media(prefers-color-scheme: dark) {
    :root {
    --text: {{ themes[1].colors.text }};
    --text-dark: {{ themes[1].colors.text-dark }};
    --border: {{ themes[1].colors.border }};
    --primary: {{ themes[1].colors.primary }};
    --secondary: {{ themes[1].colors.secondary }};
    --primary-dark: {{ themes[1].colors.primary-dark }};
    --bg: {{ themes[1].colors.bg }};
    --bg-alt: {{ themes[1].colors.bg-alt }};
    }
}
// generate the theme css from the data file
// here we use a for loop
// to iterate over all the themes in our _data/themes.json
// and output them as plain css


{% for theme in themes %}
 [data-theme="{{ theme.id }}"] {
    --text: {{ theme.colors.text }};
    --text-dark: {{ theme.colors.text-dark }};
    --border: {{ theme.colors.border }};
    --primary: {{ theme.colors.primary }};
    --secondary: {{ theme.colors.secondary }};
    --primary-dark: {{ theme.colors.primary-dark }};
    --bg: {{ theme.colors.bg }};
    --bg-alt: {{ theme.colors.bg-alt }};
 }
{% endfor %}

Notice that I'm using themes[0].colors.text because my default theme is the first one on the list. It has an index of 0, so also my dark theme has an index of 1.

In Jekyll you can output liquid in CSS by just adding empty front matter at the top of the file.

css/theme.css file
---
---

// your liquid in css goes here

I'm sure your favourite static site generator provides a similar way to output liquid in a CSS file. You can also handcode all this if you are just writing plain HTML and CSS without a SSG.

How to Use the CSS in Your Site

If you are reading this, then I assume that you already know how to work with CSS custom properties. So I won't go in depth into that here.

// css custom properties are declared using the keyword **var**
// color: var(--text);
body {
    background: var(--bg);
    color: var(--text);
}
h1,h2 {
    color: var(--text-dark)
}
// i also had default font-size and margin-top properties set
// i added this to the :root in css
:root {
    --font-size: 18px;
    --position: fixed;
    --top-margin: 96px;
}

You just have to change every bit of color on your site to the custom properties you have generated.

How to Generate the HTML

Now let's provide a UI to allow users to change the font size, header type, and color scheme of our site. Mine is a bit simple, but you can take yours further. I'm just explaining the concept here.

theme.html file
// create the font buttons
// I gave each button a value
// I want to get the value and save it in local storage 

<section class="theme-section">
    <div class="theme-btn-wrapper">
        <button class="btn btn--small btn--border js-font-btn" value="16">16px</button>
        <button class="btn btn--small btn--border js-font-btn" value="18">18px</button>
        <button class="btn btn--small btn--border js-font-btn" value="20">20px</button>
        <button class="btn btn--small btn--border js-font-btn" value="22">22px</button>
    </div>
</section>

// Create the toggle button
// To turn On & Off
// The fixed header
// The **sr-only** is used to hide the text visually 
// while keeping accessibilty in mind
// note the **role="switch"** nd aria-checked
// they are what turns the button to a On and Off switch
<div class="check-wrapper">
    <span id="btn-label" class="sr-only">Fixed or static header</span>
   <button role="switch" type="button" aria-checked="true" aria-labelledby="btn-label" class="js-theme-toggle btn btn--border btn--rounded btn--toggle">
       <span>On</span>
       <span>Off</span>
   </button>
</div>

That's pretty much the HTML for my use case. Again you can do more if you want, and there is some CSS styling involved (which would be left out in our case).

The Fun Part: How to Create the JavaScript

/assets/js/theme.js file
class CustomTheme {
    constructor() {
        // part A: check if localStorage works
        this.islocalStorage = function() {
            try {
                localStorage.setItem("test", "testing");
                localStorage.removeItem("test");
                return true;
            } catch (error) {
                return false
            }

        };
        // part B: Get the value from the buttons
        this.schemeBtns = document.querySelectorAll('.js-theme-color');
        this.schemeBtns.forEach((btn) => {
            const btnVal = btn.value;
            btn.addEventListener('click', () => this.themeScheme(btnVal))
        });

        this.fontBtns = document.querySelectorAll('.js-font-btn');
        this.fontBtns.forEach((btn) => {
            const btnVal = btn.value;
            const btnTag = btn;
            btn.addEventListener('click', () => this.themeFont(btnVal, btnTag))
        });

        // part C: get the html button element
        this.switchBtn = document.querySelector('.js-theme-toggle');
        const clicked = this.switchBtn;
        this.switchBtn.addEventListener('click', () => this.themePosition(clicked))
    }

    // part D: Save the data in localStorage
    themeScheme(btnVal) {
        document.documentElement.setAttribute('data-theme', btnVal);
        if (this.islocalStorage) {
            localStorage.setItem('theme-name', btnVal);
        }
    };

    themeFont(btnVal,btnTag) {
        document.documentElement.style.setProperty('--font-size', `${btnVal}px`);
        if (this.islocalStorage) {
            localStorage.setItem('font-size', btnVal);
        }
        ;
        if (btnVal == localStorage.getItem('font-size')) {
            removeActive();
            btnTag.classList.add('active');
    }
};

    themePosition(clicked) {
    if (clicked.getAttribute('aria-checked') == 'true') {
        clicked.setAttribute('aria-checked', 'false');
        document.documentElement.style.setProperty('--position', 'static');
        document.documentElement.style.setProperty('--top-margin', '0px');
        if (this.islocalStorage) {
            localStorage.setItem('position', 'static');
        }

    } else {
        clicked.setAttribute('aria-checked', 'true');
        document.documentElement.style.setProperty('--position', 'fixed');
        document.documentElement.style.setProperty('--top-margin', '96px');
        if (this.islocalStorage) {
            localStorage.setItem('position', 'fixed');
        }
    }

    }
}

function removeActive() {
    const btns = document.querySelectorAll('.js-font-btn');
    btns.forEach((btn) => {
        btn.classList.remove('active');
    })
}

// part E: Only use our class if css custom properties are supported
if (window.CSS && CSS.supports('color', 'var(--i-support')) {
    new CustomTheme()
};

// part E: Add an active class to selected font size button

window.addEventListener('load', () => {
    const fontBtns = document.querySelectorAll('.js-font-btn');
    fontBtns.forEach((btn) => {
        const btnVal = btn.value;
        const btnTag = btn;
        if (btnVal == localStorage.getItem('font-size')) {
            btnTag.classList.add('active');
    }
    });   
})

I know that's a big chunk of JavaScript code, but it basically only does a few things:

• it collects and checks if localStorage is supported

• then it saves the data in localStorage

Also notice that I used Javascript Classes, but you could use functions as well.

Checking for local storage

A lot of browsers support localStorage these days, but why do we still need to check?

Some users may be browsing your site in incognito mode (private browsing mode). And sometimes localStorage is turned off by default so it doesn't save anything on the users device.

So instead of saving it directly and sometimes getting an error on browsers that don't support it, we can check if the browser does support it. If it does, great – and if it doesn't then we're also cool.

Now if you notice, everything seems to work just fine. But if you change the theme or font size and you reload your browser, everything is going to revert to default. This is because we haven't used the data we stored in localStorage

So go ahead and add this piece of code to the top of your head file before any CSS files. We're doing this to eliminate the flash you get when you reload your browser.

<script>
    const scheme = localStorage.getItem('theme-name');
      document.documentElement.setAttribute('data-theme', scheme);

      const fontSize = localStorage.getItem('font-size');
    document.documentElement.style.setProperty('--font-size',  `${fontSize}px`);


    const position = localStorage.getItem('position');
    if (position == 'fixed') {
        document.documentElement.style.setProperty('--position', 'fixed');
        document.documentElement.style.setProperty('--top-margin', '96px');

    } else {
        document.documentElement.style.setProperty('--position', 'static');
        document.documentElement.style.setProperty('--top-margin', '0px');

    }    

  </script>

Wrapping up

And that's it! You now have a simple and customizable static site.

The main purpose of this guide was to show you the endless possibilities of creating a user-customizable website. So go ahead and play around with it – there are a lot of things you can do, like:

1. Show users specific content based on their choices

2. Display notification messages based on user's visits

3. Display ads in the least annoying way by showing users ads based on user choices

You can do these things and a lot more with our SSG's. Just imagine the endless possibilities.

Not much of a tutorial person? You can copy the complete source code here.

I wanted to test my limits as a young designer by improving the user experience of Clubhouse, the hottest new audio conversation app on the social media scene.

After speaking with both power users and novices on the app, I uncovered some specific pain points with wayfinding and discoverability in the app. These became the primary design challenges that guided my work throughout this project.

Onboarding Mockups

Disclaimer: I do not work for Clubhouse, and the views in this case study are strictly my own.

As a budding designer, I acknowledge that my vision for this project may be overly ambitious and at times reliant on assumptions of business goals and user data.

In a perfect world, I’d be working alongside the Clubhouse team with direct access to these resources to guide my work. Until then, this case study is meant to be an exploratory learning experience on a product I deeply admire.

The Brief

It’s difficult to understate the excitement around Clubhouse, the audio chat app where members can move around virtual rooms discussing topics ranging from culture to politics.

The app raised its first $100 million with only 1,500 users a month after its beta release. And at the time of this writing, Silicon Valley’s buzziest app has just been valued at $1 billion dollars, a mere 9 months after taking off and before even launching to the public.

Beyond its success with investors, Clubhouse has amassed a fiercely loyal user base, whose creativity has spanned from a 24-hour continuous room dedicated to new user onboarding to a live production of The Lion King.

As an early beta user on the invite-only platform, I had the unique perspective of following the product’s updates (and exponential success) in real-time. And I sought to challenge myself with my most ambitious project yet: redesigning Silicon Valley’s most exciting app in recent memory. No pressure.

The high-level goals of this project were:

• Improving discoverability within Clubhouse, allowing users to more easily find new rooms, people, and clubs to engage with
• Creating a more seamless Hallway experience, where users can filter and find the most relevant rooms to them

UX Challenges: Simplifying a complex information hierarchy

One of the main considerations I had to take into account was the hierarchy of the main components users can interact with inside the app:

• People (other users of the app)
• Rooms (a virtual meeting place for audio conversations), and
• Clubs (interest-based groups that rooms can be hosted under).

Beyond this, I had to consider how each of these components were connected, both interpersonally and through time.

Currently, a Clubhouse user’s Hallway (home screen) shows live rooms connected to the people and clubs they follow (which I’ll refer to throughout this case study as “in-network”). This makes it difficult for users to easily keep track of upcoming rooms in their network, as well as join new, out-of-network rooms.

This became a major dichotomy throughout my work: I needed to find a balance between making each of these individual parts of Clubhouse easily discoverable while maintaining – and simplifying – the web that weaves them together.

Discovery task flow

Mind map of the relationship between Clubhouse components

Research + Planning: A UX Researcher’s Dream

Another unique aspect of this project was the direct access beta users have to the Clubhouse founders, Paul Davison and Rohan Seth. Every Sunday, the pair host Clubhouse Townhall, an open forum where they share the week’s latest product updates, their upcoming roadmap, business goals, and top priorities, as well as holding space for user-submitted Q&As.

And thanks to Clubhouse’s enthusiastic user base, the official Townhalls are regularly followed by Townhall recap rooms (shoutout to Community Club), where power users would deep dive into the week’s updates and what features they’re most excited for.

Between Clubhouse Townhalls, recap rooms, and both official and community-run new member onboarding rooms (including FAQs, Q&As, and discussions), I spent on average 5 hours a week for 6 weeks gaining as many business insights and goals as I possibly could from my limited vantage point.

A compilation of some of the rooms that became a regular part of my UX Research

From these discussions, the overarching goals of the Clubhouse team are:

• Making Clubhouse accessible for everyone: Paul always made it clear that the team’s top priority was to scale Clubhouse as quickly as possible while not sacrificing quality
• Putting creators first: another point Paul never understated was the team’s prioritization of the platform’s creators, building tools that would allow for creator monetization
• Improving discoverability and suggested content: at the time of this project, Clubhouse was actively building out their topics directory and algorithms that would make finding relevant rooms progressively easier

Early sketches of how different screens might behave

User Interviews, from power users to newbies

I spoke with Clubhouse users — both power users and more casual community members — to uncover friction points they currently had with the app’s discovery experience. These interviews showed gave me the following insights:

• Keep it lightweight: most users preferred room discovery to be a spontaneous experience, not necessarily wanting to schedule upcoming rooms in their personal calendars
• Cluttered Hallway: most users were confused by how the hallway was currently curated, and who of the people they followed were in any given room present
• Hallway as a source of discovery: despite the cluttered hallway experience, most users still relied on the hallway to find new rooms, despite there being an existing (but not yet robust) “Explore” tab
• Friends first: when deciding which rooms to join in the hallway, users unanimously wanted to see which of their friends were in any given room

Affinity map of my user interviews (made using Evolve)

So how might we make the Hallway a clear and concise place for spontaneous interaction, while facilitating lightweight out-of-network discovery?

UX Solution: Streamlining the Discovery-to-Hallway pipeline

I developed a simple yet powerful UI that makes wayfinding within your hallway and rooms easier. It also makes bringing rooms found through the discover page into your hallway a breeze.

In order for this solution to feel cohesive and not siloed, I needed to implement a near-full redesign of Clubhouse, broken up into 5 main experiences.

Play with the final prototype here.

Early Wireframes

Experience 1: The Hallway

The Clubhouse Hallway currently (left), and reoptimized for more functionalities and access to controls (right)

Users wanted their hallway experience to feel more intentional and within their control. To achieve this, I established a top-level hierarchy of:

• ongoing vs. upcoming, to allow users to not only see active rooms but get a quick overview of scheduled rooms within their network
• filters by topics of interest, selected by the user during onboarding, and
• sort rooms in your hallway by people vs clubs you follow

An additional UI decision was to only present people you follow within the rooms in your hallway. This would alleviate the current issue of ambiguity surrounding the names users currently see in the room cards in their hallways.

Navigating the reimagined Hallway

Experience 2: Room preview

Room preview in action, where users can see a full list of which friends are inside any given room

Currently in Clubhouse, clicking on a room in a hallway immediately drops you into that room’s conversation.

Since identifying friends in any given room was a high decision factor for users joining a room, I wanted to design a way for users to see whom they know inside before committing to join.

Experience 3: Discovery

Clubhouse’s Explore tab currently (left), and redesigned as an immersive discovery experience (right)

Currently, discovery in Clubhouse is siphoned: users go to the Explore tab to discover people and clubs by categories and keywords, and they go to the calendar tab to discover both active and upcoming rooms across all of Clubhouse.

Bringing a room to your hallway via Clubhouse’s Calendar tab currently (left), and reimagined as a simple bottom sheet function (right)

Most participants actually didn’t use these tabs to achieve their primary goal of discovery. Instead, they adopted workarounds such as discovering clubs through user profiles, discovering people through rooms, and discovering rooms primarily through their hallway, limiting the scope of content they were being exposed to.

An immersive discovery experience with rich filter and sort options

While I designed UI solutions to make these workarounds more seamless, I wanted the discover page to be the go-to destination to accommodate for all these use cases, allowing users to search for people, clubs, and rooms by Clubhouse’s growing topics directory, in addition to keywords.

I also integrated an additional sort functionality to further facilitate discovery.

Sending an out-of-network room to your Hallway

Users also wanted an easy, lightweight solution to discover and access out-of-network rooms.

The ability to send a room from the discover feed to your hallway without committing to following that room’s moderators, corresponding club, or scheduling in your personal calendar was the biggest challenge of this project, involving many iterations in order to feel intuitive.

Experience 4: Active Users

Clubhouse “Available to Chat” flyout currently (left), and reimagined as an “Online Now” tab (right)

A close cousin to the hallway, your active users screen is where all your Clubhouse people and clubs that are currently online live. 83% of users interviewed mentioned scanning this screen to quickly identify what rooms their friends were in.

I added a much-requested search bar to further facilitate friend-finding, as well as a sort drop-down menu to reach an even more important distinction: who’s actively participating in a room vs. just listening in.

Discovering active users by different sort options

Experience 5: User and Club Profiles

Clubhouse User Profiles currently (left), and after consolidating clubs as one metric (right)

87% of users discover suitable clubs to follow via user profiles directly. There exists a further hierarchy within clubs: followers (who receive notifications and see club-branded rooms in their hallway), and members (who, in addition to the above, can also start club-branded rooms themselves).

In Clubhouse’s current design, the clubs a user follows vs. clubs a user is a member of are in disparate locations: in the user’s following list and at the bottom of their user profile, respectively. This was confusing to users wanting scan all the clubs associated with a particular person.

Navigating both User and Club Profiles

By making clubs associated with a user a consolidated metric, users visiting that profile can more easily see what clubs that person belongs to, and immediately follow without visiting a new screen.

On the club level, being able to access metadata such as previously held rooms, upcoming rooms, and club admins can help a user get a more effective overview of the club.

UI & Branding: A Case for Dark UI

In bringing all the pieces of this experience together, it became clear that adding too many visual elements would disrupt the visual hierarchy needed to move through the app with ease.

Additionally, the typical user experience on Clubhouse is already so immersive and emotive, often spanning all hours of the night — I wanted to take advantage of this use case and implement an elegant UI that emphasized Clubhouse’s few content types harmoniously.

A snippet of the Style Guide that guided my work

Usability Testing: How effectively is findability and discoverability throughout the app?

After conducting my usability tests, I created an affinity map with insights, behaviors, and findings during the tests.

Most users moved through the app with little to no missteps, but for many participants, there was one main point of friction that disrupted a key pillar of this redesign:

It was still unclear how to access a room you saved from the Discovery page to your Hallway.

Usability Testing Insights & Priority Changes

Initially, I designed for upcoming out-of-network rooms found in the discover tab to appear in the hallway by the user starring the room. These would then appear in your hallway algorithmically, further discoverable via the “sort by” drop-down menu. There were a few problems with this:

• The original design essentially treated these rooms as saved items, which inadvertently (and incorrectly) prioritized these rooms over other rooms found in your hallway
• This treatment could have greater implications of disincentivizing spontaneous room creation, or unfairly prioritizing out-of-network rooms in general
• Beyond this, embedding a saved item in a sort drop-down wasn’t intuitive or an expected place to find this type of content

Setting notifications on the room, club, and user level

Conclusion: Lessons learned & where we go from here

Going into this project, I knew this would be an ambitious challenge for a young designer. What I didn’t know was just how intricate and all-encompassing that challenge would be.

I learned that working on a highly publicized and highly beloved product comes with a lot of external pressure and internal emotions to do right by (seemingly) everyone.

There are the power users with fierce attachment to existing structures, and new users who can’t fully experience the nuance of an audio app as a static prototype.

Then there's the small but mighty Clubhouse team, who are actively iterating their product on a weekly basis, potentially launching imaginative solutions themselves for the same challenges I’m working on. And even others I haven’t imagined yet.

Against a constant stream of public conversation over an exciting product that felt almost ethereal, I’ll humbly admit that there were times where this pressure got the best of me and I felt like a total imposter who bit off way more than she could ever chew.

The biggest lessons this project taught me were the delicate balance between perseverance when faced with complex challenges, grace in the wake of perceived failure, and when to be okay with “good enough” (for this iteration, of course).

In the end, I’m extremely proud of what I was able to accomplish with this project at this stage in my design journey. And I often reminded myself of my favorite mantra that led me to product design in the first place:

“All I wanted was a job like a book so good I’d be finishing it for the rest of my life.”

Product design is that job for me, and I’m proud to say that while this project (and all my others) will never be fully finished, I breathed as much life into it as I could — I hope you enjoyed it!