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/.

‌

‌

‌

People will also abandon a site when they don’t understand an error message, can’t navigate through fields easily, or can’t get the help they need right away.

This guide will show you how to create automated systems that detect these issues before your users do. Together, we'll write code that systematically checks your forms so you don’t have to go through each field by hand in the hopes of finding problems.

Here's what we'll build together:

• Scripts that confirm your error messages are helpful and specific rather than generic and annoying.

• Automated checks that guarantee the hint text appears in the appropriate location and at the appropriate time.

• Tests to ensure keyboard users can navigate your forms without becoming lost or stuck.

• A comprehensive audit system that performs these checks automatically and provides you with a list of fixes ranked in order of priority.

• Integration with your development process so that each time you make a code change, these checks are performed.

By the end of this handbook, you'll know how to:

• Configure automated audits for any application form.

• Verify error messages against accessibility guidelines and usability best practices.

• Make sure the hint text aids users rather than confounds them.

• Verify that all users can finish your forms by testing the keyboard navigation.

• Link audit findings to actual business metrics, such as conversion rates.

• As part of your deployment procedure, run these audits automatically.

You can run the functional JavaScript code in each section right away. Because the examples use vanilla JavaScript, they can be used with any framework, including React, Vue, Angular, or simply HTML. Although you don't have to be an expert, you should be able to follow along with JavaScript to get this most out of this guide.

Table of Contents

1. Why Should You Automate Form Audits in the First Place?

2. How to Define Concise Objectives and Scope

3. How to Scope Audit Boundaries

4. How to Incorporate Heuristic Evaluation and Quantitative Data

5. How to Define Automated Test Cases for Form Components

6. How to Consistently Confirm Keyboard Navigation Flows

7. AI-Informed Navigation Pattern Detection

8. Conclusion

Why Should You Automate Form Audits in the First Place?

Manual testing will typically find easy problems. But it may miss the systematic issues with forms across your entire application. You know the type of errors I’m talking about – those that don’t state incorrect values, missing keyboard support for fields, or hints that don’t have a clear place for help based on static design.

Research on user experience design shows that an effective UX can be strategically built, refined, or designed by using continuous feedback loops (Source: Okonkwo, Research Gate). Automated audits are a good way of putting this into practice, as they can help you find issues at scale before you release your product.

The key advantage here is coverage. You can prepare form UX audit basics so you and your teammates can check every form field, validation rule, and keyboard interaction in a systematic way.

Key Form Components to Audit

Before we create our roadmap for the UX audit, let’s talk about the three main elements of forms that typically have issues:

• Error states indicate what went wrong, as well as how to fix it. The clearer they are, the better: the confusion of generic messages like "Invalid input" frustrates users. In contrast, specific feedback like "Email must contain @ symbol" is specific enough to help them get things completed.

• Hint text helps prevent errors before users can input anything. Proactive guidance like "Password must contain 8+ characters" provides realistic expectations. Placing hint text in the right location and conveying its message at the appropriate time also determines how useful the hint text will be.

• Keyboard flows distinguish accessible forms from broken forms. Tab order, focus order, and keyboard shortcuts dictate whether a user can complete their form without a mouse.

To guide you through the audit workflow for each component, we’ll focus on three user flows: a sign-up form, checkout, and a contact form. All of these affect the conversion rate of a product’s users. And each of these elements maps to multiple metrics you can track.

We’ll use Nielsen Norman Group's 10 usability heuristics (Source: Jakob Nielsen, NNgroup) as a foundation while incorporating any data indicators. These heuristics are:

• System status visibility: Users should always be aware of what's going on thanks to prompt feedback

• System and real-world match: Use the user's language instead of technical terms

• User freedom and control: Enable users to quickly correct errors

• Consistency and standards: Adhere to platform norms so users don't have to question whether various terms or behaviors have the same meaning.

• Error prevention: Design to stop issues before they start

• Recognition rather than recall: Show options rather than making users memorize details.

• Flexibility and efficiency of use: Provide shortcuts for experienced users while keeping things simple for beginners.

• Aesthetic and minimalist design: Don't clutter interfaces with irrelevant information.

• Help users recognize, diagnose, and recover from errors: Error messages should clearly explain the problem and suggest a solution.

• Help and documentation: Provide easy-to-search help when needed.

For form audits, we'll focus especially on heuristics #5 (error prevention through hint text), #6 (making requirements visible), and #9 (clear error recovery). These directly affect whether users can complete forms successfully.

There’s one more important thing to note before we proceed. For each component, you’ll want to identify what tests you can automate as part of your test case. For each form component, start building checks programmatically for several criteria:

• Accessibility – for contrast ratios, ARIA labels, and focus indicators.

• Performance – for the time it takes to validate fields and render error messages.

• Visual consistency – for error state styling, hint text patterns, and keyboard focus.

We’ll prioritize fixes with a high impact that will help prevent users from abandoning a form. Also, each audit will produce actionable information along with a line of code, acceptance criteria, and example code for fixes.

Now, let’s start building our form UX audit workflow.

How to Define Concise Objectives and Scope

Before you even put your fingers to the keyboard, you'll want to determine what exactly you’re measuring and for what purpose. There’s a golden rule: ambiguous statements will yield ambiguous results. Having specific objectives linked to user behavior and business metrics is what creates actionable audits.

Identifying Form Types and Objectives

First, you need to know what form you’re going to audit. Let’s start by mapping the three forms that have the greatest direct impact on the success of your application and defining the nuances and objectives of each one.

1. A signup form’s key goal is user acquisition.

Every friction point - like poorly defined password requirements, vague expectations for email formats, and a lack of field labels - means a user will likely abandon the signup process. Your audit must identify these user flows.

2. Checkout forms are aimed at bringing revenue

User engagement improves significantly when applications use user-centered design principles – shocking, right? (Source: Okonkwo, ResearchGate). In checkout flows, this means that error messages appear inline, hints show requirements before a user can type, and keyboard navigation follows the expected tab order from shipping to payment fields.

3. Contact forms have the objective of establishing communication

Often, devs pay less attention to contact forms than to transactional forms. But contact forms are crucial for proposal requests, customer support requests, collaboration requests, and so on. A broken contact form can mean lost business.

Now that you’ve identified the type of form and its key objective, let’s do something equally important: link these high-level objectives to specific, measurable metrics.

Connecting Objectives and Metrics to Track

Every objective for the audit maps to a set of measurements. Here’s how to build this continuum:

Error message metrics

Your audit should evaluate whether error messages fulfill three criteria:

1. Specificity (Does the message indicate what the problem is?),

2. Timing (In what context will the user see the error?), and

3. Actionable (Does the message explain what the user should do to recover?).

For example, "password too weak" does not provide actionable information and isn’t specific enough, while "Password must have at least one uppercase character, one number, and one special character" is highly actionable and provides clear information on what the user needs to do.

You can measure this by tracking two things: what percentage of your error messages mention the specific field name, and how many errors show up immediately when users leave a field versus only appearing after they hit submit.

Hints can reduce user errors before they occur. Your audit should validate:

• Whether a hint’s positioning is proactive (for instance, is the hint text located before users engage the provided input field?).

• Visual proximity (Is the hint text next to the input field?).

• Accessibility (for example, are the hints connected to the fields programmatically using aria-describedby?)

The latter is especially important, as screen readers require explicit connections to announce hints at the correct time. You’ll want to measure these using metrics like the time to display a hint (immediate vs delayed) and the number of ARIA-associated hint elements.

Keyboard flow metrics are also directly connected to accessibility

Your audit should define if there is a correct order logic. Do fields follow the visual layout? When the tabindex jumps around sporadically across the screen, users lose context.

It should also determine if the focus visibility is the current field and if that’s clearly indicated. When the focus is invisible or subtle, you end up making your users guess where they are.

Keyboard shortcuts let users submit forms, clear fields, or jump between sections without touching their mouse. Everyone benefits from this, not just people using screen readers or other assistive technology.

You will want to measure these with the tabindex sequence alignment to the visual layout, focus indicator contrast ratios, and by defining if there are keyboard shortcuts for submitting, clearing, and moving about the forms.

Now that you have outlined the key metrics and principles applicable to the form you’re auditing, it’s time to define the specific area you want to focus on.

How to Scope Audit Boundaries

You’ll need to define exactly what forms and fields your audit will cover. You’ll want to start small in order to build working automations and then slowly expand.

Setting the Initial Scope

You should start with forms in your application’s critical user paths. We’ll use the below JavaScript snippet as an example. Paste this configuration object into your audit automation tool or script:

const auditScope = {
  signupForm: {
    url: '/signup',
    fields: ['email', 'password', 'confirmPassword'],
    priority: 'critical'
  },
  checkoutForm: {
    url: '/checkout',
    fields: ['cardNumber', 'expiryDate', 'cvv', 'billingZip'],
    priority: 'critical'
  },
  contactForm: {
    url: '/contact',
    fields: ['name', 'email', 'subject', 'message'],
    priority: 'high'
  }
};

In the code above, the auditScope object lists critical forms (signup, checkout, and contact forms), specifies their URLs along with important fields to check (such as email, password, cardNumber), and lists their priority level. This helps the auditing system see what resources to prioritize.

The priority property allows your audit system to prioritize high-impact forms first when protocol limits the resources available. Such a method prevents your system from being overwhelmed with too broad a scope.

Setting the Audit Execution Plan

Your objectives dictate how the audit system will act. After you have defined the scope, you can divide the workflow into several definite phases.

• Phase 1: Static analysis will address the structure of the HTML document and verify the ARIA attributes, tab indices, and markup patterns for semantic use. This can discover structural issues that require no user interaction.

• Phase 2: Dynamic testing simulates user interactions to identify the occurrence of errors, when hints are displayed, and when a keyboard user would navigate to which elements. This can identify runtime problems that were not revealed through static analysis.

• Phase 3: Visual verification measures spacing, contrast ratios, or positioning of elements, but using visually computed styles. This allows us to examine the visual design in relation to meeting either UX or UI objectives.

Each phase will result in findings that continually tie back to your defined objectives. In the case of a failed check, the audit report will show which objective contributed to the finding, the current state of the component, the target states, and recommendations for the solution.

Field-level objectives

For each field, you should tell the script or the automated tool what the audit is actually checking. Each check is a specific automated test. When the audit is executed, every check is confirmed for every field, and failures are noted.

For instance, in the following snippet, for each field we provide (like "email" or "password"), we list three categories of checks: errorChecks, hintChecks, and keyboardChecks. When you link this object to your audit automation system (for example, UI testing frameworks, accessibility checkers), your audit automation system runs all these tests on every field. It will report any test failures so you can see which part of the input is broken or missing.

const fieldObjectives = {
  email: {
    errorChecks: [
      'hasInlineValidation',
      'errorMessageSpecific',
      'showsValidFormatExample'
    ],
    hintChecks: [
      'hintVisibleBeforeInteraction',
      'hintExplainsFormat',
      'hintAccessible'
    ],
    keyboardChecks: [
      'tabOrderCorrect',
      'focusVisible',
      'supportsAutocomplete'
    ]
  },
  password: {
    errorChecks: [
      'hasInlineValidation',
      'listsAllRequirements',
      'showsProgressIndicator'
    ],
    hintChecks: [
      'hintListsRequirements',
      'hintVisibleBeforeTyping',
      'hintPersistsDuringTyping'
    ],
    keyboardChecks: [
      'tabOrderCorrect',
      'focusVisible',
      'supportsPasswordManagers'
    ]
  }
};

This leads to a very granular, consistent, and repeatable test of important user input components so you can validate usability, accessibility, and correctness of the form.

Linking Objectives to Business KPIs

The findings of the audit should link back to business impact. Let’s look at how our objectives map to key performance indicators.

The impact on conversion rate should be direct and specific. For instance, improved error messages directly impact the form completion rate:

• Baseline. The current abandonment rate for forms.

• Target. Decrease abandonment by 15% due to clear error messages.

• Audit validation. 100% of error messages are clear and specific.

Reducing support tickets is another priority. In this case, better hint text provides less confusion:

• Baseline. Volume of support requests related to forms currently.

• Target. Decrease the number of support tickets by 25%.

• Audit validation. 100% of complex fields have proactive hints.

Accessibility compliance is another important goal. Keyboard navigation has a direct impact on the legal compliance and reach of a wider base of users. The example of the KPIs here can be the following:

• Baseline. Current level of WCAG conformance.

• Target. All forms to be WCAG 2.1 AA compliant.

• Audit validation. 100% of fields work with a keyboard only.

After you create such measurable criteria for success, you should actually give them as thresholds to your system. Here’s an example of how you can provide defined measures for passing and failing for the automated audit:

const auditThresholds = {
  errorMessages: {
    specificityScore: 0.9,  // 90% must include field-specific details
    inlineValidationPercentage: 1.0,  // 100% must show inline errors
    actionabilityScore: 0.85  // 85% must include fix instructions
  },
  hintText: {
    proactiveDisplayPercentage: 1.0,  // 100% must appear before interaction
    proximityMaxPixels: 8,  // Hints must be within 8px of fields
    ariaAssociationPercentage: 1.0  // 100% must have aria-describedby
  },
  keyboardFlow: {
    tabOrderCorrectnessScore: 1.0,  // 100% must follow visual layout
    focusContrastRatio: 3.0,  // Minimum 3:1 contrast for focus indicators
    shortcutCoveragePercentage: 0.8  // 80% of actions must have shortcuts
  }
};

As you can see, under errorMessages, the specificityScore of 0.9 states that 90% of error messages must include details specific to each field. Also, within the hintText directions, the proactiveDisplayPercentage of 1.0 demands that the hints appear before the user starts typing, not after, for the test to be passed.

The 5Cs Framework for Audit Documentation

When you document your audit results, use the 5Cs framework to make sure your reports are actually useful:

• Coverage: Which forms and fields did you test? Be specific about the scope.

• Completion: Did you run all the planned checks? Note any that were skipped and why.

• Consistency: Do your results use the same format and terminology throughout? This makes reports easier to scan.

• Clarity: Can a developer read the failure report and know exactly what to fix? Include the current state, expected state, and code examples.

• Correctness: Are your checks testing the right things? Validate that failures match real user problems, not just technical violations.

This framework helps both designers and developers understand audit results and take action quickly.

How to Incorporate Heuristic Evaluation and Quantitative Data

Once you've established objectives, you’ll want to base your audit on the usability principles and behavior patterns of users. This combination of established usability heuristics along with quantitative data can help you verify that your automated checks are surfacing issues that users actually experience – and not fictional edge cases (Source: Jakob Nielsen, NNgroup).

The best way to do this is to map the issues to the common standard of the Web Content Accessibility Guidelines and use that as the basis for your audit (Source: WCAG 2.1, W3C Recommendation). For every identified problem, identify the WCAG success criteria that the issue violates. This will give you clear requirements that you can use as an automated check and that should be commonly understood by everyone working on the audits.

In the automated script, you can use the following code to map these guidelines:

const wcagMapping = {
  errorIdentification: {
    criterion: '3.3.1',
    level: 'A',
    requirement: 'Error messages must identify the item in error',
    testFunction: 'checkErrorIdentification'
  },
  errorSuggestion: {
    criterion: '3.3.3',
    level: 'AA',
    requirement: 'Error messages must provide suggestions for correction',
    testFunction: 'checkErrorSuggestions'
  },
  labelInName: {
    criterion: '2.5.3',
    level: 'A',
    requirement: 'Accessible name must contain visible label text',
    testFunction: 'checkLabelInName'
  },
  focusOrder: {
    criterion: '2.4.3',
    level: 'A',
    requirement: 'Focus order must preserve meaning and operability',
    testFunction: 'checkFocusOrder'
  }
};

If any part of the form violates WCAG 3.3.1 – perhaps it doesn’t identify the field when it provides an error – your audit report can document it as follows:

"The error message displayed on the email field said 'Invalid input' but didn’t identify the requirement it didn't meet. WCAG 3.3.1 states that the error must identify the field with the error (potential fix: 'Email must have an @ symbol'). 3.3.1 is the mapped criteria."

Nielsen's heuristics tell you what good usability looks like. But tools like Google Analytics and Hotjar show you what users actually do on your forms. When you combine both – usability principles and real user behavior data – you make better decisions about which problems to fix first.

Research shows this combined approach catches more real issues than either method alone (Sources: Souza and others, IEEE Access). Use both types of data to prioritize what your automated audits should check.

Define Binary Pass/Fail Criteria

Automation requires clear results. Your audit must document whether a component passed or failed its WCAG criteria. The process must yield binary results – yes/no, positive/negative.

For instance, the following code incorporates a definite, binary audit check to verify whether a form field is compliant with WCAG 3.3.1 criteria for error identification (Source: WCAG 2.1, W3C Recommendation):

function checkErrorIdentification(field) {
  const errorElement = field.querySelector('[role="alert"], .error-message');
  
  if (!errorElement) {
    return {
      pass: false,
      wcag: '3.3.1',
      severity: 'critical',
      message: `Field "${field.name}" lacks error message element`,
      fix: 'Add aria-describedby pointing to error container'
    };
  }
  
  const errorText = errorElement.textContent.trim();
  const hasFieldReference = errorText.toLowerCase().includes(field.name.toLowerCase()) 
    || errorText.toLowerCase().includes(field.labels[0]?.textContent.toLowerCase());
  
  if (!hasFieldReference) {
    return {
      pass: false,
      wcag: '3.3.1',
      severity: 'major',
      message: `Error message "${errorText}" doesn't identify field`,
      fix: `Include field name in error: "\({field.labels[0]?.textContent} \){errorText}"`
    };
  }
  
  return { pass: true, wcag: '3.3.1' };
}

The error message identified the error, and each component definitively passes or fails the criterion. There’s no room for interpretation or doubt.

Standardize Error Messages and Hint Messages

Keep in mind that automated functions require familiarity and consistency. You can create centralized repositories with libraries of accepted usage patterns and approval that developers can refer to, and your tests can check that your forms are using standardized messages.

For example, in the following snippet, the errorLibrary object provides a single source of truth for every acceptable error message your application will display for specific fields. For each field, there are appropriately defined message strings for common validation issues (like empty, invalid, duplicate). Similarly, the hintLibrary object provides a single source of truth for every hint text that prefaces user input.

const errorLibrary = {
  email: {
    empty: 'Email address is required',
    invalid: 'Email must include @ symbol and domain (example: user@domain.com)',
    duplicate: 'This email is already registered. Try signing in instead.'
  },
  password: {
    empty: 'Password is required',
    tooShort: 'Password must be at least 8 characters',
    missingUppercase: 'Password must include at least one uppercase letter',
    missingNumber: 'Password must include at least one number',
    missingSpecial: 'Password must include at least one special character (!@#$%^&*)'
  }
};

const hintLibrary = {
  email: 'Enter your email address (example: name@company.com)',
  password: 'Create a password with 8+ characters, including uppercase, number, and special character',
  phone: 'Enter 10-digit phone number without dashes (example: 5551234567)'
};

By having a single source of these patterns, you won’t run the risk of writing duplicate or misaligned messages in different areas across the app, increasing maintainability.

Utilize Definite ARIA Identifiers

If you use consistent ARIA attributes, you can automate checks. As an example, in the following snippet, we explicitly define which ARIA attributes connect error messages, hints, and fields. The auditARIAImplementation function checks whether each field has an accessible label (either an HTML element or an aria-label attribute) to meet WCAG 1.3.1. Without it, users will likely find it hard to identify the purpose of the input.

function auditARIAImplementation(field) {
  const checks = {
    hasLabel: !!field.labels?.length || !!field.getAttribute('aria-label'),
    hasDescription: !!field.getAttribute('aria-describedby'),
    hasErrorMessage: !!field.getAttribute('aria-errormessage'),
    hasRequired: field.hasAttribute('required') || field.getAttribute('aria-required') === 'true'
  };
  
  const failures = [];
  
  if (!checks.hasLabel) {
    failures.push({
      wcag: '1.3.1',
      message: `Field "${field.name}" lacks accessible label`,
      fix: 'Add <label> element or aria-label attribute'
    });
  }
  
  if (!checks.hasDescription) {
    failures.push({
      wcag: '3.3.2',
      message: `Field "${field.name}" lacks hint text association`,
      fix: 'Add aria-describedby pointing to hint element ID'
    });
  }
  
  if (field.dataset.validatable && !checks.hasErrorMessage) {
    failures.push({
      wcag: '3.3.1',
      message: `Validatable field "${field.name}" lacks aria-errormessage`,
      fix: 'Add aria-errormessage attribute pointing to error container ID'
    });
  }
  
  return {
    pass: failures.length === 0,
    failures
  };
}

This function checks for specific ARIA-tied patterns that your design system prescribes. The great thing is that you can check the code in CI/CD pipelines to maintain implementation standards.

The next section will help you identify specific automated test cases for errors, hints, and keyboard flows.

How to Define Automated Test Cases for Form Components

Now that you've established a baseline with WCAG standards, heuristics, and user data, you can create specific automated test cases. Each test case targets a measurable quality for the error messages, hint text, or keyboard navigation functionality of each form component. The following sections will provide concrete ways to automate these checks for each form component.

Automated Error Message Checks

Error messages are crucial conversion points. Your automated checks should ensure that each error message meets the specificity, timing, and actionability criteria. Every error message must convey what exactly has gone wrong. Generic error messages don’t pass this quality check.

For automation, your checks can provide insight as to whether the error message references the specific construction of the field. For instance, in the following snippet, the method verifies that every error message that appears in a form serves to pinpoint the input problem, not use a vague general expression.

function auditErrorSpecificity(formId) {
  const form = document.getElementById(formId);
  const fields = form.querySelectorAll('input, textarea, select');
  const failures = [];
  
  fields.forEach(field => {
    const errorElement = document.querySelector(`[aria-describedby="${field.id}-error"]`);
    if (errorElement) {
      const errorText = errorElement.textContent.toLowerCase();
      const genericTerms = ['invalid', 'error', 'wrong', 'incorrect'];
      const isGeneric = genericTerms.some(term => 
        errorText.includes(term) && errorText.split(' ').length < 4
      );
      
      if (isGeneric) {
        failures.push({
          field: field.id,
          message: errorText,
          issue: 'Generic error message lacks specificity',
          wcag: '3.3.1 Error Identification'
        });
      }
    }
  });
  
  return failures;
}

It looks through field-specific error messages and flags any that use common generic terms in a short, vague message, as ambiguous messages don’t serve the purposes of WCAG 3.3.1 since they don’t provide an actionable correction for user input (Source: WCAG 3.3.1, WC3).

Validation Timing of Inline Messages

Error messages should show the message when the user leaves the field and not just at submission. Research demonstrates that even just the timing of the feedback alone significantly disrupts user performance. Your automation should check whether errors are displayed inline (Source: Al-Khalifa and others, ResearchGate).

This code verifies that error messages appear immediately when a user leaves a required input field on blur, as opposed to only showing errors after submitting the entire form.

function auditErrorTiming(formId) {
  const form = document.getElementById(formId);
  const fields = form.querySelectorAll('input[required], textarea[required]');
  const failures = [];
  
  fields.forEach(field => {
    let hasBlurValidation = false;
    let hasInputValidation = false;
    
    // Check for blur event listeners
    const blurListeners = getEventListeners(field).blur || [];
    hasBlurValidation = blurListeners.length > 0;
    
    // Check for input event listeners
    const inputListeners = getEventListeners(field).input || [];
    hasInputValidation = inputListeners.length > 0;
    
    if (!hasBlurValidation && !hasInputValidation) {
      failures.push({
        field: field.id,
        issue: 'No inline validation detected',
        recommendation: 'Add blur or input event validation',
        wcag: '3.3.1 Error Identification'
      });
    }
  });
  
  return failures;
}

This audit verifies that an event handler which runs against an inline validator is in place for blur and input events on input fields. It also checks that it flags any that fail to have these interactions as a failure under the WCAG 3.3.1 Error Identification guideline (Source: WCAG 3.3.1, WC3).

Confirm Actionable Recovery Guidance

Error messages must clarify how to recover from any faults or issues. "Password too weak" fails the user. In contrast, the error message "Password must be 8+ characters, contain at least 1 upper case letter, and one numeric character" gives the user enough information to make the proper adjustment.

Let’s take an example of some code that audits password fields to ensure that the error message includes specific actionable recovery instructions outlining character types or character length and clearly guides users on how to correct input errors (Source: WCAG 3.3.3, WC3).

function auditErrorActionability(formId) {
  const form = document.getElementById(formId);
  const failures = [];
  const passwordFields = form.querySelectorAll('input[type="password"]');
  
  passwordFields.forEach(field => {
    const errorElement = document.getElementById(`${field.id}-error`);
    if (errorElement) {
      const errorText = errorElement.textContent;
      const hasSpecificRequirements = /\d+/.test(errorText) || 
        /uppercase|lowercase|special|character|digit/.test(errorText.toLowerCase());
      
      if (!hasSpecificRequirements) {
        failures.push({
          field: field.id,
          message: errorText,
          issue: 'Error lacks specific recovery guidance',
          wcag: '3.3.3 Error Suggestion'
        });
      }
    }
  });
  
  return failures;
}

If the error message doesn’t contain these characters or meet the length requirement, the function will flag the instance as a failure with a corresponding WCAG reference.

Automated Rich Hint Text Auditing

Rich text hints help prevent errors (and hopefully the need for an error message). Research suggests that users who are given proactive guidance improve form completion by up to 23% (Source: Okonkwo, ResearchGate). Your automation should confirm that the right hints appear at the right time, in the right places, with appropriate accessible information and presentation.

This function audits form fields to ensure that hint text is seen before the user interacts with the form, helping avoid user errors while filling out the form.

function auditHintTiming(formId) {
  const form = document.getElementById(formId);
  const complexFields = form.querySelectorAll('input[type="password"], input[pattern]');
  const failures = [];
  
  complexFields.forEach(field => {
    const hintElement = document.querySelector(`[id="${field.getAttribute('aria-describedby')}"]`);
    
    if (!hintElement) {
      failures.push({
        field: field.id,
        issue: 'Complex field missing proactive hint text',
        wcag: '3.3.2 Labels or Instructions'
      });
    } else {
      // Check if hint is visible before interaction
      const computedStyle = window.getComputedStyle(hintElement);
      const isVisible = computedStyle.display !== 'none' && 
        computedStyle.visibility !== 'hidden';
      
      if (!isVisible) {
        failures.push({
          field: field.id,
          issue: 'Hint text hidden until interaction',
          wcag: '3.3.2 Labels or Instructions'
        });
      }
    }
  });
  
  return failures;
}

If the hint doesn't exist or doesn’t show until after the user interacts with the form, the function will flag it as a failure to satisfy WCAG 3.3.2 Labels or Instructions for a generally consistent and user-friendly form design (Source: WCAG 3.3.3, WC3).

How to Consistently Confirm Keyboard Navigation Flows

Keyboard accessibility is required for WCAG compliance, and you can automate most of the testing with code. When people can't use your forms with just a keyboard, they often give up and leave. This directly hurts your conversion rates.

When you document how keyboard navigation should work, you can write automated tests to check if it actually works that way.

Outlining the Interactions

Your audit should document expected keyboard interactions for each component. If there's a modal dialog, note that Tab will cycle through the elements within the modal, Escape closes the modal, and the focus returns to the element that opened the modal.

For forms, note that Tab advances through the fields in visual order, Shift+Tab will go back, and Enter will submit the form from the submit button only.

You should document these flows in a data-driven way. A structured format with columns for "Component," "Keystroke," "Expected Action," and "Relevant WCAG" will make both human review and automated parsing much easier:

const keyboardPatterns = {
  'modal-dialog': {
    tab: 'Focus next element within modal',
    shiftTab: 'Focus previous element within modal',
    escape: 'Close modal and return focus',
    wcag: '2.1.1 Keyboard, 2.4.3 Focus Order'
  },
  'form-field': {
    tab: 'Move to next field in visual order',
    shiftTab: 'Move to previous field',
    enter: 'Submit only from submit button',
    wcag: '2.1.1 Keyboard, 2.4.3 Focus Order'
  },
  'dropdown-select': {
    space: 'Open dropdown menu',
    arrowDown: 'Navigate to next option',
    arrowUp: 'Navigate to previous option',
    enter: 'Select current option',
    escape: 'Close dropdown without selection',
    wcag: '2.1.1 Keyboard, 4.1.2 Name, Role, Value'
  }
};

This code aligns these patterns with WCAG guidelines 2.1.1 (Keyboard Accessibility), 2.4.3 (Focus Order), and 4.1.2 (Name, Role, Value) to support users who rely on keyboard inputs (Source: WCAG Understanding Docs, WC3).

Automated Tab Order Validation

Tab order should follow the visual layout of the page. When focus jumps around randomly, users get lost. The code below checks that focus moves through fields in the order people expect – top to bottom, left to right. It catches cases where focus skips around even when the tabindex values look correct.

function auditTabOrder(formId) {
  const form = document.getElementById(formId);
  const focusableElements = form.querySelectorAll(
    'input, select, textarea, button, a[href], [tabindex]:not([tabindex="-1"])'
  );
  const failures = [];
  
  const elements = Array.from(focusableElements).map(el => ({
    element: el,
    position: el.getBoundingClientRect(),
    tabindex: parseInt(el.getAttribute('tabindex')) || 0
  }));
  
  for (let i = 1; i < elements.length; i++) {
    const prev = elements[i - 1];
    const curr = elements[i];
    
    // Check if tab order follows visual top-to-bottom, left-to-right
    const visuallyBefore = prev.position.top < curr.position.top || 
      (prev.position.top === curr.position.top && prev.position.left < curr.position.left);
    
    if (!visuallyBefore && prev.tabindex === curr.tabindex) {
      failures.push({
        field: curr.element.id,
        issue: 'Tab order does not match visual layout',
        wcag: '2.4.3 Focus Order'
      });
    }
  }
  
  return failures;
}

In essence, the audit identifies failures to adhere to WCAG 2.4.3 Focus Order while preserving context and the ability to interact with keyboard users as they interact with form fields (Source: WCAG 2.4.3, WC3).

Verify Focus Visibility

Focus indicators need to be clearly identifiable. According to research, visible focus indicators improved typing and reduced errors significantly (Source: Liu and others, ResearchGate).

For instance, focus styles can include an outline, border, or shadow, but they must have enough contrast against the background (at least 3:1) to satisfy WCAG 2.4.7 Focus Visible and 1.4.11 Non-text Contrast (Source: WCAG Understanding Docs, WC3). Consider the following example:

function auditFocusVisibility(formId) {
  const form = document.getElementById(formId);
  const focusableElements = form.querySelectorAll('input, select, textarea, button');
  const failures = [];
  
  focusableElements.forEach(element => {
    element.focus();
    const computedStyle = window.getComputedStyle(element);
    
    // Check for visible focus indicator
    const hasOutline = computedStyle.outline !== 'none' && 
      computedStyle.outlineWidth !== '0px';
    const hasBorder = computedStyle.borderStyle !== 'none';
    const hasBoxShadow = computedStyle.boxShadow !== 'none';
    
    // Check contrast ratio for focus indicator
    const outlineColor = computedStyle.outlineColor;
    const backgroundColor = computedStyle.backgroundColor;
    const contrastRatio = calculateContrastRatio(outlineColor, backgroundColor);
    
    if (!hasOutline && !hasBorder && !hasBoxShadow) {
      failures.push({
        field: element.id,
        issue: 'No visible focus indicator',
        wcag: '2.4.7 Focus Visible'
      });
    } else if (contrastRatio < 3) {
      failures.push({
        field: element.id,
        contrastRatio: contrastRatio.toFixed(2),
        issue: 'Focus indicator contrast ratio below 3:1',
        wcag: '1.4.11 Non-text Contrast'
      });
    }
  });
  
  return failures;
}

Good focus styling helps keyboard users see where they are on the page. This code checks that focus indicators are visible and have enough contrast against the background so users can tell which field they're currently in.

Using Automated Testing Tools

To speed up and automate audits even more efficiently, you can use tools such as Google Lighthouse, axe-core, and Cypress. You can also combine these tools to be even more powerful – for example, using axe-core in conjunction with Cypress is the most comprehensive test suite I can suggest.

Here is a workflow you can follow:

async function runAccessibilityAudit(formId) {
  const form = document.getElementById(formId);
  const results = await axe.run(form, {
    rules: {
      'label': { enabled: true },
      'aria-required-attr': { enabled: true },
      'aria-valid-attr-value': { enabled: true },
      'keyboard-navigation': { enabled: true },
      'focus-order-semantics': { enabled: true }
    }
  });
  
  const violations = results.violations.map(violation => ({
    rule: violation.id,
    impact: violation.impact,
    description: violation.description,
    wcag: violation.tags.filter(tag => tag.startsWith('wcag')),
    elements: violation.nodes.map(node => node.target)
  }));
  
  return violations;
}

When you document keyboard patterns and automate the checks, you make sure everyone can complete your forms – whether they use a mouse, keyboard, or screen reader. Run these checks in your CI/CD pipeline to catch problems before they go live.

AI-Informed Navigation Pattern Detection

Machine learning models can help identify strange keyboard navigation sequences that signal potential usability challenges. Combining mouse tracking with artificial intelligence can give you insights into user behavior that aren't possible using traditional strategies (Sources: Souza and others, IEEE Access).

The logic could similarly be applied to keyboard navigation studies, as AI models can be trained on typical successful navigation patterns to signal when users are struggling in their keyboard flows.

Pattern Detection for Navigation Using AI

AI tools can assess keyboard navigation to find non-compliant actions during testing. For instance, through machine learning, the code sample below captures, evaluates, and categorizes unusual or problematic keyboard navigation behavior on web forms and detects unique keyboard navigation or k-action sequences that are likely indicative of usability concerns.

async function detectNavigationAnomalies(formId) {
  const navigationData = captureKeyboardSequence(formId);
  const features = extractNavigationFeatures(navigationData);
  
  // Use machine learning to classify navigation patterns
  const model = await loadTrainedModel('keyboard-anomaly-detection');
  const predictions = await model.predict(features);
  
  const anomalies = predictions.filter(p => p.confidence > 0.8).map(p => ({
    sequence: p.keystrokes,
    anomalyType: p.classification,
    severity: p.confidence,
    recommendation: generateRecommendation(p.classification)
  }));
  
  return anomalies;
}

function extractNavigationFeatures(data) {
  return {
    tabSequenceLength: data.tabs.length,
    backtrackCount: countBacktracks(data.tabs),
    focusTrapIndicators: detectFocusTraps(data),
    averageTimePerElement: calculateAverageTime(data),
    sequenceDeviation: measureSequenceDeviation(data)
  };
}

The code structure captures the user's keyboard navigation actions on specified forms using captureKeyboardSequence(formId), which means that the user has entered keystrokes, such as tabbing and focusing between fields.

Using extractNavigationFeatures(data), the code processes the Raw keyboard navigation sequence by calculating metrics. Lastly, the code loads a previously-trained ML model and provides the extracted features to the model to be classified into their respective categories along with a confidence score.

Any keyboard navigation anomalies detected with a confidence score of 0.8 or higher will be filtered. The detected keystroke sequences, type of anomaly, severity, and specific suggestions will be included in the final results report for later review by the user.

Fuzzy Logic Paradigm for Navigation-Performance Scoring

Collaborative feedback systems can help improve the virtual keyboard user experience. Fuzzy logic lets you combine multiple measurements – like focus visibility and tab order – into a single score that better reflects the actual user experience. (Source: Liu and others, ResearchGate).

For example, the following code creates a fuzzy inference system that evaluates two inputs: Focus Visibility and Tab Order Logic. These two inputs are evaluated using fuzzy logic and associated rules to arrive at a single score representing the total efficiency of keyboard navigation for a given application.

function createKeyboardNavigationFuzzySystem() {
  // Define fuzzy variables
  const focusVisibility = new FuzzyVariable('focusVisibility', 0, 100);
  focusVisibility.addTerm('poor', new TriangularMF(0, 0, 40));
  focusVisibility.addTerm('adequate', new TriangularMF(30, 50, 70));
  focusVisibility.addTerm('excellent', new TriangularMF(60, 100, 100));
  
  const tabOrderLogic = new FuzzyVariable('tabOrderLogic', 0, 100);
  tabOrderLogic.addTerm('confusing', new TriangularMF(0, 0, 40));
  tabOrderLogic.addTerm('acceptable', new TriangularMF(30, 50, 70));
  tabOrderLogic.addTerm('intuitive', new TriangularMF(60, 100, 100));
  
  const navigationEfficiency = new FuzzyVariable('navigationEfficiency', 0, 100);
  navigationEfficiency.addTerm('inefficient', new TriangularMF(0, 0, 40));
  navigationEfficiency.addTerm('moderate', new TriangularMF(30, 50, 70));
  navigationEfficiency.addTerm('efficient', new TriangularMF(60, 100, 100));
  
  // Define fuzzy rules
  const rules = [
    'IF focusVisibility IS excellent AND tabOrderLogic IS intuitive THEN navigationEfficiency IS efficient',
    'IF focusVisibility IS poor OR tabOrderLogic IS confusing THEN navigationEfficiency IS inefficient',
    'IF focusVisibility IS adequate AND tabOrderLogic IS acceptable THEN navigationEfficiency IS moderate'
  ];
  
  return new FuzzyInferenceSystem([focusVisibility, tabOrderLogic], navigationEfficiency, rules);
}

The resulting score is meant to be more representative of a user’s experience with the keyboard navigation system than other existing methods of measuring user satisfaction. This fuzzy inference system assesses keyboard navigation quality based on multiple dimensions at the same time, yielding scores in a similar range to user-reported satisfaction measurements (Source: Liu and others, ResearchGate).

Conclusion

This article has given you the tools and resources you’ll need to automate a UX audit of your app’s forms – from the initial setup through continuous integration.

You’ve learned:

• Three essential components of forms and the importance of addressing each component systematically.

• How to link objectives directly with business KPIs and user outcomes.

• How to set up automated testing for the specificity of errors, the timing of validation, and the direction for the next actionable step after an error.

• How to review the hint text on your forms: proactive display, proximity to the field it assists, and accessibility.

• How to validate keyboard navigation through verification of tab order, testing focus visibility, and using ARIA tags.

• How to incorporate WCAG criteria into your automated tests and to incorporate Nielsen's 10 Heuristics.

• How to prepare documentation for the handoff between Design and Development, using the "5Cs": Coverage, Completion, Consistency, Clarity, and Correctness.

Next steps:

• Begin with a single high-impact form in your application (signup or checkout) and run the basic automated checks on error messages and keyboard flows.

• Integrate one or two audit functions into your existing test suite to see how they surface issues you might have missed manually.

• Create a centralized error and hint message library for your most critical forms to ensure consistency.

• Gradually expand your audit coverage to additional forms and fields as you refine your automation approach.

• Add these checks to your CI/CD pipeline so they run automatically on every pull request, catching regressions before they reach users.

• Experiment with AI-powered anomaly detection for keyboard navigation patterns once your foundational audits are stable.

Most importantly, remember that form UX optimization is an ongoing practice, not a one-time fix. Start with the forms that directly impact your conversion metrics, validate that your automated checks catch real user problems, and expand your coverage systematically. Your goal should be to build a reliable system that continuously protects your users from friction.

About the author

Hope you enjoyed the article and found it helpful. I’ve been a contributor to freeCodeCamp for more than 8 years, and to make this piece more precise and detailed, I used some expert help.

I sincerely thank skilled designers from COAX Software for the UX and accessibility guidelines, and the developers who provided the audit automation code snippets (who both wished to stay anonymous). The company has a deep expertise in UI/UX design.

To find out more about me and read more content on tech and digital, visit https://www.linkedin.com/in/oleg-romanyuk/.

When users tap a button, they expect it to respond smoothly. When data is loading, users expect some visual feedback. Even small touches, like a gentle bounce or a fading transition, can make an interface feel polished and professional.

For developers, motion graphics are now part of the job. Designers may create the initial assets, but it’s usually developers who bring them to life in the actual product.

That means knowing how to control animations with code, integrate them into app logic, and make sure they perform well across devices.

Fortunately, a number of powerful tools have emerged that make motion graphics more accessible to developers without requiring them to become expert animators.

Let’s dive into some of the best motion graphics tools that developers can use today, and why each one is worth learning.

Lottie

Lottie has become one of the most widely used tools for integrating motion graphics into mobile apps and websites.

Originally developed by Airbnb, Lottie lets designers create animations in Adobe After Effects and export them as lightweight JSON files using the Bodymovin plugin.

As a developer, you don’t have to recreate complex animations manually or deal with heavy video files. Instead, you load the JSON file into your app using the Lottie library, and the animation plays natively.

One of Lottie’s biggest advantages is its cross-platform support. Whether you’re building for iOS, Android, the web, React Native, or Flutter, Lottie works the same way.

The animations are rendered as scalable vector graphics, so they stay sharp on any screen size or resolution. This makes them perfect for things like onboarding screens, button interactions, loading indicators, and even full-screen animated backgrounds.

Lottie also gives you a lot of control through code. You can play, pause, loop, or even dynamically change the speed of an animation. If you want an animation to start when a user scrolls to a certain point or clicks a button, you can easily hook into your app’s logic and control the animation’s state.

This flexibility makes Lottie a favorite for developers who want designer-level animations without the usual headaches of file size, performance, or cross-platform compatibility.

GSAP

While Lottie is great for pre-designed animations, sometimes you want full programmatic control over how elements move and interact. That’s where GSAP, short for GreenSock Animation Platform, really shines.

GSAP allows you to animate anything on the web: HTML elements, SVG graphics, Canvas drawings, and even WebGL content. It’s used by professional web developers and interactive designers around the world for its precision, performance, and flexibility.

With GSAP, you write animations directly in JavaScript. You’re not importing files created in a design tool. Instead, you describe the animations in code, which gives you complete control over timing, sequencing, and interaction.

You can chain multiple animations together, create synchronized timelines, and easily coordinate animations across multiple elements. The syntax is both simple and powerful, allowing you to start with basic effects and scale up to complex sequences as needed.

One of GSAP’s standout features is how well it handles performance. Animations stay smooth even when animating many elements at once, and the library takes care of browser quirks so you don’t have to worry about inconsistencies across platforms.

If you’ve ever struggled with CSS transitions or vanilla JavaScript animations, GSAP feels like a breath of fresh air. You get pixel-perfect control with readable and maintainable code, even as your animations grow more complex.

Framer Motion

If you’re building modern web apps with React, Framer Motion offers a different kind of power.

Unlike GSAP, which works everywhere, Framer Motion is built specifically for React’s component model. Instead of managing animations through external scripts or event listeners, you define them directly in your JSX code alongside the rest of your component logic.

This declarative approach means you simply describe what you want to happen, and Framer Motion takes care of the rest. You specify target values for things like position, opacity, or scale, and the library smoothly transitions from the current state to the new one whenever props change.

This makes it incredibly easy to animate things like page transitions, hover effects, collapsible panels, and other common UI interactions.

Framer Motion also supports more advanced features out of the box, such as gesture-based animations, layout transitions, and shared element transitions between different routes or components.

These kinds of features can be very challenging to implement manually, but Framer Motion makes them approachable even for developers who aren’t animation experts.

Another benefit is how naturally Framer Motion fits into the React ecosystem. Since you’re not writing separate animation code, your logic stays tightly integrated with your app state and component structure. This reduces bugs, simplifies maintenance, and helps keep your codebase clean and organised.

Rive

Rive represents a new way of thinking about motion graphics, one that blurs the line between design and code.

Unlike tools that focus only on timeline-based animations, Rive adds state machines and logic directly into the animation itself. This allows you to create interactive, real-time animations that respond to user input or application state changes.

In Rive’s editor, designers build both the visuals and the interaction logic. You can define how animations transition between different states based on triggers that your app can control.

As a developer, you don’t have to write complex animation logic yourself. Instead, you simply send events to the Rive runtime and let it handle the animation transitions.

For example, imagine a character that waves when a user taps the screen, then smiles if a task is completed. With Rive, the designer creates both the waving and smiling animations and wires up the logic that connects them.

You just tell the animation which state to enter based on your app’s data. The result feels dynamic and interactive, like a small game embedded into your UI.

Rive works across platforms, including web, mobile, and game engines, and the exported files are lightweight enough to use even in performance-sensitive environments.

It’s a tool that empowers both designers and developers to create richer experiences without a ton of back-and-forth or complicated handoffs.

Three.js

Sometimes, 2D animations aren’t enough. When you need true 3D motion graphics in the browser, Three.js is the go-to library for developers.

While not strictly a motion graphics tool in the traditional sense, Three.js allows you to create complex 3D scenes, animate objects, and build immersive experiences entirely with JavaScript.

Three.js abstracts much of the complexity of WebGL, making it more approachable for developers who may not have a deep background in computer graphics. You can load 3D models, apply materials and lighting, set up cameras, and create fully interactive environments that respond to user input.

Animation in Three.js can involve simple tasks like rotating a model or more complex sequences like animated camera moves or physics-based simulations. Because you have full access to the scene graph, you can control every detail of how your objects move and behave.

This opens up possibilities for product visualizations, interactive demos, educational tools, and even web-based games.

While Three.js has a steeper learning curve than the other tools mentioned here, the payoff is significant. You’re no longer limited to flat surfaces and basic transitions. With Three.js, you can build fully immersive experiences that were once only possible in native apps or games.

Summary

As motion graphics become more important in modern interfaces, developers have an expanding toolbox to help them deliver polished, interactive experiences. Each tool has its own strengths, depending on the project and platform.

As a developer, you don’t need to master all of these tools at once. Start with the one that fits your current project needs, and build your motion graphics skills from there. With practice, you’ll discover that motion isn’t just a visual extra — it’s part of how your software communicates, guides, and delights your users.

Hope you enjoyed this article. You can learn more about me or connect with me on Linkedidn.

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.

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 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.

In this article, we're going to learn how to integrate a splash screen in a Flutter app. But first, why is having a splash screen in your app essential?

What is a Splash Screen?

A splash screen is an initial screen that gets displayed right when the user launches the app, before the main page loads. It may not look like much because it's only shown for a short time. But splash screens can really pack a punch as they're the first impression of the app.

You may think that most users ignore them. But splash screens do have an impact, even subconsciously. They set the tone for the overall app theme and the user experience.

Think of a splash screen as a welcome screen for your app. They also help let your users know when there's a loading delay due to a network issue or other error. Because of all this, we as developers should know how to add a proper splash screen to our mobile applications.

Splash Screen Overview

Since splash screens are a valuable initial element in any app, you need to learn how to integrate them properly. So in this tutorial, we are going to learn how to do so in the Flutter ecosystem.

The exact steps are pretty simple because we'll use a package to help us integrate the screen called splashscreen. This package allows us to set the splash screen as well as time the splash screen appears with just a few lines of code. And we don't have to touch any native codes.

So let's get started and learn how to add a simple splash screen containing text, an image, and a loading indicator.

Create a New Flutter Project

First, we need to create a new Flutter project. For that, make sure that you have the Flutter SDK and other Flutter app development related components installed.

If everything is properly set up, then to create a project you can simply run the following command in whatever local directory you want:

flutter create splashSceenExample

After the project has been set up, navigate inside the project directory and execute the following command in the terminal to run the project in either an available emulator or an actual device:

flutter run

After it's successfully built, you will get the following result on the emulator screen:

How to Install the splashscreen Package

Now that we have our flutter project up and running, we can install the required dependencies. Now, you could add a splash screen by tampering with the native code in the Android and iOS folders – but if you're not a native Android or iOS developer, this isn't something you'll need to know how to do.

Fortunately, we have the splashscreen package that makes it easy to add a splash screen in your Flutter app. The package offers widgets and various customization parameters to put up a simple introductory splash screen in your app.

In order to use it, you need to add it to your dependencies first. To do that, just copy the piece of code in the code snippet below and paste it into your pubspec.yaml file:

splashscreen: ^1.3.5

The package provides a SplashScreen widget that lets you display a splash screen before navigating to your app’s primary screen.

How to Add a Splash Screen to Your App

Now, we are going to use the SplashScreen widget provided by the splashscreen package. The idea is to apply the SplashScreen widget to the home parameter of your MaterialApp widget. You can see the overall coding implementation in the code snippet below:

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      home: SplashScreen(
        seconds: 8,
        navigateAfterSeconds:MyHomePage(title: 'Flutter Demo Home Page'),
        title: new Text(
          'SplashScreen Example',
          style: new TextStyle(
              fontWeight: FontWeight.bold,
              fontSize: 20.0,
              color: Colors.white),
        ),
        backgroundColor: Colors.lightBlue[200],
      )
    );
  }
}

In this code, we have introduced the SplashScreen widget in the home parameter of the MaterialApp. There are several parameters we have configured inside the SplashScreen widget. Let's look at each one more closely.

• seconds: The seconds option allows you to enter the time in seconds that you want the splash screen to be displayed.
• navigateAfterSeconds: This option allows you to define the Widget or Screen (preferably the Home Screen of the app) which is shown after the splash screen ends.
• title : This option let you add text to your splash screen. Here, we have used Text widget with some styles to do that.
• backgroundColor : This allows you to specify the overall background color of the splash screen.

Alright, that was a simple configuration of a splash screen with text. This is what it'll look like:

Here, you can see that the splash screen appears for few seconds before the default Home page loads. The loader is also shown by default.

But, we can control the visibility of the loader by applying the useLoader parameter in the SplashScreen widget, which can be either true or false.

How to Add a Custom Loader to Your Splash Screen

We already have the loader in place by default. But, we can control its color and styling by using the loaderColor options as shown in the code snippet below:

home: SplashScreen(
        seconds: 8,
        navigateAfterSeconds:MyHomePage(title: 'Flutter Demo Home Page'),
        title: new Text(
          'SplashScreen Example',
          style: new TextStyle(
              fontWeight: FontWeight.bold,
              fontSize: 20.0,
              color: Colors.white),
        ),
        backgroundColor: Colors.blue,
        styleTextUnderTheLoader: new TextStyle(),
        loaderColor: Colors.white
      )

Now you'll get the result as shown in the demo below:

Here, you can see that we've changed the color of the loader to white.

How to Add an Image or Logo to a Splash Screen

Now to make the splash screen look better, we can add an image or diagram – perhaps a logo or something similar.

The SplashScreen widget gives you two additional parameters to set the logo correctly in the splash screen. The image option lets you add an image from your assets or network, and the photoSize option allows you to specify the dimensions of the image.

It's better to add images from your assets because loading network images depends on connectivity and sometimes the image may not show up due to a slow internet connection.

So we'll need to get the image to our ./assets directory and then register the path to it in our pubspec.yaml file. Then, we can use the image and photoSize options as shown in the code snippet below:

home: SplashScreen(
        seconds: 5,
        navigateAfterSeconds:MyHomePage(title: 'Flutter Demo Home Page'),
        title: new Text(
          'SplashScreen Example',
          style: new TextStyle(
              fontWeight: FontWeight.bold,
              fontSize: 20.0,
              color: Colors.white),
        ),
        image: new Image.asset('assets/flut.png'),
        photoSize: 100.0,        
        backgroundColor: Colors.blue,
        styleTextUnderTheLoader: new TextStyle(),
        loaderColor: Colors.white
      )

This will be the result:

As you can see, we have the image placed at the top of our text. There are other options available as well which you can explore via the documentation of the splash screen package itself.

And there you have it! Keep in mind that this works on both Android and iOS and does not need separate implementations.

Conclusion

Adding a splash screen to your app doesn't have to be hard, thanks to the splashscreen plugin. The main aim of this tutorial was to show you how to integrate a splash screen into your Flutter app without having to touch the native code.

Here, you learned how to create a splash screen and include text, a loading indicator, and an image. Now, the challenge is to use the remaining parameters provided by the SplashScreen widget.

Remember that a nice splash screen also helps alleviate any anxiety a user might have while launching your app. So, it does provide mental health benefits as well.

Just keep in mind that the splashcreen plugin's functionality is a bit limited. If you want to create a custom splash screen with full control over what you can add to it, then you will have to go into the native code. Still, for simple splash screens, this plugin does the job.

Lastly, you can get inspiration for your Flutter App from others that are already out there.

Two years ago, I switched from medicine and redesigned Instagram.

Three months after, I packed what I could fit into my carry-on and two moving boxes, and flew to Saigon to become Christina’s second product designer. Fast forward to today and I am now their Head of Product.

I can still remember my first task on the job: creating color swatches for our tour guide’s awesome new helmets. It might sound like a simple feat, but after trying out hundreds of color combinations and learning a thing or two about color theory, I was pretty proud of the results.

As Christina’s grew from 100 to well over 450+ team members spanning all across Vietnam, so did my responsibilities. From tour guide helmets to redesigning the company’s flagship communication app to then launching it for Airbnb hosts all over the world to use, its been a crazy (but fun) ride.

As I look forward to my next journey back to the States, I wanted to reflect on my experiences by sharing what I’ve learned along the way as someone who started with zero knowledge about product design and technology.

Let’s be clear — I still feel like I know nothing. I just know a little bit less of nothing than the day before.

Trust your gut when it comes to recruitment.

If you, your team, and your culture are playing to the same tune — you will know whether the candidate is a good fit (or not). As a rule of thumb, my go-to question after assessing a candidate’s technical skill is:

“How did this person make me feel?”

My goal for going into any interview is to gain a better understanding of who the candidate is beyond what is on their resume and what their motivations are for arriving in this room with me. If I left the interview feeling more confused and conflicted than I did going in, it’s probably a good sign that this candidate is not the one. If I left the room feeling energized and excited, s/he is most likely a keeper.

Hire someone you would be excited to work with and most importantly, trust your gut instinct.

Be consistent in expressing your values.

From creating wireframes to leading a team of developers, I knew it was important to establish our design and engineering principles early. It helps guide us in making product decisions, examining trade-offs during development, and uniting us stronger as a team.

Our team’s north star ?

An example of when we put our principles to the test was when my CTO had fixed a bug only to have it spam our users with hundreds of push notifications within a span of minutes.

I suggested to my CTO that he should write a post to be considerate of our users, take accountability, and explain what had happened so that our users can empathize with us through our immediate transparency. It will also be the kind of leadership that our junior engineers can learn from. And he did.

Instead of receiving any backlash, his post was received with likes and heart-eye emojis. Not only did our principles became a model for how we communicated as a team and developed our products, but it also forged the path for building a trusting relationship with our users.

It goes without saying that leaders lead best through their actions, and not only by what they have to say.

Now whenever there’s a bug (not saying it happens often), our users are much more forgiving and understanding of it. Not only that, but the other engineers on our team started to follow his example and took accountability for their own missteps as well.

Don’t underestimate the power of 1:1 meetings, because they are so, so important.

Whether you’re a designer or the CEO of a company, 1:1 meetings will always be the bread and butter for building a personal connection with your team. My engineers and I have weekly 1:1 meetings to QA the state of our product and pending features. To my engineers, it might be just a routine product QA. To me, it’s a perfect window of opportunity for me to get to know them on a personal level, address concerns they might have, and provide insights to help them find more value in their work.

If you’re looking for mentorship or growth in your career, I suggest scheduling 1:1 meetings with your team leader. First, it shows initiative. Second, you might also be surprised by the feedback and support you get in return. Before reaching out, make sure you understand what your goal is for the meeting. Is it to understand how you’re doing in your role? Is it to ask for additional remote days? After figuring out what your objective is, make sure to communicate it. This will help give your team leader ample time to prepare and keep the meeting focused.

Creating a process is great, but staying flexible is even better.

Create processes, but plan for disruption. This can mean one of two things. One, the process you created didn’t work out as intended. Two, the process you created worked, but it ended up being discarded somewhere along the ever-evolving development process. This is especially true for startups during their hyper-growth stage when you have many cross-functional teams working together to build and ship a product. When this happens, you have to be able to quickly switch gears, and adopt new mental models, while pushing the overall product vision forward.

So instead of looking for an evergreen process, make your process of implementing and iterating evergreen.

Figma is king.

This article is not sponsored by Figma, but I figured this would be a great chance for me to give this amazing team (and product) a shoutout. Before Figma, our design team at Christina’s was getting around with using Sketch for design, Zeplin for hand-off, and Abstract for version control. It was a lot of tools but we had figured out a process that worked for us. Intrigued by Figma’s approach to design and collaboration, I decided to test out the tool to see for myself.

With Figma, design to developer handoff became almost instantaneous. In addition to the speed and efficiency, we also saved a lot of money in not having to use multiple software to maintain our design system, version control, and hand-offs. Since then, our entire product team has switched over to using Figma, and we haven’t looked back since.

Thanks Figma ✌?

“Work politics will always be a thing, but it doesn’t mean you have to be a part of it.”

My COO said this to me during one of our lunch conversations after I had told him my reason for not wanting to accept the promotion to Head of Product.

With my previous role as a product designer/owner, I was able to influence business decisions, resolve problems, and focus on building products from behind the shadows, politics-free. However, when he said this to me, it made me realize that it’s not about the situation or the environment, but rather how I choose to react (or not react) to it.

More importantly, he made me realize that my new role will only put me in a better position to squash any office politics (with my killer resting face), reinforce our core values, and further protect the positive and empowering culture we have built together.

Start building your persona capital early.

A persona is in short — a representation of a target audience or a person. Research shows it takes about 3 seconds for people to form a perception of you upon the initial meeting. Sometimes even before you’ve even spoken a word. Now consider this in terms of all the micro-interactions you might have with your colleagues, clients, and business partners day-to-day. Add in impromptu slack messages, random hallway exchanges, desk drop-ins, meetings, and company events — now you have given every person you’ve interacted with countless seconds to form their opinion of you.

What kind of team member would you like to be? What kind of leader do you want to be perceived as? What do you want to be known for? Have these questions answered before you join any team or company — or someone else will answer them for you.

If you want to be perceived as a competent, reliable, and self-sufficient person — show it and own it every opportunity you get.

Once you build your persona capital, it’ll be one of your most valuable assets when communicating with stakeholders, influencing key decisions, and working with cross-functional teams.

Imposter syndrome never truly goes away, but it does get easier.

Several months after joining Christina’s, I had a heart-to-heart with my CTO. I told him how I felt like an imposter. I told him how I felt like everything I’ve achieved up to this point had all been attributed to luck. It also didn’t help that I’ve never had any formal design education. I’m afraid that I was going to be exposed as a fraud one day. I was upfront about my personal assessment, and honestly, it felt good to finally say it out loud.

What he said next shocked me:

he told me he felt the same.

I was in disbelief and all I could muster was… really? This made me realized that this so-called imposter syndrome is perfectly normal, and it can happen to anyone regardless of age, sex, and experience. If anything, it just means you’re a humble person with really high expectations of yourself.

It’s been a couple of years since that exchange, and since then, I’ve felt less and less like an imposter. If you’re feeling these insecurities, share it with someone you trust. It’ll help relieve some of the burden and guilt.

One reassuring thing I’ll add is this — it will only get easier with time as long as you show up, put in the work, and commit to continuously learn.

Remember, you’ve earned your spot at the table. The only person that you need to convince now is yourself.

“Your harshest critic is always going to be yourself. Don’t ignore that critic but don’t give it more attention than it deserves. 

— Michael Ian Black”

Recently, I decided to build a web application to allow designers and developers to generate variants for colors and to check color accessibility. In this post, I would like to give you a walkthrough of how I built some of the components I would use in that app.

Full source code for the application can be found at the end of this article, along with a link to a Storybook instance with all of the described components.

Dependencies

To help me build these components I used Tinycolor, a library with a range of color utility functions which you can use to manipulate, transform, and represent colors.

I have also used React Spring, which is a spring physics based library that allows you to add animations to your project really easily.

Color Tile

Color Tile Designs

The simplest component out of our list, the color tile will serve as a building block for other components. The responsibility of this component is to display a color, along with its name and HEX value.

const TILE_SIZES = {
  sm: "2.5rem",
  md: "4rem",
  lg: "6rem"
};

const ColorTile = ({
  color,
  name,
  hideName,
  hideHex,
  size,
  className,
  customTileStyle,
  ...otherProps
}) => {
  const containerClass = cx(styles.container, className);

  const tileClass = cx(styles.tile, {
    "margin-bottom--xxs": !hideName || !hideHex
  });
  const dimension = TILE_SIZES[size];
  const tileStyle = {
    "--color-tile-width": dimension,
    "--color-tile-height": dimension,
    "--color-tile-bg": color,
    "--color-tile-border-color": "transparent",
    ...customTileStyle
  };
  const tile = <div style={tileStyle} className={tileClass} />;

  const nameClass = cx("text--colors-grey-lighten-30", {
    "margin-bottom--xxs": !hideHex
  });

  const hex = useMemo(() => tinycolor(color).toHexString(), [color]);
  return (
    <div className={containerClass} {...otherProps}>
      {tile}
      {!hideName && <small className={nameClass}>{name}</small>}
      {!hideHex && (
        <small className="text--colors-grey-lighten-30">{hex}</small>
      )}
    </div>
  );
};

ColorTile.propTypes = {
  /**
   * Color to display
   */
  color: PropTypes.string.isRequired,
  /**
   * Name of the color
   */
  name: PropTypes.string,
  /**
   * Hide the name text if true
   */
  hideName: PropTypes.bool,
  /**
   * Hide the hex color value display if true
   */
  hideHex: PropTypes.bool,
  /**
   * Size of the tile
   */
  size: PropTypes.oneOf(["sm", "md", "lg"]),
  /**
   * Custom styles to apply to the tile element
   */
  customTileStyle: PropTypes.object
};

ColorTile.defaultProps = {
  size: "md",
  hideName: true,
  hideHex: true,
  customTileStyle: {}
};

Notes on the implementation

1. Line 17, and line 19 might look slightly strange if you’re not familiar with the excellent classnames library. Basically, the classnames library allows you to concatenate and conditionally apply CSS classes to your elements.
2. On line 36 you can see that we calculate the HEX string of the color passed in. Since we’re using the color prop passed in directly in the CSS, it can be in any acceptable CSS color format, not just HEX. It could be an rgba string for example. This is where Tinycolor comes in. We can give it any of those formats and it returns a nicely formatted HEX string we can display along with our tile.
3. Sticking with line 36, you might also have noticed that the function to calculate the HEX string is wrapped in useMemo . This is because we only want to compute this value if the color changes. We can avoid recalculating if any of the other props change which might cause a rerender. I’m still learning the new Hooks API, so this might not be the most appropriate usage of useMemo since it’s probably not a particularly expensive operation, but I think it was a nice way to handle it regardless. You can learn more about the useMemo function or Hooks in general here.

.tile {
  width: var(--color-tile-width);
  height: var(--color-tile-height);
  background-color: var(--color-tile-bg);
  border: 3px solid var(--color-tile-border-color);
  cursor: pointer;
}

.container {
  display: inline-flex;
  flex-direction: column;
  align-items: center;
}

Notes on the styling

The styling of our tile is really simple. We have the tile itself which takes its dimensions and color from the variables we pass in.

Then, we have the container which holds the tile, the color name, and the HEX value. It’s a simple flex container that keeps our elements aligned.

Color Picker

Color Picker Designs

For our Color Picker, we are going to reuse the Color Tile component, along with a picker from the react-color package.

import React, { useState } from "react";
import PropTypes from "prop-types";
import { ChromePicker } from "react-color";

import ColorTile from "../ColorTile/ColorTile";

import styles from "./ColorPicker.module.scss";

const ColorPicker = ({ color, onChange, className, tileClassName }) => {
  const [isPickerOpen, setPickerOpen] = useState(false);

  const onSwatchClick = () => {
    setPickerOpen(!isPickerOpen);
  };

  const onColorChange = color => {
    onChange(color.hex);
  };

  return (
    <div className={className}>
      <ColorTile
        color={color}
        onClick={onSwatchClick}
        hideHex={false}
        size="lg"
        className={tileClassName}
      />

      {isPickerOpen && (
        <div className={styles.popover}>
          <div className={styles.cover} onClick={onSwatchClick} />
          <ChromePicker color={color} onChangeComplete={onColorChange} />
        </div>
      )}
    </div>
  );
};

ColorPicker.propTypes = {
  /**
   * Currently selected color value
   */
  color: PropTypes.string,
  /**
   * Callback fn for when the color changes
   */
  onChange: PropTypes.func,
  /**
   * Custom classes to apply to the color tile
   */
  tileClassName: PropTypes.string
};

ColorPicker.defaultProps = {
  onChange: () => {}
};

export default ColorPicker;

Notes on the implementation

Our color picker is composed of a ColorTile which shows the currently selected color, along with its HEX value, and a ChromePicker from the react-color library which actually allows us to select a color.

We have some state which controls whether the ChromePicker is visible or not, and a callback function to let whatever component is using our picker know when the color changes. react-color provides lots of information when the color changes, but the hex value was enough for my purposes as you can see on line 17.

Color List

Color List Designs

Our Color List component takes a list of colors and renders them as a list containing color tiles. Our Color List is intended to show a base color as a slightly larger tile, with the remaining tiles representing the variants of the base shown as smaller tiles. We also allow naming our list, and this will be used to display the name of the base color.

Our Color List also brings the “springy” part of this walkthrough. The tiles will be animated on entry using React Spring ?

const ROW_DIRECTION = "row";
const COL_DIRECTION = "col";
const ALL_DIRECTIONS = [ROW_DIRECTION, COL_DIRECTION];

/**
 * Renders a list of colors
 */
const ColorPaletteList = ({
  name,
  colors,
  direction,
  onColorClick,
  onColorDoubleClick,
  animationRef,
  getCustomTileStyle,
  renderTileBy,
  ...otherProps
}) => {
  const headingClass = cx("margin-bottom--xs", {
    "text--align-left": direction === ROW_DIRECTION,
    "text--align-center": direction === COL_DIRECTION
  });

  const containerClass = cx({
    [styles.containerCol]: direction === COL_DIRECTION,
    [styles.containerRow]: direction === ROW_DIRECTION
  });

  const tileClass = cx({
    "margin-bottom--xs": direction === COL_DIRECTION,
    "margin-right--xs": direction === ROW_DIRECTION
  });

  const trailMargin =
    direction === COL_DIRECTION ? "marginBottom" : "marginRight";
  const trails = useTrail(colors.length, {
    from: { [trailMargin]: 20, opacity: 0 },
    to: { [trailMargin]: 0, opacity: 1 },
    ref: animationRef
  });

  return (
    <div {...otherProps}>
      <h4 className={headingClass}>{name || ""}</h4>
      <div className={containerClass}>
        {trails.map((trailProps, idx) => {
          const color = colors[idx];
          const onClick = () => onColorClick(color);
          return (
            <animated.div
              key={`animated-tile-${color.name}-${idx}`}
              style={trailProps}
            >
              {renderTileBy(color, tileClass, onClick, false, false)}
            </animated.div>
          );
        })}
      </div>
    </div>
  );
};

ColorPaletteList.propTypes = {
  /**
   * Name of the list
   */
  name: PropTypes.string,
  /**
   * The list of colors to display
   */
  colors: PropTypes.arrayOf(
    PropTypes.shape({
      color: PropTypes.string,
      name: PropTypes.string,
      isMain: PropTypes.bool
    })
  ).isRequired,
  /**
   * Determines the layout of the tiles
   */
  direction: PropTypes.oneOf(ALL_DIRECTIONS),
  /**
   * Callback for when a color in the list is clicked
   */
  onColorClick: PropTypes.func,
  /**
   * Ref used to hook into the animation
   */
  animationRef: PropTypes.object,
  /**
   * Pass custom styles for a particular color tile
   */
  getCustomTileStyle: PropTypes.func,
  /**
   * Render prop to render the color tile
   */
  renderTileBy: PropTypes.func
};

ColorPaletteList.defaultProps = {
  direction: COL_DIRECTION,
  onColorClick: () => {},
  onColorDoubleClick: () => {},
  getCustomTileStyle: () => ({}),
  renderTileBy: (color, className, onClick, hideName, hideHex) => (
    <ColorTile
      key={color.name}
      color={color.color}
      name={color.name}
      size={color.isMain ? "lg" : "md"}
      className={className}
      onClick={onClick}
      hideName={hideName}
      hideHex={hideHex}
    />
  )
};

Notes on the implementation

1. On line 34–40 you can see our implementation of React Spring using useTrail . You can read more about trails here. We animate the margin on the Color Tile container and depending on whether the list is column aligned or row aligned this could be the margin on the right or bottom.
2. On line 39 you can see that we pass a ref to our animation. This is so that we can pass a ref to our Color List to delay the animation. This would be useful is we wanted to trigger a specific sequence of animations from a parent component.

.containerCol {
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
}

.containerRow {
  display: flex;
  flex-direction: row;
  align-items: center;
  flex-wrap: wrap;
}

Color Pair

Color Pair Designs

The Color Pair component takes two colors and displays them side by side along with some accessibility information. The idea is that a developer or designer would pair colors to ensure they work together when used as a background/foreground combination.

const AccessiblePair = ({
  background,
  foreground,
  hideCloseBtn,
  onCloseBtnClick,
  closeBtnIcon,
  ...otherProps
}) => {
  const title = `${background.name}/${foreground.name}`;

  const bgTileStyle = {
    "--tile-color": background.color
  };

  const fgTileStyle = {
    "--tile-color": foreground.color
  };

  const tileContainerClass = cx(styles.tileContainer, "margin-right--sm");
  const titleContainerClass = cx(
    styles.titleContainer,
    "margin-bottom--xxs",
    "text--colors-grey-lighten-30"
  );

  const isAAPass = tinycolor.isReadable(background.color, foreground.color, {
    level: "AA",
    size: "small"
  });
  const isAAAPass = tinycolor.isReadable(background.color, foreground.color, {
    level: "AAA",
    size: "small"
  });

  const aaDisplayText = "WCAG AA";
  const aaaDisplayText = "WCAG AAA";
  const aaPillType = isAAPass ? "success" : "error";
  const aaaPillType = isAAAPass ? "success" : "error";

  const examplePillStyle = {
    "--pill-background": background.color,
    "--pill-color": foreground.color
  };

  return (
    <div {...otherProps}>
      <div className={titleContainerClass}>
        <small className={styles.title}>{title}</small>
        {!hideCloseBtn && (
          <FontAwesomeIcon icon={closeBtnIcon} onClick={onCloseBtnClick} />
        )}
      </div>
      <div className={styles.mainContent}>
        <div className={tileContainerClass}>
          <div style={bgTileStyle} className={styles.tile} />
          <div style={fgTileStyle} className={styles.tile} />
        </div>

        <div className={styles.pillContainer}>
          <Pill type={aaPillType} className="margin-bottom--xxs">
            {aaDisplayText}
          </Pill>
          <Pill type={aaaPillType} className="margin-bottom--xxs">
            {aaaDisplayText}
          </Pill>
          <Pill style={examplePillStyle}>This is how text will look</Pill>
        </div>
      </div>
    </div>
  );
};

AccessiblePair.propTypes = {
  /**
   * The background color
   */
  background: colorShape.isRequired,
  /**
   * The foreground color
   */
  foreground: colorShape.isRequired,
  /**
   * Set to true to hide the close button
   */
  hideCloseBtn: PropTypes.bool,
  /**
   * Callback for when the close button is clicked
   */
  onCloseBtnClick: PropTypes.func,
  /**
   * FontAwesome icon to use for the close button
   */
  closeBtnIcon: PropTypes.string
};

AccessiblePair.defaultProps = {
  hideCloseBtn: false,
  onCloseBtnClick: () => {},
  closeBtnIcon: "times"
};

Notes on the implementation

As mentioned, our Color Pair component takes a background and foreground color, and on line 26–33 you can see where we use Tinycolor to determine the accessibility of the color pair.

We use a simple Pill component to display the result with the type of the Pill being determined by the result. I haven’t shown the source for the Pill here, but it’s a pretty standard component that you would find in any component library (Bootstrap, Material, etc).

You can learn more about accessibility and WCAG here.

Conclusion and source code

I hope you have learned something from this walkthrough. I highly recommend looking into the libraries I have mentioned here in your next project. In particular, my application would have taken much longer to create without the excellent Tinycolor package.

Source code for the full application can be found here.

A Storybook instance with all of the components can be found here.

If you have any feedback on the designs, code, or in general, I would love to hear it.

Thank you very much for reading my article!

Originally published here.

If you had asked me four years ago, when I became a CS graduate, what kind of career path I saw myself following, I probably would have told you back-end Java development or something similar. I was never creative, in the paint meets canvas kind of way, so I didn’t really consider a career path involving front-end development and design.

As we all know, things change. Over the course of my career, I have become more and more interested in UI development and design. I have been lucky enough in my job to have gained exposure to front-end development and to have been allowed to invest time in improving the skills necessary to be a front-end developer.

Over the past 12 months, I have been striving to improve my understanding of UI/UX design, both because of personal interest and to allow me to be more effective when working with designers.

In this post, I would like to share the lessons I have learned, the resources I have gathered, and the mistakes I have made in the hopes that other developers will be able to learn from my journey.

Table of Contents

• It’s not just talent
• Look, think, steal
• Learn the theory
• Build something
• Don’t give up
• Resources
• Conclusion

It’s not just talent

This one seems obvious to me now, but there was a time when I thought that designers were wizards that were born with the ability to create amazing looking apps, and websites.

It turns out that they’re not. They have just worked hard to perfect their craft. In the same way that learning to code comes easier to some people, there are people who will have a natural talent for design, but talent doesn’t mean much without hard work.

Design is something that can be learned. Don’t make the mistake I did and write yourself off because you’re not creative in the traditional sense. Solving programming problems takes creativity; think about solving design challenges in the same way.

Look, think, steal

In the same way that reading good code will help you become a better developer, learning from what others have created will help you become a better designer.

The next time you visit a website or use an app, look at it and really think about why it looks and behaves the way it does. Why are the elements are placed where they are? Why is that button a particular color? Why do you have to perform actions in a certain order?

Take Medium’s applause button for example. Why didn’t they just use a “like” button like every other social media website? In my opinion, it was a clever design decision not to. Instead, they are able to reinforce the idea of community that drives the site by carefully designing an interaction. Giving an article or response fifty claps takes time for a user to do, but it helps them to really connect with the content they are viewing and the person who created it.

Sites like Awwwards and Dribbble have proven invaluable to me in the last year. Many of the designs I have created have taken liberal inspiration from the creations of other great designers.

Learn the theory

When I first started putting together designs of my own, I couldn’t figure out why they looked and behaved so poorly. The flows were awkward, the colors mismatched, and the layouts were inconsistent.

I thought I could just jump straight in and use my development knowledge along with my basic knowledge of how sites should work, as a user, and it would work out fine.

I was very, very wrong. I ended up creating designs from a developers point of view, instead of using design theory as a base.

Developers know how a site works, but designers know how a site behaves and feels. There is a big gap that you can only fill by gaining a foundation in design knowledge.

To gain a basic understanding of design theory, I mostly used Medium and Udemy. You can find links to the resources I used in the section below.

Build something

Any developer or CS professor will tell you that the best way to become a better programmer is to write code. The same principle applies to design.

It doesn’t matter what you design, as long as you learn from it. Treat it as a real project: Think about the users. Create wireframes, mockups, and prototypes. Iterate on the original design to improve it. You can use sites like Reddit to get feedback on what you create.

You can even pair it with improving your development skills. Most of my recent side projects have been motivated by a joint desire to improve both my web development and design skills. After you design your project, you can develop it and see both sides of the coin.

Here are some ideas to get you started:

• Design an interaction. Use Medium’s applause button for inspiration.
• Design an app for your favorite charity. Think about the different kinds of users: potential, infrequent, and regular patrons.
• Design your CV. Think about the colors you use and what the mean. Think about how your CV will be used. Will it just be viewed on a screen, or will it be printed out? How does that influence the design?
• Redesign an existing website. It could be your local transport provider or a global brand. Compare your design with the original and think about the differences from a user’s perspective.
• Design something physical, such as a new method of transport or maybe an alternative to something simple like a fork or chair. I have found thinking about the design of everyday things to be a really useful way of getting in the mindset to design something intuitive.

Don’t give up

When I look back on what I created a year ago, it’s hard not to wince. But everyone starts somewhere. Seeing the progression in what you create will be worth it. As long as you are learning from what you’re doing then your time is being well spent.

It might help to keep track of what you have learned at a regular interval. Every month I look back at some of the things I have worked on and try to take as much as I can from the experience. Even if it’s only to recognize some small piece of information you picked up from reading an article, it’s still progress.

Some designs I have created from oldest (left) to newest (right)

Resources

Below is a small collection of my favorite tools, articles, and courses. You can find many more that I haven’t listed here, and here.

Tools

Figma — Design and prototyping with collaboration.

FramerX — Similar to Figma, but with added React, and discoverable components.

Coolors — Discover and generate color palletes.

WebAIM Contrast Checker — Make sure your colors are accessible.

Archetype — Typography system editor and generator.

Articles

7 Practical Tips for Cheating at Design

10 cheat codes for designing User Interfaces

10 Small Design Mistakes We Still Make

Design Better Forms

A Complete List Of UX Deliverables

The Psychology Principles Every UI/UX Designer Needs to Know

How to use colors in UI Design

16 Quotes You Need to Read as UX Designer

Product Design Principles in a Single Card

Courses

User Experience Design Fundamentals — Udemy

The Complete App Design Course — UX, UI and Design Thinking — Udemy

UXTraining.com

Conclusion

I hope you have been able to take something from my journey. If you have design tips or resources that have helped you learn, I would love to hear them in the responses.

Thanks for reading!

CSS is often quickly dismissed as an easy thing to learn by developers, or one thing you just pick up when you need to quickly style a page or app. Due to this reason, it’s often learned on-the-fly, or we learn things in isolation right when we have to use them. This can be a huge source of frustration when we find that the tool does not simply do what we want.

This article will help you get up to speed with CSS and get an overview of the main modern features you can use to style your pages and apps.

I hope to help you get comfortable with CSS and get you quickly up to speed with using this awesome tool that lets you create stunning designs on the Web.

Click here to get a PDF / ePub / Mobi version of this post to read offline

CSS, a shorthand for Cascading Style Sheets, is one of the main building blocks of the Web. Its history goes back to the 90’s, and along with HTML it has changed a lot since its humble beginnings.

As I’ve been creating websites since before CSS existed, I have seen its evolution.

CSS is an amazing tool, and in the last few years it has grown a lot, introducing many fantastic features like CSS Grid, Flexbox and CSS Custom Properties.

This handbook is aimed at a vast audience.

First, the beginner. I explain CSS from zero in a succinct but comprehensive way, so you can use this book to learn CSS from the basics.

Then, the professional. CSS is often considered like a secondary thing to learn, especially by JavaScript developers. They know CSS is not a real programming language, they are programmers and therefore they should not bother learning CSS the right way. I wrote this book for you, too.

Next, the person that knows CSS from a few years but hasn’t had the opportunity to learn the new things in it. We’ll talk extensively about the new features of CSS, the ones that are going to build the web of the next decade.

CSS has improved a lot in the past few years and it’s evolving fast.

Even if you don’t write CSS for a living, knowing how CSS works can help save you some headaches when you need to understand it from time to time, for example while tweaking a web page.

Thank you for getting this ebook. My goal with it is to give you a quick yet comprehensive overview of CSS.

Flavio

You can reach me via email at flavio@flaviocopes.com, on Twitter @flaviocopes.

My website is flaviocopes.com.

Table of Contents

• INTRODUCTION TO CSS
• A BRIEF HISTORY OF CSS
• ADDING CSS TO AN HTML PAGE
• SELECTORS
• CASCADE
• SPECIFICITY
• INHERITANCE
• IMPORT
• ATTRIBUTE SELECTORS
• PSEUDO-CLASSES
• PSEUDO-ELEMENTS
• COLORS
• UNITS
• URL
• CALC
• BACKGROUNDS
• COMMENTS
• CUSTOM PROPERTIES
• FONTS
• TYPOGRAPHY
• BOX MODEL
• BORDER
• PADDING
• MARGIN
• BOX SIZING
• DISPLAY
• POSITIONING
• FLOATING AND CLEARING
• Z-INDEX
• CSS GRID
• FLEXBOX
• TABLES
• CENTERING
• LISTS
• MEDIA QUERIES AND RESPONSIVE DESIGN
• FEATURE QUERIES
• FILTERS
• TRANSFORMS
• TRANSITIONS
• ANIMATIONS
• NORMALIZING CSS
• ERROR HANDLING
• VENDOR PREFIXES
• CSS FOR PRINT
• WRAPPING UP

INTRODUCTION TO CSS

CSS (an abbreviation of Cascading Style Sheets) is the language that we use to style an HTML file, and tell the browser how should it render the elements on the page.

In this book I talk exclusively about styling HTML documents, although CSS can be used to style other things too.

A CSS file contains several CSS rules.

Each rule is composed by 2 parts:

• the selector
• the declaration block

The selector is a string that identifies one or more elements on the page, following a special syntax that we’ll soon talk about extensively.

The declaration block contains one or more declarations, in turn composed by a property and value pair.

Those are all the things we have in CSS.

Carefully organising properties, associating them values, and attaching those to specific elements of the page using a selector is the whole argument of this ebook.

How does CSS look like

A CSS rule set has one part called selector, and the other part called declaration. The declaration contains various rules, each composed by a property, and a value.

In this example, p is the selector, and applies one rule which sets the value 20px to the font-size property:

p {
  font-size: 20px;
}

Multiple rules are stacked one after the other:

p {
  font-size: 20px;
}

a {
  color: blue;
}

A selector can target one or more items:

p, a {
  font-size: 20px;
}

and it can target HTML tags, like above, or HTML elements that contain a certain class attribute with .my-class, or HTML elements that have a specific id attribute with #my-id.

More advanced selectors allow you to choose items whose attribute matches a specific value, or also items which respond to pseudo-classes (more on that later)

Semicolons

Every CSS rule terminates with a semicolon. Semicolons are not optional, except after the last rule. But I suggest to always use them for consistency and to avoid errors if you add another property and forget to add the semicolon on the previous line.

Formatting and indentation

There is no fixed rule for formatting. This CSS is valid:

p
      {
  font-size:           20px   ;
                      }

a{color:blue;}

but a pain to see. Stick to some conventions, like the ones you see in the examples above: stick selectors and the closing brackets to the left, indent 2 spaces for each rule, have the opening bracket on the same line of the selector, separated by one space.

Correct and consistent use of spacing and indentation is a visual aid in understanding your code.

A BRIEF HISTORY OF CSS

Before moving on, I want to give you a brief recap of the history of CSS.

CSS was grown out of the necessity of styling web pages. Before CSS was introduced, people wanted a way to style their web pages, which looked all very similar and “academic” back in the day. You couldn’t do much in terms of personalisation.

HTML 3.2 introduced the option of defining colors inline as HTML element attributes, and presentational tags like center and font, but that escalated quickly into a far from ideal situation.

CSS let us move everything presentation-related from the HTML to the CSS, so that HTML could get back being the format that defines the structure of the document, rather than how things should look in the browser.

CSS is continuously evolving, and CSS you used 5 years ago might just be outdated, as new idiomatic CSS techniques emerged and browsers changed.

It’s hard to imagine the times when CSS was born and how different the web was.

At the time, we had several competing browsers, the main ones being Internet Explorer or Netscape Navigator.

Pages were styled by using HTML, with special presentational tags like bold and special attributes, most of which are now deprecated.

This meant you had a limited amount of customisation opportunities.

The bulk of the styling decisions were left to the browser.

Also, you built a site specifically for one of them, because each one introduced different non-standard tags to give more power and opportunities.

Soon people realised the need for a way to style pages, in a way that would work across all browsers.

After the initial idea proposed in 1994, CSS got its first release in 1996, when the CSS Level 1 (“CSS 1”) recommendation was published.

CSS Level 2 (“CSS 2”) got published in 1998.

Since then, work began on CSS Level 3. The CSS Working Group decided to split every feature and work on it separately, in modules.

Browsers weren’t especially fast at implementing CSS. We had to wait until 2002 to have the first browser implement the full CSS specification: IE for Mac, as nicely described in this CSS Tricks post: https://css-tricks.com/look-back-history-css/

Internet Explorer implemented the box model incorrectly right from the start, which led to years of pain trying to have the same style applied consistently across browsers. We had to use various tricks and hacks to make browsers render things as we wanted.

Today things are much, much better. We can just use the CSS standards without thinking about quirks, most of the time, and CSS has never been more powerful.

We don’t have official release numbers for CSS any more now, but the CSS Working Group releases a “snapshot” of the modules that are currently considered stable and ready to be included in browsers. This is the latest snapshot, from 2018: https://www.w3.org/TR/css-2018/

CSS Level 2 is still the base for the CSS we write today, and we have many more features built on top of it.

ADDING CSS TO AN HTML PAGE

CSS is attached to an HTML page in different ways.

1: Using the link tag

The link tag is the way to include a CSS file. This is the preferred way to use CSS as it's intended to be used: one CSS file is included by all the pages of your site, and changing one line on that file affects the presentation of all the pages in the site.

To use this method, you add a link tag with the href attribute pointing to the CSS file you want to include. You add it inside the head tag of the site (not inside the body tag):

<link rel="stylesheet" type="text/css" href="myfile.css">

The rel and type attributes are required too, as they tell the browser which kind of file we are linking to.

2: using the style tag

Instead of using the link tag to point to separate stylesheet containing our CSS, we can add the CSS directly inside a style tag. This is the syntax:

<style>
...our CSS...
</style>

Using this method we can avoid creating a separate CSS file. I find this is a good way to experiment before “formalising” CSS to a separate file, or to add a special line of CSS just to a file.

3: inline styles

Inline styles are the third way to add CSS to a page. We can add a style attribute to any HTML tag, and add CSS into it.

<div style="">...</div>

Example:

<div style="background-color: yellow">...</div>

SELECTORS

A selector allows us to associate one or more declarations to one or more elements on the page.

Basic selectors

Suppose we have a p element on the page, and we want to display the words into it using the yellow color.

We can target that element using this selector p, which targets all the element using the p tag in the page. A simple CSS rule to achieve what we want is:

p {
  color: yellow;
}

Every HTML tag has a corresponding selector, for example: div, span, img.

If a selector matches multiple elements, all the elements in the page will be affected by the change.

HTML elements have 2 attributes which are very commonly used within CSS to associate styling to a specific element on the page: class and id.

There is one big difference between those two: inside an HTML document you can repeat the same class value across multiple elements, but you can only use an id once. As a corollary, using classes you can select an element with 2 or more specific class names, something not possible using ids.

Classes are identified using the . symbol, while ids using the # symbol.

Example using a class:

<p class="dog-name">
  Roger
</p>

.dog-name {
  color: yellow;
}

Example using an id:

<p id="dog-name">
  Roger
</p>

#dog-name {
  color: yellow;
}

Combining selectors

So far we’ve seen how to target an element, a class or an id. Let’s introduce more powerful selectors.

Targeting an element with a class or id

You can target a specific element that has a class, or id, attached.

Example using a class:

<p class="dog-name">
  Roger
</p>

p.dog-name {
  color: yellow;
}

Example using an id:

<p id="dog-name">
  Roger
</p>

p#dog-name {
  color: yellow;
}

Why would you want to do that, if the class or id already provides a way to target that element? You might have to do that to have more specificity. We’ll see what that means later.

Targeting multiple classes

You can target an element with a specific class using .class-name, as you saw previously. You can target an element with 2 (or more) classes by combining the class names separated with a dot, without spaces.

Example:

<p class="dog-name roger">
  Roger
</p>

.dog-name.roger {
  color: yellow;
}

Combining classes and ids

In the same way, you can combine a class and an id.

Example:

<p class="dog-name" id="roger">
  Roger
</p>

.dog-name#roger {
  color: yellow;
}

Grouping selectors

You can combine selectors to apply the same declarations to multiple selectors. To do so, you separate them with a comma.

Example:

<p>
  My dog name is:
</p>
<span class="dog-name">
  Roger
</span>

p, .dog-name {
  color: yellow;
}

You can add spaces in those declarations to make them more clear:

p,
.dog-name {
  color: yellow;
}

Follow the document tree with selectors

We’ve seen how to target an element in the page by using a tag name, a class or an id.

You can create a more specific selector by combining multiple items to follow the document tree structure. For example, if you have a span tag nested inside a p tag, you can target that one without applying the style to a span tag not included in a p tag:

<span>
  Hello!
</span>
<p>
  My dog name is:
  <span class="dog-name">
    Roger
  </span>
</p>

p span {
  color: yellow;
}

See how we used a space between the two tokens p and span.

This works even if the element on the right is multiple levels deep.

To make the dependency strict on the first level, you can use the > symbol between the two tokens:

p > span {
  color: yellow;
}

In this case, if a span is not a first children of the p element, it's not going to have the new color applied.

Direct children will have the style applied:

<p>
  <span>
    This is yellow
  </span>
  <strong>
    <span>
      This is not yellow
    </span>
  </strong>
</p>

Adjacent sibling selectors let us style an element only if preceded by a specific element. We do so using the + operator:

Example:

p + span {
  color: yellow;
}

This will assign the color yellow to all span elements preceded by a p element:

<p>This is a paragraph</p>
<span>This is a yellow span</span>

We have a lot more selectors we can use:

• attribute selectors
• pseudo class selectors
• pseudo element selectors

We’ll find all about them in the next sections.

CASCADE

Cascade is a fundamental concept of CSS. After all, it’s in the name itself, the first C of CSS — Cascading Style Sheets — it must be an important thing.

What does it mean?

Cascade is the process, or algorithm, that determines the properties applied to each element on the page. Trying to converge from a list of CSS rules that are defined in various places.

It does so taking in consideration:

• specificity
• importance
• inheritance
• order in the file

It also takes care of resolving conflicts.

Two or more competing CSS rules for the same property applied to the same element need to be elaborated according to the CSS spec, to determine which one needs to be applied.

Even if you just have one CSS file loaded by your page, there is other CSS that is going to be part of the process. We have the browser (user agent) CSS. Browsers come with a default set of rules, all different between browsers.

Then your CSS comes into play.

Then the browser applies any user stylesheet, which might also be applied by browser extensions.

All those rules come into play while rendering the page.

We’ll now see the concepts of specificity and inheritance.

SPECIFICITY

What happens when an element is targeted by multiple rules, with different selectors, that affect the same property?

For example, let’s talk about this element:

<p class="dog-name">
  Roger
</p>

We can have

.dog-name {
  color: yellow;
}

and another rule that targets p, which sets the color to another value:

p {
  color: red;
}

And another rule that targets p.dog-name. Which rule is going to take precedence over the others, and why?

Enter specificity. The more specific rule will win. If two or more rules have the same specificity, the one that appears last wins.

Sometimes what is more specific in practice is a bit confusing to beginners. I would say it’s also confusing to experts that do not look at those rules that frequently, or simply overlook them.

How to calculate specificity

Specificity is calculated using a convention.

We have 4 slots, and each one of them starts at 0: 0 0 0 0. The slot at the left is the most important, and the rightmost one is the least important.

Like it works for numbers in the decimal system: 1 0 0 0 is higher than 0 1 0 0.

Slot 1

The first slot, the rightmost one, is the least important.

We increase this value when we have an element selector. An element is a tag name. If you have more than one element selector in the rule, you increment accordingly the value stored in this slot.

Examples:

p {}                    /* 0 0 0 1 */
span {}                 /* 0 0 0 1 */
p span {}               /* 0 0 0 2 */
p > span {}             /* 0 0 0 2 */
div p > span {}         /* 0 0 0 3 */

Slot 2

The second slot is incremented by 3 things:

• class selectors
• pseudo-class selectors
• attribute selectors

Every time a rule meets one of those, we increment the value of the second column from the right.

Examples:

.name {}                 /* 0 0 1 0 */
.users .name {}          /* 0 0 2 0 */
[href$='.pdf'] {}        /* 0 0 1 0 */
:hover {}                /* 0 0 1 0 */

Of course slot 2 selectors can be combined with slot 1 selectors:

div .name {}             /* 0 0 1 1 */
a[href$='.pdf'] {}       /* 0 0 1 1 */
.pictures img:hover {}   /* 0 0 2 1 */

One nice trick with classes is that you can repeat the same class and increase the specificity. For example:

.name {}              /* 0 0 1 0 */
.name.name {}         /* 0 0 2 0 */
.name.name.name {}    /* 0 0 3 0 */

Slot 3

Slot 3 holds the most important thing that can affect your CSS specificity in a CSS file: the id.

Every element can have an id attribute assigned, and we can use that in our stylesheet to target the element.

Examples:

#name {}                    /* 0 1 0 0 */
.user #name {}              /* 0 1 1 0 */
#name span {}               /* 0 1 0 1 */

Slot 4

Slot 4 is affected by inline styles. Any inline style will have precedence over any rule defined in an external CSS file, or inside the style tag in the page header.

Example:

<p style="color: red">Test</p> /* 1 0 0 0 */

Even if any other rule in the CSS defines the color, this inline style rule is going to be applied. Except for one case — if !important is used, which fills the slot 5.

Importance

Specificity does not matter if a rule ends with !important:

p {
  font-size: 20px!important;
}

That rule will take precedence over any rule with more specificity

Adding !important in a CSS rule is going to make that rule more important than any other rule, according to the specificity rules. The only way another rule can take precedence is to have !important as well, and have higher specificity in the other less important slots.

Tips

In general you should use the amount of specificity you need, but not more. In this way, you can craft other selectors to overwrite the rules set by preceding rules without going mad.

!important is a highly debated tool that CSS offers us. Many CSS experts advocate against using it. I find myself using it especially when trying out some style and a CSS rule has so much specificity that I need to use !important to make the browser apply my new CSS.

But generally, !important should have no place in your CSS files.

Using the id attribute to style CSS is also debated a lot, since it has a very high specificity. A good alternative is to use classes instead, which have less specificity, and so they are easier to work with, and they are more powerful (you can have multiple classes for an element, and a class can be reused multiple times).

Tools to calculate the specificity

You can use the site https://specificity.keegan.st/ to perform the specificity calculation for you automatically.

It’s useful especially if you are trying to figure things out, as it can be a nice feedback tool.

INHERITANCE

When you set some properties on a selector in CSS, they are inherited by all the children of that selector.

I said some, because not all properties show this behaviour.

This happens because some properties make sense to be inherited. This helps us write CSS much more concisely, since we don’t have to explicitly set that property again on every single child.

Some other properties make more sense to not be inherited.

Think about fonts: you don’t need to apply the font-family to every single tag of your page. You set the body tag font, and every child inherits it, along with other properties.

The background-color property, on the other hand, makes little sense to be inherited.

Properties that inherit

Here is a list of the properties that do inherit. The list is non-comprehensive, but those rules are just the most popular ones you’ll likely use:

• border-collapse
• border-spacing
• caption-side
• color
• cursor
• direction
• empty-cells
• font-family
• font-size
• font-style
• font-variant
• font-weight
• font-size-adjust
• font-stretch
• font
• letter-spacing
• line-height
• list-style-image
• list-style-position
• list-style-type
• list-style
• orphans
• quotes
• tab-size
• text-align
• text-align-last
• text-decoration-color
• text-indent
• text-justify
• text-shadow
• text-transform
• visibility
• white-space
• widows
• word-break
• word-spacing

I got it from this nice Sitepoint article on CSS inheritance.

Forcing properties to inherit

What if you have a property that’s not inherited by default, and you want it to, in a child?

In the children, you set the property value to the special keyword inherit.

Example:

body {
    background-color: yellow;
}

p {
  background-color: inherit;
}

Forcing properties to NOT inherit

On the contrary, you might have a property inherited and you want to avoid so.

You can use the revert keyword to revert it. In this case, the value is reverted to the original value the browser gave it in its default stylesheet.

In practice this is rarely used, and most of the times you’ll just set another value for the property to overwrite that inherited value.

Other special values

In addition to the inherit and revert special keywords we just saw, you can also set any property to:

• initial: use the default browser stylesheet if available. If not, and if the property inherits by default, inherit the value. Otherwise do nothing.
• unset: if the property inherits by default, inherit. Otherwise do nothing.

IMPORT

From any CSS file you can import another CSS file using the @import directive.

Here is how you use it:

@import url(myfile.css)

url() can manage absolute or relative URLs.

One important thing you need to know is that @import directives must be put before any other CSS in the file, or they will be ignored.

You can use media descriptors to only load a CSS file on the specific media:

@import url(myfile.css) all;
@import url(myfile-screen.css) screen;
@import url(myfile-print.css) print;

ATTRIBUTE SELECTORS

We already introduced several of the basic CSS selectors: using element selectors, class, id, how to combine them, how to target multiple classes, how to style several selectors in the same rule, how to follow the page hierarchy with child and direct child selectors, and adjacent siblings.

In this section we’ll analyze attribute selectors, and we’ll talk about pseudo class and pseudo element selectors in the next 2 sections.

Attribute presence selectors

The first selector type is the attribute presence selector.

We can check if an element has an attribute using the [] syntax. p[id] will select all p tags in the page that have an id attribute, regardless of its value:

p[id] {
  /* ... */
}

Exact attribute value selectors

Inside the brackets you can check the attribute value using =, and the CSS will be applied only if the attribute matches the exact value specified:

p[id="my-id"] {
  /* ... */
}

Match an attribute value portion

While = lets us check for exact value, we have other operators:

• *= checks if the attribute contains the partial
• ^= checks if the attribute starts with the partial
• $= checks if the attribute ends with the partial
• |= checks if the attribute starts with the partial and it's followed by a dash (common in classes, for example), or just contains the partial
• ~= checks if the partial is contained in the attribute, but separated by spaces from the rest

All the checks we mentioned are case sensitive.

If you add an i just before the closing bracket, the check will be case insensitive. It's supported in many browsers but not in all, check https://caniuse.com/#feat=css-case-insensitive.

PSEUDO-CLASSES

Pseudo classes are predefined keywords that are used to select an element based on its state, or to target a specific child.

They start with a single colon :.

They can be used as part of a selector, and they are very useful to style active or visited links, for example, change the style on hover, focus, or target the first child, or odd rows. Very handy in many cases.

These are the most popular pseudo classes you will likely use:

Let’s do an example. A common one, actually. You want to style a link, so you create a CSS rule to target the a element:

a {
  color: yellow;
}

Things seem to work fine, until you click one link. The link goes back to the predefined color (blue) when you click it. Then when you open the link and go back to the page, now the link is blue.

Why does that happen?

Because the link when clicked changes state, and goes in the :active state. And when it's been visited, it is in the :visited state. Forever, until the user clears the browsing history.

So, to correctly make the link yellow across all states, you need to write

a,
a:visited,
a:active {
  color: yellow;
}

:nth-child() deserves a special mention. It can be used to target odd or even children with :nth-child(odd) and :nth-child(even).

It is commonly used in lists to color odd lines differently from even lines:

ul:nth-child(odd) {
  color: white;
    background-color: black;
}

You can also use it to target the first 3 children of an element with :nth-child(-n+3). Or you can style 1 in every 5 elements with :nth-child(5n).

Some pseudo classes are just used for printing, like :first, :left, :right, so you can target the first page, all the left pages, and all the right pages, which are usually styled slightly differently.

PSEUDO-ELEMENTS

Pseudo-elements are used to style a specific part of an element.

They start with a double colon ::.

Sometimes you will spot them in the wild with a single colon, but this is only a syntax supported for backwards compatibility reasons. You should use 2 colons to distinguish them from pseudo-classes.

::before and ::after are probably the most used pseudo-elements. They are used to add content before or after an element, like icons for example.

Here’s the list of the pseudo-elements:

Let’s do an example. Say you want to make the first line of a paragraph slightly bigger in font size, a common thing in typography:

p::first-line {
  font-size: 2rem;
}

Or maybe you want the first letter to be bolder:

p::first-letter {
  font-weight: bolder;
}

::after and ::before are a bit less intuitive. I remember using them when I had to add icons using CSS.

You specify the content property to insert any kind of content after or before an element:

p::before {
  content: url(/myimage.png);
}

.myElement::before {
    content: "Hey Hey!";
}

COLORS

By default an HTML page is rendered by web browsers quite sadly in terms of the colors used.

We have a white background, black color, and blue links. That’s it.

Luckily CSS gives us the ability to add colors to our designs.

We have these properties:

• color
• background-color
• border-color

All of them accept a color value, which can be in different forms.

Named colors

First, we have CSS keywords that define colors. CSS started with 16, but today there is a huge number of colors names:

• aliceblue
• antiquewhite
• aqua
• aquamarine
• azure
• beige
• bisque
• black
• blanchedalmond
• blue
• blueviolet
• brown
• burlywood
• cadetblue
• chartreuse
• chocolate
• coral
• cornflowerblue
• cornsilk
• crimson
• cyan
• darkblue
• darkcyan
• darkgoldenrod
• darkgray
• darkgreen
• darkgrey
• darkkhaki
• darkmagenta
• darkolivegreen
• darkorange
• darkorchid
• darkred
• darksalmon
• darkseagreen
• darkslateblue
• darkslategray
• darkslategrey
• darkturquoise
• darkviolet
• deeppink
• deepskyblue
• dimgray
• dimgrey
• dodgerblue
• firebrick
• floralwhite
• forestgreen
• fuchsia
• gainsboro
• ghostwhite
• gold
• goldenrod
• gray
• green
• greenyellow
• grey
• honeydew
• hotpink
• indianred
• indigo
• ivory
• khaki
• lavender
• lavenderblush
• lawngreen
• lemonchiffon
• lightblue
• lightcoral
• lightcyan
• lightgoldenrodyellow
• lightgray
• lightgreen
• lightgrey
• lightpink
• lightsalmon
• lightseagreen
• lightskyblue
• lightslategray
• lightslategrey
• lightsteelblue
• lightyellow
• lime
• limegreen
• linen
• magenta
• maroon
• mediumaquamarine
• mediumblue
• mediumorchid
• mediumpurple
• mediumseagreen
• mediumslateblue
• mediumspringgreen
• mediumturquoise
• mediumvioletred
• midnightblue
• mintcream
• mistyrose
• moccasin
• navajowhite
• navy
• oldlace
• olive
• olivedrab
• orange
• orangered
• orchid
• palegoldenrod
• palegreen
• paleturquoise
• palevioletred
• papayawhip
• peachpuff
• peru
• pink
• plum
• powderblue
• purple
• rebeccapurple
• red
• rosybrown
• royalblue
• saddlebrown
• salmon
• sandybrown
• seagreen
• seashell
• sienna
• silver
• skyblue
• slateblue
• slategray
• slategrey
• snow
• springgreen
• steelblue
• tan
• teal
• thistle
• tomato
• turquoise
• violet
• wheat
• white
• whitesmoke
• yellow
• yellowgreen

plus tranparent, and currentColor which points to the color property, for example it’s useful to make the border-color inherit it.

They are defined in the CSS Color Module, Level 4. They are case insensitive.

Wikipedia has a nice table which lets you pick the perfect color by its name.

Named colors are not the only option.

RGB and RGBa

You can use the rgb() function to calculate a color from its RGB notation, which sets the color based on its red-green-blue parts. From 0 to 255:

p {
  color: rgb(255, 255, 255); /* white */
    background-color: rgb(0, 0, 0); /* black */
}

rgba() lets you add the alpha channel to enter a transparent part. That can be a number from 0 to 1:

p {
    background-color: rgb(0, 0, 0, 0.5);
}

Hexadecimal notation

Another option is to express the RGB parts of the colors in the hexadecimal notation, which is composed by 3 blocks.

Black, which is rgb(0,0,0) is expressed as #000000 or #000 (we can shortcut the 2 numbers to 1 if they are equal).

White, rgb(255,255,255) can be expressed as #ffffff or #fff.

The hexadecimal notation lets us express a number from 0 to 255 in just 2 digits, since they can go from 0 to “15” (f).

We can add the alpha channel by adding 1 or 2 more digits at the end, for example #00000033. Not all browsers support the shortened notation, so use all 6 digits to express the RGB part.

HSL and HSLa

This is a more recent addition to CSS.

HSL = Hue Saturation Lightness.

In this notation, black is hsl(0, 0%, 0%) and white is hsl(0, 0%, 100%).

If you are more familiar with HSL than RGB because of your past knowledge, you can definitely use that.

You also have hsla() which adds the alpha channel to the mix, again a number from 0 to 1: hsl(0, 0%, 0%, 0.5)

UNITS

One of the things you’ll use every day in CSS are units. They are used to set lengths, paddings, margins, align elements and so on.

Things like px, em, rem, or percentages.

They are everywhere. There are some obscure ones, too. We’ll go through each of them in this section.

Pixels

The most widely used measurement unit. A pixel does not actually correlate to a physical pixel on your screen, as that varies, a lot, by device (think high-DPI devices vs non-retina devices).

There is a convention that make this unit work consistently across devices.

Percentages

Another very useful measure, percentages let you specify values in percentages of that parent element’s corresponding property.

Example:

.parent {
  width: 400px;
}

.child {
  width: 50%; /* = 200px */
}

Real-world measurement units

We have those measurement units which are translated from the outside world. Mostly useless on screen, they can be useful for print stylesheets. They are:

• cm a centimeter (maps to 37.8 pixels)
• mm a millimeter (0.1cm)
• q a quarter of a millimeter
• in an inch (maps to 96 pixels)
• pt a point (1 inch = 72 points)
• pc a pica (1 pica = 12 points)

Relative units

• em is the value assigned to that element's font-size, therefore its exact value changes between elements. It does not change depending on the font used, just on the font size. In typography this measures the width of the m letter.
• rem is similar to em, but instead of varying on the current element font size, it uses the root element (html) font size. You set that font size once, and rem will be a consistent measure across all the page.
• ex is like em, but instead of measuring the width of m, it measures the height of the x letter. It can change depending on the font used, and on the font size.
• ch is like ex but instead of measuring the height of x it measures the width of 0 (zero).

Viewport units

• vw the viewport width unit represents a percentage of the viewport width. 50vw means 50% of the viewport width.
• vh the viewport height unit represents a percentage of the viewport height. 50vh means 50% of the viewport height.
• vmin the viewport minimum unit represents the minimum between the height or width in terms of percentage. 30vmin is the 30% of the current width or height, depending which one is smaller
• vmax the viewport maximum unit represents the maximum between the height or width in terms of percentage. 30vmax is the 30% of the current width or height, depending which one is bigger

Fraction units

fr are fraction units, and they are used in CSS Grid to divide space into fractions.

We’ll talk about them in the context of CSS Grid later on.

URL

When we talk about background images, @import, and more, we use the url() function to load a resource:

div {
  background-image: url(test.png);
}

In this case I used a relative URL, which searches the file in the folder where the CSS file is defined.

I could go one level back

div {
  background-image: url(../test.png);
}

or go into a folder

div {
  background-image: url(subfolder/test.png);
}

Or I could load a file starting from the root of the domain where the CSS is hosted:

div {
  background-image: url(/test.png);
}

Or I could use an absolute URL to load an external resource:

div {
  background-image: url(https://mysite.com/test.png);
}

CALC

The calc() function lets you perform basic math operations on values, and it's especially useful when you need to add or subtract a length value from a percentage.

This is how it works:

div {
    max-width: calc(80% - 100px)
}

It returns a length value, so it can be used anywhere you expect a pixel value.

You can perform

• additions using +
• subtractions using -
• multiplication using *
• division using /

One caveat: with addition and subtraction, the space around the operator is mandatory, otherwise it does not work as expected.

Examples:

div {
    max-width: calc(50% / 3)
}

div {
    max-width: calc(50% + 3px)
}

BACKGROUNDS

The background of an element can be changed using several CSS properties:

• background-color
• background-image
• background-clip
• background-position
• background-origin
• background-repeat
• background-attachment
• background-size

and the shorthand property background, which allows us to shorten definitions and group them on a single line.

background-color accepts a color value, which can be one of the color keywords, or an rgb or hsl value:

p {
  background-color: yellow;
}

div {
  background-color: #333;
}

Instead of using a color, you can use an image as background to an element, by specifying the image location URL:

div {
  background-image: url(image.png);
}

background-clip lets you determine the area used by the background image, or color. The default value is border-box, which extends up to the border outer edge.

Other values are

• padding-box to extend the background up to the padding edge, without the border
• content-box to extend the background up to the content edge, without the padding
• inherit to apply the value of the parent

When using an image as background you will want to set the position of the image placement using the background-position property: left, right, center are all valid values for the X axis, and top, bottom for the Y axis:

div {
  background-position: top right;
}

If the image is smaller than the background, you need to set the behavior using background-repeat. Should it repeat-x, repeat-y or repeat on all the axes? This last one is the default value. Another value is no-repeat.

background-origin lets you choose where the background should be applied: to the entire element including padding (default) using padding-box, to the entire element including the border using border-box, to the element without the padding using content-box.

With background-attachment we can attach the background to the viewport, so that scrolling will not affect the background:

div {
  background-attachment: fixed;
}

By default the value is scroll. There is another value, local. The best way to visualize their behavior is this Codepen.

The last background property is background-size. We can use 3 keywords: auto, cover and contain. auto is the default.

cover expands the image until the entire element is covered by the background.

contain stops expanding the background image when one dimension (x or y) covers the whole smallest edge of the image, so it's fully contained into the element.

You can also specify a length value, and if so it sets the width of the background image (and the height is automatically defined):

div {
  background-size: 100%;
}

If you specify 2 values, one is the width and the second is the height:

div {
  background-size: 800px 600px;
}

The shorthand property background allows to shorten definitions and group them on a single line.

This is an example:

div {
  background: url(bg.png) top left no-repeat;
}

If you use an image, and the image could not be loaded, you can set a fallback color:

div {
  background: url(image.png) yellow;
}

You can also set a gradient as background:

div {
  background: linear-gradient(#fff, #333);
}

COMMENTS

CSS gives you the ability to write comments in a CSS file, or in the style tag in the page header

The format is the /* this is a comment */ C-style (or JavaScript-style, if you prefer) comments.

This is a multiline comment. Until you add the closing */ token, the all the lines found after the opening one are commented.

Example:

#name { display: block; } /* Nice rule! */

/* #name { display: block; } */

#name {
    display: block; /*
    color: red;
    */
}

CSS does not have inline comments, like // in C or JavaScript.

Pay attention though — if you add // before a rule, the rule will not be applied, looking like the comment worked. In reality, CSS detected a syntax error and due to how it works it ignored the line with the error, and went straight to the next line.

Knowing this approach lets you purposefully write inline comments, although you have to be careful because you can’t add random text like you can in a block comment.

For example:

// Nice rule!
#name { display: block; }

In this case, due to how CSS works, the #name rule is actually commented out. You can find more details here if you find this interesting. To avoid shooting yourself in the foot, just avoid using inline comments and rely on block comments.

CUSTOM PROPERTIES

In the last few years CSS preprocessors have had a lot of success. It was very common for greenfield projects to start with Less or Sass. And it’s still a very popular technology.

The main benefits of those technologies are, in my opinion:

• They allow you to nest selectors
• The provide an easy imports functionality
• They give you variables

Modern CSS has a new powerful feature called CSS Custom Properties, also commonly known as CSS Variables.

CSS is not a programming language like JavaScript, Python, PHP, Ruby or Go where variables are key to do something useful. CSS is very limited in what it can do, and it’s mainly a declarative syntax to tell browsers how they should display an HTML page.

But a variable is a variable: a name that refers to a value, and variables in CSS help reduce repetition and inconsistencies in your CSS, by centralizing the values definition.

And it introduces a unique feature that CSS preprocessors won’t ever have: you can access and change the value of a CSS Variable programmatically using JavaScript.

The basics of using variables

A CSS Variable is defined with a special syntax, prepending two dashes to a name (--variable-name), then a colon and a value. Like this:

:root {
  --primary-color: yellow;
}

(more on :root later)

You can access the variable value using var():

p {
  color: var(--primary-color)
}

The variable value can be any valid CSS value, for example:

:root {
  --default-padding: 30px 30px 20px 20px;
  --default-color: red;
  --default-background: #fff;
}

Create variables inside any element

CSS Variables can be defined inside any element. Some examples:

:root {
  --default-color: red;
}

body {
  --default-color: red;
}

main {
  --default-color: red;
}

p {
  --default-color: red;
}

span {
  --default-color: red;
}

a:hover {
  --default-color: red;
}

What changes in those different examples is the scope.

Variables scope

Adding variables to a selector makes them available to all the children of it.

In the example above you saw the use of :root when defining a CSS variable:

:root {
  --primary-color: yellow;
}

:root is a CSS pseudo-class that identifies the root element of a tree.

In the context of an HTML document, using the :root selector points to the html element, except that :root has higher specificity (takes priority).

In the context of an SVG image, :root points to the svg tag.

Adding a CSS custom property to :root makes it available to all the elements in the page.

If you add a variable inside a .container selector, it's only going to be available to children of .container:

.container {
  --secondary-color: yellow;
}

and using it outside of this element is not going to work.

Variables can be reassigned:

:root {
  --primary-color: yellow;
}

.container {
  --primary-color: blue;
}

Outside .container, --primary-color will be yellow, but inside it will be blue.

You can also assign or overwrite a variable inside the HTML using inline styles:

<main style="--primary-color: orange;">
  <!-- ... -->
</main>

CSS Variables follow the normal CSS cascading rules, with precedence set according to specificity.

Interacting with a CSS Variable value using JavaScript

The coolest thing with CSS Variables is the ability to access and edit them using JavaScript.

Here’s how you set a variable value using plain JavaScript:

const element = document.getElementById('my-element')
element.style.setProperty('--variable-name', 'a-value')

This code below can be used to access a variable value instead, in case the variable is defined on :root:

const styles = getComputedStyle(document.documentElement)
const value = String(styles.getPropertyValue('--variable-name')).trim()

Or, to get the style applied to a specific element, in case of variables set with a different scope:

const element = document.getElementById('my-element')
const styles = getComputedStyle(element)
const value = String(styles.getPropertyValue('--variable-name')).trim()

Handling invalid values

If a variable is assigned to a property which does not accept the variable value, it’s considered invalid.

For example you might pass a pixel value to a position property, or a rem value to a color property.

In this case the line is considered invalid and is ignored.

Browser support

Browser support for CSS Variables is very good, according to Can I Use.

CSS Variables are here to stay, and you can use them today if you don’t need to support Internet Explorer and old versions of the other browsers.

If you need to support older browsers you can use libraries like PostCSS or Myth, but you’ll lose the ability to interact with variables via JavaScript or the Browser Developer Tools, as they are transpiled to good old variable-less CSS (and as such, you lose most of the power of CSS Variables).

CSS Variables are case sensitive

This variable:

--width: 100px;

is different than this one:

--Width: 100px;

Math in CSS Variables

To do math in CSS Variables, you need to use calc(), for example:

:root {
  --default-left-padding: calc(10px * 2);
}

Media queries with CSS Variables

Nothing special here. CSS Variables normally apply to media queries:

body {
  --width: 500px;
}

@media screen and (max-width: 1000px) and (min-width: 700px) {
  --width: 800px;
}

.container {
  width: var(--width);
}

Setting a fallback value for var()

var() accepts a second parameter, which is the default fallback value when the variable value is not set:

.container {
  margin: var(--default-margin, 30px);
}

FONTS

At the dawn of the web you only had a handful of fonts you could choose from.

Thankfully today you can load any kind of font on your pages.

CSS has gained many nice capabilities over the years in regards to fonts.

The font property is the shorthand for a number of properties:

• font-family
• font-weight
• font-stretch
• font-style
• font-size

Let’s see each one of them and then we’ll cover font.

Then we’ll talk about how to load custom fonts, using @import or @font-face, or by loading a font stylesheet.

font-family

Sets the font family that the element will use.

Why “family”? Because what we know as a font is actually composed of several sub-fonts which provide all the style (bold, italic, light..) we need.

Here’s an example from my Mac’s Font Book app — the Fira Code font family hosts several dedicated fonts underneath:

This property lets you select a specific font, for example:

body {
  font-family: Helvetica;
}

You can set multiple values, so the second option will be used if the first cannot be used for some reason (if it’s not found on the machine, or the network connection to download the font failed, for example):

body {
  font-family: Helvetica, Arial;
}

I used some specific fonts up to now, ones we call Web Safe Fonts, as they are pre-installed on different operating systems.

We divide them in Serif, Sans-Serif, and Monospace fonts. Here’s a list of some of the most popular ones:

Serif

• Georgia
• Palatino
• Times New Roman
• Times

Sans-Serif

• Arial
• Helvetica
• Verdana
• Geneva
• Tahoma
• Lucida Grande
• Impact
• Trebuchet MS
• Arial Black

Monospace

• Courier New
• Courier
• Lucida Console
• Monaco

You can use all of those as font-family properties, but they are not guaranteed to be there for every system. Others exist, too, with a varying level of support.

You can also use generic names:

• sans-serif a font without ligatures
• serif a font with ligatures
• monospace a font especially good for code
• cursive used to simulate handwritten pieces
• fantasy the name says it all

Those are typically used at the end of a font-family definition, to provide a fallback value in case nothing else can be applied:

body {
  font-family: Helvetica, Arial, sans-serif;
}

font-weight

This property sets the width of a font. You can use those predefined values:

• normal
• bold
• bolder (relative to the parent element)
• lighter (relative to the parent element)

Or using the numeric keywords

• 100
• 200
• 300
• 400, mapped to normal
• 500
• 600
• 700 mapped to bold
• 800
• 900

where 100 is the lightest font, and 900 is the boldest.

Some of those numeric values might not map to a font, because that must be provided in the font family. When one is missing, CSS makes that number be at least as bold as the preceding one, so you might have numbers that point to the same font.

font-stretch

Allows you to choose a narrow or wide face of the font, if available.

This is important: the font must be equipped with different faces.

Values allowed are, from narrower to wider:

• ultra-condensed
• extra-condensed
• condensed
• semi-condensed
• normal
• semi-expanded
• expanded
• extra-expanded
• ultra-expanded

font-style

Allows you to apply an italic style to a font:

p {
  font-style: italic;
}

This property also allows the values oblique and normal. There is very little, if any, difference between using italic and oblique. The first is easier to me, as HTML already offers an i element which means italic.

font-size

This property is used to determine the size of fonts.

You can pass 2 kinds of values:

1. a length value, like px, em, rem etc, or a percentage
2. a predefined value keyword

In the second case, the values you can use are:

• xx-small
• x-small
• small
• medium
• large
• x-large
• xx-large
• smaller (relative to the parent element)
• larger (relative to the parent element)

Usage:

p {
  font-size: 20px;
}

li {
  font-size: medium;
}

font-variant

This property was originally used to change the text to small caps, and it had just 3 valid values:

• normal
• inherit
• small-caps

Small caps means the text is rendered in “smaller caps” beside its uppercase letters.

font

The font property lets you apply different font properties in a single one, reducing the clutter.

We must at least set 2 properties, font-size and font-family, the others are optional:

body {
  font: 20px Helvetica;
}

If we add other properties, they need to be put in the correct order.

This is the order:

font: <font-stretch> <font-style> <font-variant> <font-weight> <font-size> <line-height> <font-family>;

Example:

body {
  font: italic bold 20px Helvetica;
}

section {
  font: small-caps bold 20px Helvetica;
}

Loading custom fonts using @font-face

@font-face lets you add a new font family name, and map it to a file that holds a font.

This font will be downloaded by the browser and used in the page, and it’s been such a fundamental change to typography on the web — we can now use any font we want.

We can add @font-face declarations directly into our CSS, or link to a CSS dedicated to importing the font.

In our CSS file we can also use @import to load that CSS file.

A @font-face declaration contains several properties we use to define the font, including src, the URI (one or more URIs) to the font. This follows the same-origin policy, which means fonts can only be downloaded from the current origin (domain + port + protocol).

Fonts are usually in the formats

• woff (Web Open Font Format)
• woff2 (Web Open Font Format 2.0)
• eot (Embedded Open Type)
• otf (OpenType Font)
• ttf (TrueType Font)

The following properties allow us to define the properties to the font we are going to load, as we saw above:

• font-family
• font-weight
• font-style
• font-stretch

A note on performance

Of course loading a font has performance implications which you must consider when creating the design of your page.

TYPOGRAPHY

We already talked about fonts, but there’s more to styling text.

In this section we’ll talk about the following properties:

• text-transform
• text-decoration
• text-align
• vertical-align
• line-height
• text-indent
• text-align-last
• word-spacing
• letter-spacing
• text-shadow
• white-space
• tab-size
• writing-mode
• hyphens
• text-orientation
• direction
• line-break
• word-break
• overflow-wrap

text-transform

This property can transform the case of an element.

There are 4 valid values:

• capitalize to uppercase the first letter of each word
• uppercase to uppercase all the text
• lowercase to lowercase all the text
• none to disable transforming the text, used to avoid inheriting the property

Example:

p {
  text-transform: uppercase;
}

text-decoration

This property adds decorations to the text, including

• underline
• overline
• line-through
• blink
• none

Example:

p {
  text-decoration: underline;
}

You can also set the style of the decoration, and the color.

Example:

p {
  text-decoration: underline dashed yellow;
}

Valid style values are solid, double, dotted, dashed, wavy.

You can do all in one line, or use the specific properties:

• text-decoration-line
• text-decoration-color
• text-decoration-style

Example:

p {
  text-decoration-line: underline;
  text-decoration-color: yellow;
  text-decoration-style: dashed;
}

text-align

By default text align has the start value, meaning the text starts at the "start", origin 0, 0 of the box that contains it. This means top left in left-to-right languages, and top right in right-to-left languages.

Possible values are start, end, left, right, center, justify (nice to have a consistent spacing at the line ends):

p {
  text-align: right;
}

vertical-align

Determines how inline elements are vertically aligned.

We have several values for this property. First we can assign a length or percentage value. Those are used to align the text in a position higher or lower (using negative values) than the baseline of the parent element.

Then we have the keywords:

• baseline (the default), aligns the baseline to the baseline of the parent element
• sub makes an element subscripted, simulating the sub HTML element result
• super makes an element superscripted, simulating the sup HTML element result
• top align the top of the element to the top of the line
• text-top align the top of the element to the top of the parent element font
• middle align the middle of the element to the middle of the line of the parent
• bottom align the bottom of the element to the bottom of the line
• text-bottom align the bottom of the element to the bottom of the parent element font

line-height

This allows you to change the height of a line. Each line of text has a certain font height, but then there is additional spacing vertically between the lines. That’s the line height:

p {
  line-height: 0.9rem;
}

text-indent

Indent the first line of a paragraph by a set length, or a percentage of the paragraph width:

p {
  text-indent: -10px;
}

text-align-last

By default the last line of a paragraph is aligned following the text-align value. Use this property to change that behavior:

p {
  text-align-last: right;
}

word-spacing

Modifies the spacing between each word.

You can use the normal keyword, to reset inherited values, or use a length value:

p {
  word-spacing: 2px;
}

span {
  word-spacing: -0.2em;
}

letter-spacing

Modifies the spacing between each letter.

You can use the normal keyword, to reset inherited values, or use a length value:

p {
  letter-spacing: 0.2px;
}

span {
  letter-spacing: -0.2em;
}

text-shadow

Apply a shadow to the text. By default the text has no shadow.

This property accepts an optional color, and a set of values that set

• the X offset of the shadow from the text
• the Y offset of the shadow from the text
• the blur radius

If the color is not specified, the shadow will use the text color.

Examples:

p {
  text-shadow: 0.2px 2px;
}

span {
  text-shadow: yellow 0.2px 2px 3px;
}

white-space

Sets how CSS handles the white space, new lines and tabs inside an element.

Valid values that collapse white space are:

• normal collapses white space. Adds new lines when necessary as the text reaches the container end
• nowrap collapses white space. Does not add a new line when the text reaches the end of the container, and suppresses any line break added to the text
• pre-line collapses white space. Adds new lines when necessary as the text reaches the container end

Valid values that preserve white space are:

• pre preserves white space. Does not add a new line when the text reaches the end of the container, but preserves line break added to the text
• pre-wrap preserves white space. Adds new lines when necessary as the text reaches the container end

tab-size

Sets the width of the tab character. By default it’s 8, and you can set an integer value that sets the character spaces it takes, or a length value:

p {
  tab-size: 2;
}

span {
  tab-size: 4px;
}

writing-mode

Defines whether lines of text are laid out horizontally or vertically, and the direction in which blocks progress.

The values you can use are

• horizontal-tb (default)
• vertical-rl content is laid out vertically. New lines are put on the left of the previous
• vertical-lr content is laid out vertically. New lines are put on the right of the previous

hyphens

Determines if hyphens should be automatically added when going to a new line.

Valid values are

• none (default)
• manual only add an hyphen when there is already a visible hyphen or a hidden hyphen (a special character)
• auto add hyphens when determined the text can have a hyphen.

text-orientation

When writing-mode is in a vertical mode, determines the orientation of the text.

Valid values are

• mixed is the default, and if a language is vertical (like Japanese) it preserves that orientation, while rotating text written in western languages
• upright makes all text be vertically oriented
• sideways makes all text horizontally oriented

direction

Sets the direction of the text. Valid values are ltr and rtl:

p {
  direction: rtl;
}

word-break

This property specifies how to break lines within words.

• normal (default) means the text is only broken between words, not inside a word
• break-all the browser can break a word (but no hyphens are added)
• keep-all suppress soft wrapping. Mostly used for CJK (Chinese/Japanese/Korean) text.

Speaking of CJK text, the property line-break is used to determine how text lines break. I'm not an expert with those languages, so I will avoid covering it.

overflow-wrap

If a word is too long to fit a line, it can overflow outside of the container.

This property is also known as word-wrap, although that is non-standard (but still works as an alias)

This is the default behavior (overflow-wrap: normal;).

We can use:

p {
  overflow-wrap: break-word;
}

to break it at the exact length of the line, or

p {
  overflow-wrap: anywhere;
}

if the browser sees there’s a soft wrap opportunity somewhere earlier. No hyphens are added, in any case.

This property is very similar to word-break. We might want to choose this one on western languages, while word-break has special treatment for non-western languages.

BOX MODEL

Every CSS element is essentially a box. Every element is a generic box.

The box model explains the sizing of the elements based on a few CSS properties.

From the inside to the outside, we have:

• the content area
• padding
• border
• margin

The best way to visualize the box model is to open the browser DevTools and check how it is displayed:

Here you can see how Firefox tells me the properties of a span element I highlighted. I right-clicked on it, pressed Inspect Element, and went to the Layout panel of the DevTools.

See, the light blue space is the content area. Surrounding it there is the padding, then the border and finally the margin.

By default, if you set a width (or height) on the element, that is going to be applied to the content area. All the padding, border, and margin calculations are done outside of the value, so you have to keep this in mind when you do your calculation.

Later you’ll see how you can change this behavior using Box Sizing.

BORDER

The border is a thin layer between padding and margin. By editing the border, you can make elements draw their perimeter on screen.

You can work on borders by using those properties:

• border-style
• border-color
• border-width

The property border can be used as a shorthand for all those properties.

border-radius is used to create rounded corners.

You also have the ability to use images as borders, an ability given to you by border-image and its specific separate properties:

• border-image-source
• border-image-slice
• border-image-width
• border-image-outset
• border-image-repeat

Let’s start with border-style.

The border style

The border-style property lets you choose the style of the border. The options you can use are:

• dotted
• dashed
• solid
• double
• groove
• ridge
• inset
• outset
• none
• hidden

Check out this Codepen for a live example.

The default for the style is none, so to make the border appear at all you need to change it to something else. solid is a good choice most of the time.

You can set a different style for each edge using the properties

• border-top-style
• border-right-style
• border-bottom-style
• border-left-style

or you can use border-style with multiple values to define them, using the usual Top-Right-Bottom-Left order:

p {
  border-style: solid dotted solid dotted;
}

The border width

border-width is used to set the width of the border.

You can use one of the pre-defined values:

• thin
• medium (the default value)
• thick

or express a value in pixels, em or rem or any other valid length value.

Example:

p {
  border-width: 2px;
}

You can set the width of each edge (Top-Right-Bottom-Left) separately by using 4 values:

p {
  border-width: 2px 1px 2px 1px;
}

or you can use the specific edge properties border-top-width, border-right-width, border-bottom-width, border-left-width.

The border color

border-color is used to set the color of the border.

If you don’t set a color, the border by default is colored using the color of the text in the element.

You can pass any valid color value to border-color.

Example:

p {
  border-color: yellow;
}

You can set the color of each edge (Top-Right-Bottom-Left) separately by using 4 values:

p {
  border-color: black red yellow blue;
}

or you can use the specific edge properties border-top-color, border-right-color, border-bottom-color, border-left-color.

The border shorthand property

Those 3 properties mentioned, border-width, border-style and border-color can be set using the shorthand property border.

Example:

p {
  border: 2px black solid;
}

You can also use the edge-specific properties border-top, border-right, border-bottom, border-left.

Example:

p {
  border-left: 2px black solid;
  border-right: 3px red dashed;
}

The border radius

border-radius is used to set rounded corners to the border. You need to pass a value that will be used as the radius of the circle that will be used to round the border.

Usage:

p {
  border-radius: 3px;
}

You can also use the edge-specific properties border-top-left-radius, border-top-right-radius, border-bottom-left-radius, border-bottom-right-radius.

Using images as borders

One very cool thing with borders is the ability to use images to style them. This lets you go very creative with borders.

We have 5 properties:

• border-image-source
• border-image-slice
• border-image-width
• border-image-outset
• border-image-repeat

and the shorthand border-image. I won't go in much details here as images as borders would need a more in-depth coverage as what I can do in this little chapter. I recommend reading the CSS Tricks almanac entry on border-image for more information.

PADDING

The padding CSS property is commonly used in CSS to add space in the inner side of an element.

Remember:

• margin adds space outside an element border
• padding adds space inside an element border

Specific padding properties

padding has 4 related properties that alter the padding of a single edge at once:

• padding-top
• padding-right
• padding-bottom
• padding-left

The usage of those is very simple and cannot be confused, for example:

padding-left: 30px;
padding-right: 3em;

Using the padding shorthand

padding is a shorthand to specify multiple padding values at the same time, and depending on the number of values entered, it behaves differently.

1 value

Using a single value applies that to all the paddings: top, right, bottom, left.

padding: 20px;

2 values

Using 2 values applies the first to bottom & top, and the second to left & right.

padding: 20px 10px;

3 values

Using 3 values applies the first to top, the second to left & right, the third to bottom.

padding: 20px 10px 30px;

4 values

Using 4 values applies the first to top, the second to right, the third to bottom, the fourth to left.

padding: 20px 10px 5px 0px;

So, the order is top-right-bottom-left.

Values accepted

padding accepts values expressed in any kind of length unit, the most common ones are px, em, rem, but many others exist.

MARGIN

The margin CSS property is commonly used in CSS to add space around an element.

Remember:

• margin adds space outside an element border
• padding adds space inside an element border

Specific margin properties

margin has 4 related properties that alter the margin of a single edge at once:

• margin-top
• margin-right
• margin-bottom
• margin-left

The usage of those is very simple and cannot be confused, for example:

margin-left: 30px;
margin-right: 3em;

Using the margin shorthand

margin is a shorthand to specify multiple margins at the same time, and depending on the number of values entered, it behaves differently.

1 value

Using a single value applies that to all the margins: top, right, bottom, left.

margin: 20px;

2 values

Using 2 values applies the first to bottom & top, and the second to left & right.

margin: 20px 10px;

3 values

Using 3 values applies the first to top, the second to left & right, the third to bottom.

margin: 20px 10px 30px;

4 values

Using 4 values applies the first to top, the second to right, the third to bottom, the fourth to left.

margin: 20px 10px 5px 0px;

So, the order is top-right-bottom-left.

Values accepted

margin accepts values expressed in any kind of length unit, the most common ones are px, em, rem, but many others exist.

It also accepts percentage values, and the special value auto.

Using auto to center elements

auto can be used to tell the browser to select automatically a margin, and it's most commonly used to center an element in this way:

margin: 0 auto;

As said above, using 2 values applies the first to bottom & top, and the second to left & right.

The modern way to center elements is to use Flexbox, and its justify-content: center; directive.

Older browsers of course do not implement Flexbox, and if you need to support them margin: 0 auto; is still a good choice.

Using a negative margin

margin is the only property related to sizing that can have a negative value. It's extremely useful, too. Setting a negative top margin makes an element move over elements before it, and given enough negative value it will move out of the page.

A negative bottom margin moves up the elements after it.

A negative right margin makes the content of the element expand beyond its allowed content size.

A negative left margin moves the element left over the elements that precede it, and given enough negative value it will move out of the page.

BOX SIZING

The default behavior of browsers when calculating the width of an element is to apply the calculated width and height to the content area, without taking any of the padding, border and margin in consideration.

This approach has proven to be quite complicated to work with.

You can change this behavior by setting the box-sizing property.

The box-sizing property is a great help. It has 2 values:

• border-box
• content-box

content-box is the default, the one we had for ages before box-sizing became a thing.

border-box is the new and great thing we are looking for. If you set that on an element:

.my-div {
  box-sizing: border-box;
}

width and height calculation include the padding and the border. Only the margin is left out, which is reasonable since in our mind we also typically see that as a separate thing: margin is outside of the box.

This property is a small change but has a big impact. CSS Tricks even declared an international box-sizing awareness day, just saying, and it’s recommended to apply it to every element on the page, out of the box, with this:

*, *:before, *:after {
  box-sizing: border-box;
}

DISPLAY

The display property of an object determines how it is rendered by the browser.

It’s a very important property, and probably the one with the highest number of values you can use.

Those values include:

• block
• inline
• none
• contents
• flow
• flow-root
• table (and all the table-* ones)
• flex
• grid
• list-item
• inline-block
• inline-table
• inline-flex
• inline-grid
• inline-list-item

plus others you will not likely use, like ruby.

Choosing any of those will considerably alter the behavior of the browser with the element and its children.

In this section we’ll analyze the most important ones not covered elsewhere:

• block
• inline
• inline-block
• none

We’ll see some of the others in later chapters, including coverage of table, flex and grid.

inline

Inline is the default display value for every element in CSS.

All the HTML tags are displayed inline out of the box except some elements like div, p and section, which are set as block by the user agent (the browser).

Inline elements don’t have any margin or padding applied.

Same for height and width.

You can add them, but the appearance in the page won’t change — they are calculated and applied automatically by the browser.

inline-block

Similar to inline, but with inline-block width and height applied as you specify.

block

As mentioned, normally elements are displayed inline, with the exception of some elements, including

• div
• p
• section
• ul

which are set as block by the browser.

With display: block, elements are stacked one after each other, vertically, and every element takes up 100% of the page.

The values assigned to the width and height properties are respected, if you set them, along with margin and padding.

none

Using display: none makes an element disappear. It's still there in the HTML, but just not visible in the browser.

POSITIONING

Positioning is what makes us determine where elements appear on the screen, and how they appear.

You can move elements around, and position them exactly where you want.

In this section we’ll also see how things change on a page based on how elements with different position interact with each other.

We have one main CSS property: position.

It can have those 5 values:

• static
• relative
• absolute
• fixed
• sticky

Static positioning

This is the default value for an element. Static positioned elements are displayed in the normal page flow.

Relative positioning

If you set position: relative on an element, you are now able to position it with an offset, using the properties

• top
• right
• bottom
• left

which are called offset properties. They accept a length value or a percentage.

Take this example I made on Codepen. I create a parent container, a child container, and an inner box with some text:

<div class="parent">
  <div class="child">
    <div class="box">
      <p>Test</p>
    </div>
  </div>
</div>

with some CSS to give some colors and padding, but does not affect positioning:

.parent {
  background-color: #af47ff;
  padding: 30px;
  width: 300px;
}

.child {
  background-color: #ff4797;
  padding: 30px;
}

.box {
  background-color: #f3ff47;
  padding: 30px;
  border: 2px solid #333;
  border-style: dotted;
  font-family: courier;
  text-align: center;
  font-size: 2rem;
}

here’s the result:

You can try and add any of the properties I mentioned before (top, right, bottom, left) to .box, and nothing will happen. The position is static.

Now if we set position: relative to the box, at first apparently nothing changes. But the element is now able to move using the top, right, bottom, left properties, and now you can alter the position of it relatively to the element containing it.

For example:

.box {
  /* ... */
  position: relative;
  top: -60px;
}

A negative value for top will make the box move up relatively to its container.

Or

.box {
  /* ... */
  position: relative;
  top: -60px;
  left: 180px;
}

Notice how the space that is occupied by the box remains preserved in the container, like it was still in its place.

Another property that will now work is z-index to alter the z-axis placement. We'll talk about it later on.

Absolute positioning

Setting position: absolute on an element will remove it from the document's flow.

Remember in relative positioning that we noticed the space originally occupied by an element was preserved even if it was moved around?

With absolute positioning, as soon as we set position: absolute on .box, its original space is now collapsed, and only the origin (x, y coordinates) remain the same.

.box {
  /* ... */
  position: absolute;
}

We can now move the box around as we please, using the top, right, bottom, left properties:

.box {
  /* ... */
  position: absolute;
  top: 0px;
  left: 0px;
}

or

.box {
  /* ... */
  position: absolute;
  top: 140px;
  left: 50px;
}

The coordinates are relative to the closest container that is not static.

This means that if we add position: relative to the .child element, and we set top and left to 0, the box will not be positioned at the top left margin of the window, but rather it will be positioned at the 0, 0 coordinates of .child:

.child {
  /* ... */
  position: relative;
}

.box {
  /* ... */
  position: absolute;
  top: 0px;
  left: 0px;
}

Here’s how we already saw that .child is static (the default):

.child {
  /* ... */
  position: static;
}

.box {
  /* ... */
  position: absolute;
  top: 0px;
  left: 0px;
}

Like for relative positioning, you can use z-index to alter the z-axis placement.

Fixed positioning

Like with absolute positioning, when an element is assigned position: fixed it's removed from the flow of the page.

The difference with absolute positioning is this: elements are now always positioned relative to the window, instead of the first non-static container.

.box {
  /* ... */
  position: fixed;
}

.box {
  /* ... */
  position: fixed;
  top: 0;
  left: 0;
}

Another big difference is that elements are not affected by scrolling. Once you put a fixed element somewhere, scrolling the page does not remove it from the visible part of the page.

Sticky positioning

While the above values have been around for a very long time, this one was introduced recently and it’s still relatively unsupported (see caniuse.com)

The UITableView iOS component is the thing that comes to mind when I think about position: sticky. You know when you scroll in the contacts list and the first letter is stuck to the top, to let you know you are viewing that particular letter's contacts?

We used JavaScript to emulate that, but this is the approach taken by CSS to allow it natively.

FLOATING AND CLEARING

Floating has been a very important topic in the past.

It was used in lots of hacks and creative usages because it was one of the few ways, along with tables, we could really implement some layouts. In the past we used to float the sidebar to the left, for example, to show it on the left side of the screen and added some margin to the main content.

Luckily times have changed and today we have Flexbox and Grid to help us with layout, and float has gone back to its original scope: placing content on one side of the container element, and making its siblings show up around it.

The float property supports 3 values:

• left
• right
• none (the default)

Say we have a box which contains a paragraph with some text, and the paragraph also contains an image.

Here’s some code:

<div class="parent">
  <div class="child">
    <div class="box">
      <p>This is some random paragraph and an image. <img src="https://via.placeholder.com/100x100" /> The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text.
      </p>
    </div>
  </div>
</div>

.parent {
  background-color: #af47ff;
  padding: 30px;
  width: 500px;
}

.child {
  background-color: #ff4797;
  padding: 30px;
}

.box {
  background-color: #f3ff47;
  padding: 30px;
  border: 2px solid #333;
  border-style: dotted;
  font-family: courier;
  text-align: justify;
  font-size: 1rem;
}

and the visual appearance:

As you can see, the normal flow by default considers the image inline, and makes space for it in the line itself.

If we add float: left to the image, and some padding:

img {
  float: left;
  padding: 20px 20px 0px 0px;
}

this is the result:

and this is what we get by applying a float: right, adjusting the padding accordingly:

img {
  float: right;
  padding: 20px 0px 20px 20px;
}

A floated element is removed from the normal flow of the page, and the other content flows around it.

See the example on Codepen

You are not limited to floating images, too. Here we switch the image with a span element:

<div class="parent">
  <div class="child">
    <div class="box">
      <p>This is some random paragraph and an image. <span>Some text to float</span> The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text. The image is in the middle of the text.
      </p>
    </div>
  </div>
</div>

span {
  float: right;
  margin: 20px 0px 20px 20px;
  padding: 10px;
  border: 1px solid black
}

and this is the result:

Clearing

What happens when you float more than one element?

If when floated they find another floated image, by default they are stacked up one next to the other, horizontally. Until there is no room, and they will start being stacked on a new line.

Say we had 3 inline images inside a p tag:

If we add float: left to those images:

img {
  float: left;
  padding: 20px 20px 0px 0px;
}

this is what we’ll have:

if you add clear: left to images, those are going to be stacked vertically rather than horizontally:

I used the left value for clear. It allows

• left to clear left floats
• right to clear right floats
• both to clear both left and right floats
• none (default) disables clearing

Z-INDEX

When we talked about positioning, I mentioned that you can use the z-index property to control the Z axis positioning of elements.

It’s very useful when you have multiple elements that overlap each other, and you need to decide which one is visible, as nearer to the user, and which one(s) should be hidden behind it.

This property takes a number (without decimals) and uses that number to calculate which elements appear nearer to the user, in the Z axis.

The higher the z-index value, the more an element is positioned nearer to the user.

When deciding which element should be visible and which one should be positioned behind it, the browser does a calculation on the z-index value.

The default value is auto, a special keyword. Using auto, the Z axis order is determined by the position of the HTML element in the page - the last sibling appears first, as it's defined last.

By default elements have the static value for the position property. In this case, the z-index property does not make any difference - it must be set to absolute, relative or fixed to work.

Example:

.my-first-div {
    position: absolute;
    top: 0;
    left: 0;
    width: 600px;
    height: 600px;
    z-index: 10;
}

.my-second-div {
    position: absolute;
    top: 0;
    left: 0;
    width: 500px;
    height: 500px;
    z-index: 20;
}

The element with class .my-second-div will be displayed, and behind it .my-first-div.

Here we used 10 and 20, but you can use any number. Negative numbers too. It’s common to pick non-consecutive numbers, so you can position elements in the middle. If you use consecutive numbers instead, you would need to re-calculate the z-index of each element involved in the positioning.

CSS GRID

CSS Grid is the new kid in the CSS town, and while not yet fully supported by all browsers, it’s going to be the future system for layouts.

CSS Grid is a fundamentally new approach to building layouts using CSS.

Keep an eye on the CSS Grid Layout page on caniuse.com (https://caniuse.com/#feat=css-grid) to find out which browsers currently support it. At the time of writing, April 2019, all major browsers (except IE, which will never have support for it) are already supporting this technology, covering 92% of all users.

CSS Grid is not a competitor to Flexbox. They interoperate and collaborate on complex layouts, because CSS Grid works on 2 dimensions (rows AND columns) while Flexbox works on a single dimension (rows OR columns).

Building layouts for the web has traditionally been a complicated topic.

I won’t dig into the reasons for this complexity, which is a complex topic on its own. But you can think yourself as a very lucky human because nowadays you have 2 very powerful and well supported tools at your disposal:

• CSS Flexbox
• CSS Grid

These 2 are the tools to build the Web layouts of the future.

Unless you need to support old browsers like IE8 and IE9, there is no reason to be messing with things like:

• Table layouts
• Floats
• clearfix hacks
• display: table hacks

In this guide there’s all you need to know about going from zero knowledge of CSS Grid to being a proficient user.

The basics

The CSS Grid layout is activated on a container element (which can be a div or any other tag) by setting display: grid.

As with flexbox, you can define some properties on the container, and some properties on each individual item in the grid.

These properties combined will determine the final look of the grid.

The most basic container properties are grid-template-columns and grid-template-rows.

grid-template-columns and grid-template-rows

Those properties define the number of columns and rows in the grid, and they also set the width of each column/row.

The following snippet defines a grid with 4 columns each 200px wide, and 2 rows with a 300px height each.

.container {
  display: grid;
  grid-template-columns: 200px 200px 200px 200px;
  grid-template-rows: 300px 300px;
}

Here’s another example of a grid with 2 columns and 2 rows:

.container {
  display: grid;
  grid-template-columns: 200px 200px;
  grid-template-rows: 100px 100px;
}

Automatic dimensions

Many times you might have a fixed header size, a fixed footer size, and the main content that is flexible in height, depending on its length. In this case you can use the auto keyword:

.container {
  display: grid;
  grid-template-rows: 100px auto 100px;
}

Different columns and rows dimensions

In the above examples we made regular grids by using the same values for rows and the same values for columns.

You can specify any value for each row/column, to create a lot of different designs:

.container {
  display: grid;
  grid-template-columns: 100px 200px;
  grid-template-rows: 100px 50px;
}

Another example:

.container {
  display: grid;
  grid-template-columns: 10px 100px;
  grid-template-rows: 100px 10px;
}

Adding space between the cells

Unless specified, there is no space between the cells.

You can add spacing by using those properties:

• grid-column-gap
• grid-row-gap

or the shorthand syntax grid-gap.

Example:

.container {
  display: grid;
  grid-template-columns: 100px 200px;
  grid-template-rows: 100px 50px;
  grid-column-gap: 25px;
  grid-row-gap: 25px;
}

The same layout using the shorthand:

.container {
  display: grid;
  grid-template-columns: 100px 200px;
  grid-template-rows: 100px 50px;
  grid-gap: 25px;
}

Spanning items on multiple columns and/or rows

Every cell item has the option to occupy more than just one box in the row, and expand horizontally or vertically to get more space, while respecting the grid proportions set in the container.

These are the properties we’ll use for that:

• grid-column-start
• grid-column-end
• grid-row-start
• grid-row-end

Example:

.container {
  display: grid;
  grid-template-columns: 200px 200px 200px 200px;
  grid-template-rows: 300px 300px;
}

.item1 {
  grid-column-start: 2;
  grid-column-end: 4;
}

.item6 {
  grid-column-start: 3;
  grid-column-end: 5;
}

The numbers correspond to the vertical line that separates each column, starting from 1:

The same principle applies to grid-row-start and grid-row-end, except this time instead of taking more columns, a cell takes more rows.

Shorthand syntax

Those properties have a shorthand syntax provided by:

• grid-column
• grid-row

The usage is simple, here’s how to replicate the above layout:

.container {
  display: grid;
  grid-template-columns: 200px 200px 200px 200px;
  grid-template-rows: 300px 300px;
}

.item1 {
  grid-column: 2 / 4;
}

.item6 {
  grid-column: 3 / 5;
}

Another approach is to set the starting column/row, and set how many it should occupy using span:

.container {
  display: grid;
  grid-template-columns: 200px 200px 200px 200px;
  grid-template-rows: 300px 300px;
}

.item1 {
  grid-column: 2 / span 2;
}

.item6 {
  grid-column: 3 / span 2;
}

More grid configuration

Using fractions

Specifying the exact width of each column or row is not ideal in every case.

A fraction is a unit of space.

The following example divides a grid into 3 columns with the same width, 1/3 of the available space each.

.container {
  grid-template-columns: 1fr 1fr 1fr;
}

Using percentages and rem

You can also use percentages, and mix and match fractions, pixels, rem and percentages:

.container {
  grid-template-columns: 3rem 15% 1fr 2fr
}

Using repeat()

repeat() is a special function that takes a number that indicates the number of times a row/column will be repeated, and the length of each one.

If every column has the same width, you can specify the layout using this syntax:

.container {
  grid-template-columns: repeat(4, 100px);
}

This creates 4 columns with the same width.

Or using fractions:

.container {
  grid-template-columns: repeat(4, 1fr);
}

Specify a minimum width for a row

Common use case: Have a sidebar that never collapses more than a certain amount of pixels when you resize the window.

Here’s an example where the sidebar takes 1/4 of the screen and never takes less than 200px:

.container {
  grid-template-columns: minmax(200px, 3fr) 9fr;
}

You can also set just a maximum value using the auto keyword:

.container {
  grid-template-columns: minmax(auto, 50%) 9fr;
}

or just a minimum value:

.container {
  grid-template-columns: minmax(100px, auto) 9fr;
}

Positioning elements using grid-template-areas

By default elements are positioned in the grid using their order in the HTML structure.

Using grid-template-areas you can define template areas to move them around in the grid, and also to span an item on multiple rows / columns instead of using grid-column.

Here’s an example:

<div class="container">
  <main>
    ...
  </main>
  <aside>
    ...
  </aside>
  <header>
    ...
  </header>
  <footer>
    ...
  </footer>
</div>

.container {
  display: grid;
  grid-template-columns: 200px 200px 200px 200px;
  grid-template-rows: 300px 300px;
  grid-template-areas:
    "header header header header"
    "sidebar main main main"
    "footer footer footer footer";
}
main {
  grid-area: main;
}
aside {
  grid-area: sidebar;
}
header {
  grid-area: header;
}
footer {
  grid-area: footer;
}

Despite their original order, items are placed where grid-template-areas define, depending on the grid-area property associated to them.

Adding empty cells in template areas

You can set an empty cell using the dot . instead of an area name in grid-template-areas:

.container {
  display: grid;
  grid-template-columns: 200px 200px 200px 200px;
  grid-template-rows: 300px 300px;
  grid-template-areas:
    ". header header ."
    "sidebar . main main"
    ". footer footer .";
}

Fill a page with a grid

You can make a grid extend to fill the page using fr:

.container {
  display: grid;
  height: 100vh;
  grid-template-columns: 1fr 1fr 1fr 1fr;
  grid-template-rows: 1fr 1fr;
}

An example: header, sidebar, content and footer

Here is a simple example of using CSS Grid to create a site layout that provides a header op top, a main part with sidebar on the left and content on the right, and a footer afterwards.

Here’s the markup:

<div class="wrapper">
  <header>Header</header>
  <article>
    <h1>Welcome</h1>
    <p>Hi!</p>
  </article>
  <aside><ul><li>Sidebar</li></ul></aside>
  <footer>Footer</footer>
</div>

and here’s the CSS:

header {
  grid-area: header;
  background-color: #fed330;
  padding: 20px;
}
article {
  grid-area: content;
  background-color: #20bf6b;
  padding: 20px;
}
aside {
  grid-area: sidebar;
  background-color: #45aaf2;
}
footer {
  padding: 20px;
  grid-area: footer;
  background-color: #fd9644;
}
.wrapper {
  display: grid;
  grid-gap: 20px;
  grid-template-columns: 1fr 3fr;
  grid-template-areas:
    "header  header"
    "sidebar content"
    "footer  footer";
}

I added some colors to make it prettier, but basically it assigns to every different tag a grid-area name, which is used in the grid-template-areas property in .wrapper.

When the layout is smaller we can put the sidebar below the content using a media query:

@media (max-width: 500px) {
  .wrapper {
    grid-template-columns: 4fr;
    grid-template-areas:
      "header"
      "content"
      "sidebar"
      "footer";
  }
}

See on CodePen

These are the basics of CSS Grid. There are many things I didn’t include in this introduction but I wanted to make it very simple, so you can start using this new layout system without making it feel overwhelming.

FLEXBOX

Flexbox, also called Flexible Box Module, is one of the two modern layouts systems, along with CSS Grid.

Compared to CSS Grid (which is bi-dimensional), flexbox is a one-dimensional layout model. It will control the layout based on a row or on a column, but not together at the same time.

The main goal of flexbox is to allow items to fill the whole space offered by their container, depending on some rules you set.

Unless you need to support old browsers like IE8 and IE9, Flexbox is the tool that lets you forget about using

• Table layouts
• Floats
• clearfix hacks
• display: table hacks

Let’s dive into flexbox and become a master of it in a very short time.

Browser support

At the time of writing (Feb 2018), it’s supported by 97.66% of the users. All the most important browsers have implemented it for years, so even older browsers (including IE10+) are covered:

While we must wait a few years for users to catch up on CSS Grid, Flexbox is an older technology and can be used right now.

Enable Flexbox

A flexbox layout is applied to a container, by setting

display: flex;

or

display: inline-flex;

The content inside the container will be aligned using flexbox.

Container properties

Some flexbox properties apply to the container, which sets the general rules for its items. They are

• flex-direction
• justify-content
• align-items
• flex-wrap
• flex-flow

Align rows or columns

The first property we see, **flex-direction**, determines if the container should align its items as rows, or as columns:

• flex-direction: row places items as a row, in the text direction (left-to-right for western countries)
• flex-direction: row-reverse places items just like row but in the opposite direction
• flex-direction: column places items in a column, ordering top to bottom
• flex-direction: column-reverse places items in a column, just like column but in the opposite direction

Vertical and horizontal alignment

By default, items start from the left if flex-direction is row, and from the top if flex-direction is column.

You can change this behavior using justify-content to change the horizontal alignment, and align-items to change the vertical alignment.

Change the horizontal alignment

**justify-content** has 5 possible values:

• flex-start: align to the left side of the container.
• flex-end: align to the right side of the container.
• center: align at the center of the container.
• space-between: display with equal spacing between them.
• space-around: display with equal spacing around them

Change the vertical alignment

**align-items** has 5 possible values:

• flex-start: align to the top of the container.
• flex-end: align to the bottom of the container.
• center: align at the vertical center of the container.
• baseline: display at the baseline of the container.
• stretch: items are stretched to fit the container.

A note on baseline:

baseline looks similar to flex-start in this example, due to my boxes being too simple. Check out this Codepen to have a more useful example, which I forked from a Pen originally created by Martin Michálek. As you can see there, item dimensions are aligned.

Wrap

By default, items in a flexbox container are kept on a single line, shrinking them to fit in the container.

To force the items to spread across multiple lines, use flex-wrap: wrap. This will distribute the items according to the order set in flex-direction. Use flex-wrap: wrap-reverse to reverse this order.

A shorthand property called flex-flow allows you to specify flex-direction and flex-wrap in a single line, by adding the flex-direction value first, followed by flex-wrap value, for example: flex-flow: row wrap.

Properties that apply to each single item

Up to this point, we’ve seen the properties you can apply to the container.

Single items can have a certain amount of independence and flexibility, and you can alter their appearance using those properties:

• order
• align-self
• flex-grow
• flex-shrink
• flex-basis
• flex

Let’s see them in detail.

Moving items before / after another one using order

Items are ordered based on the order they are assigned. By default every item has order 0 and the appearance in the HTML determines the final order.

You can override this property using order on each separate item. This is a property you set on the item, not the container. You can make an item appear before all the others by setting a negative value.

Vertical alignment using align-self

An item can choose to override the container align-items setting, using **align-self**, which has the same 5 possible values of align-items:

• flex-start: align to the top of the container.
• flex-end: align to the bottom of the container.
• center: align at the vertical center of the container.
• baseline: display at the baseline of the container.
• stretch: items are stretched to fit the container.

Grow or shrink an item if necessary

flex-grow

The default for any item is 0.

If all items are defined as 1 and one is defined as 2, the bigger element will take the space of two “1” items.

flex-shrink

The defaut for any item is 1.

If all items are defined as 1 and one is defined as 3, the bigger element will shrink 3x the other ones. When less space is available, it will take 3x less space.

flex-basis

If set to auto, it sizes an item according to its width or height, and adds extra space based on the flex-grow property.

If set to 0, it does not add any extra space for the item when calculating the layout.

If you specify a pixel number value, it will use that as the length value (width or height depends on if it’s a row or a column item)

flex

This property combines the above 3 properties:

• flex-grow
• flex-shrink
• flex-basis

and provides a shorthand syntax: flex: 0 1 auto

TABLES

Tables in the past were greatly overused in CSS, as they were one of the only ways we could create a fancy page layout.

Today with Grid and Flexbox we can move tables back to the job they were intended to do: styling tables.

Let’s start from the HTML. This is a basic table:

<table>
  <thead>
    <tr>
      <th scope="col">Name</th>
      <th scope="col">Age</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Flavio</th>
      <td>36</td>
    </tr>
    <tr>
      <th scope="row">Roger</th>
      <td>7</td>
    </tr>
  </tbody>
</table>

By default it’s not very attractive. The browser provides some standard styles, and that’s it:

We can use CSS to style all the elements of the table, of course.

Let’s start with the border. A nice border can go a long way.

We can apply it on the table element, and on the inner elements too, like th and td:

table, th, td {
  border: 1px solid #333;
}

If we pair it with some margin, we get a nice result:

One common thing with tables is the ability to add a color to one row, and a different color to another row. This is possible using the :nth-child(odd) or :nth-child(even) selector:

tbody tr:nth-child(odd) {
  background-color: #af47ff;
}

This gives us:

If you add border-collapse: collapse; to the table element, all borders are collapsed into one:

CENTERING

Centering things in CSS is a task that is very different if you need to center horizontally or vertically.

In this post I explain the most common scenarios and how to solve them. If a new solution is provided by Flexbox I ignore the old techniques because we need to move forward, and Flexbox has been supported by browsers for years, IE10 included.

Center horizontally

Text

Text is very simple to center horizontally using the text-align property set to center:

p {
  text-align: center;
}

Blocks

The modern way to center anything that is not text is to use Flexbox:

#mysection {
  display: flex;
  justify-content: center;
}

any element inside #mysection will be horizontally centered.

Here is the alternative approach if you don’t want to use Flexbox.

Anything that is not text can be centered by applying an automatic margin to left and right, and setting the width of the element:

section {
  margin: 0 auto;
  width: 50%;
}

the above margin: 0 auto; is a shorthand for:

section {
  margin-top: 0;
  margin-bottom: 0;
  margin-left: auto;
  margin-right: auto;
}

Remember to set the item to display: block if it's an inline element.

Center vertically

Traditionally this has always been a difficult task. Flexbox now provides us a great way to do this in the simplest possible way:

#mysection {
  display: flex;
  align-items: center;
}

any element inside #mysection will be vertically centered.

Center both vertically and horizontally

Flexbox techniques to center vertically and horizontally can be combined to completely center an element in the page.

#mysection {
  display: flex;
  align-items: center;
  justify-content: center;
}

The same can be done using CSS Grid:

body {
  display: grid;
  place-items: center;
  height: 100vh;
}

LISTS

Lists are a very important part of many web pages.

CSS can style them using several properties.

list-style-type is used to set a predefined marker to be used by the list:

li {
  list-style-type: square;
}

We have lots of possible values, which you can see here https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-type with examples of their appearance. Some of the most popular ones are disc, circle, square and none.

list-style-image is used to use a custom marker when a predefined marker is not appropriate:

li {
  list-style-image: url(list-image.png);
}

list-style-position lets you add the marker outside (the default) or inside of the list content, in the flow of the page rather than outside of it

li {
  list-style-position: inside;
}

The list-style shorthand property lets us specify all those properties in the same line:

li {
  list-style: url(list-image.png) inside;
}

MEDIA QUERIES AND RESPONSIVE DESIGN

In this section we’re going to first introduce media types and media feature descriptors, then we’ll explain media queries.

Media types

Used in media queries and @import declarations, media types allow us to determine on which media a CSS file, or a piece of CSS, is loaded.

We have the following media types

• all means all the media
• print used when printing
• screen used when the page is presented on a screen
• speech used for screen readers

screen is the default.

In the past we had more of them, but most are deprecated as they proved to be ineffective ways of determining device needs.

We can use them in @import statements like this:

@import url(myfile.css) screen;
@import url(myfile-print.css) print;

We can load a CSS file on multiple media types separating each with a comma:

@import url(myfile.css) screen, print;

The same works for the link tag in HTML:

<link rel="stylesheet" type="text/css" href="myfile.css" media="screen" />
<link rel="stylesheet" type="text/css" href="another.css" media="screen, print" />

We’re not limited to just using media types in the media attribute and in the @import declaration. There's more.

Media feature descriptors

First, let’s introduce media feature descriptors. They are additional keywords that we can add to the media attribute of link or the the @import declaration, to express more conditionals over the loading of the CSS.

Here’s the list of them:

• width
• height
• device-width
• device-height
• aspect-ratio
• device-aspect-ratio
• color
• color-index
• monochrome
• resolution
• orientation
• scan
• grid

Each of them has a corresponding min- and max-, for example:

• min-width, max-width
• min-device-width, max-device-width

and so on.

Some of those accept a length value which can be expressed in px or rem or any length value. It's the case of width, height, device-width, device-height.

For example:

@import url(myfile.css) screen and (max-width: 800px);

Notice that we wrap each block using media feature descriptors in parentheses.

Some accept a fixed value. orientation, used to detect the device orientation, accepts portrait or landscape.

Example:

<link rel="stylesheet" type="text/css" href="myfile.css" media="screen and (orientation: portrait)" />

scan, used to determine the type of screen, accepts progressive (for modern displays) or interlace (for older CRT devices).

Some others want an integer.

Like color which inspects the number of bits per color component used by the device. Very low-level, but you just need to know it's there for your usage (like grid, color-index, monochrome).

aspect-ratio and device-aspect-ratio accept a ratio value representing the width to height viewport ratio, which is expressed as a fraction.

Example:

@import url(myfile.css) screen and (aspect-ratio: 4/3);

resolution represents the pixel density of the device, expressed in a resolution data type like dpi.

Example:

@import url(myfile.css) screen and (min-resolution: 100dpi);

Logic operators

We can combine rules using and:

<link rel="stylesheet" type="text/css" href="myfile.css" media="screen and (max-width: 800px)" />

We can perform an “or” type of logic operation using commas, which combines multiple media queries:

@import url(myfile.css) screen, print;

We can use not to negate a media query:

@import url(myfile.css) not screen;

Important: not can only be used to negate an entire media query, so it must be placed at the beginning of it (or after a comma).

Media queries

All those above rules we saw applied to @import or the the link HTML tag can be applied inside the CSS, too.

You need to wrap them in a @media () {} structure.

Example:

@media screen and (max-width: 800px) {
  /* enter some CSS */
}

and this is the foundation for responsive design.

Media queries can be quite complex. This example applies the CSS only if it’s a screen device, the width is between 600 and 800 pixels, and the orientation is landscape:

@media screen and (max-width: 800px) and (min-width: 600px) and (orientation: landscape) {
  /* enter some CSS */
}

FEATURE QUERIES

Feature queries are a recent and relatively unknown ability of CSS, but a well supported one.

We can use it to check if a feature is supported by the browser using the @supports keyword.

I think this is especially useful, at the time of writing, for checking if a browser supports CSS grid, for example, which can be done using:

@supports (display: grid) {
  /* apply this CSS */
}

We check if the browser supports the grid value for the display property.

We can use @supports for any CSS property, to check any value.

We can also use the logical operators and, or and not to build complex feature queries:

@supports (display: grid) and (display: flex) {
  /* apply this CSS */
}

FILTERS

Filters allow us to perform operations on elements.

Things you normally do with Photoshop or other photo editing software, like changing the opacity or the brightness, and more.

You use the filter property. Here's an example of it applied on an image, but this property can be used on any element:

img {
  filter: <something>;
}

You can use various values here:

• blur()
• brightness()
• contrast()
• drop-shadow()
• grayscale()
• hue-rotate()
• invert()
• opacity()
• sepia()
• saturate()
• url()

Notice the parentheses after each option, because they all require a parameter.

For example:

img {
  filter: opacity(0.5);
}

means the image will be 50% transparent, because opacity() takes one value from 0 to 1, or a percentage.

You can also apply multiple filters at once:

img {
  filter: opacity(0.5) blur(2px);
}

Let’s now talk about each filter in detail.

blur()

Blurs an element content. You pass it a value, expressed in px or em or rem that will be used to determine the blur radius.

Example:

img {
  filter: blur(4px);
}

opacity()

opacity() takes one value from 0 to 1, or a percentage, and determines the image transparency based on it.

0, or 0%, means totally transparent. 1, or 100%, or higher, means totally visible.

Example:

img {
  filter: opacity(0.5);
}

CSS also has an opacity property. filter however can be hardware accelerated, depending on the implementation, so this should be the preferred method.

drop-shadow()

drop-shadow() shows a shadow behind the element, which follows the alpha channel. This means that if you have a transparent image, you get a shadow applied to the image shape, not the image box. If the image does not have an alpha channel, the shadow will be applied to the entire image box.

It accepts a minimum of 2 parameters, up to 5:

• offset-x sets the horizontal offset. Can be negative.
• offset-y sets the vertical offset. Can be negative.
• blur-radius, optional, sets the blur radius for the shadow. It defaults to 0, no blur.
• spread-radius, optional, sets the spread radius. Expressed in px, rem or em
• color, optional, sets the color of the shadow.

You can set the color without setting the spread radius or blur radius. CSS understands the value is a color and not a length value.

Example:

img {
  filter: drop-shadow(10px 10px 5px orange);
}

img {
  filter: drop-shadow(10px 10px orange);
}

img {
  filter: drop-shadow(10px 10px 5px 5px #333);
}

grayscale()

Makes the element have a gray color.

You pass one value from 0 to 1, or from 0% to 100%, where 1 and 100% mean completely gray, and 0 or 0% mean the image is not touched, and the original colors remain.

Example:

img {
  filter: grayscale(50%);
}

sepia()

Makes the element have a sepia color.

You pass one value from 0 to 1, or from 0% to 100%, where 1 and 100% mean completely sepia, and 0 or 0% mean the image is not touched, and the original colors remain.

Example:

img {
  filter: sepia(50%);
}

invert()

Invert the colors of an element. Inverting a color means looking up the opposite of a color in the HSL color wheel. Just search “color wheel” in Google if you have no idea what that means. For example, the opposite of yellow is blue, the opposite of red is cyan. Every single color has an opposite.

You pass a number, from 0 to 1 or from 0% to 100%, that determines the amount of inversion. 1 or 100% means full inversion, 0 or 0% means no inversion.

0.5 or 50% will always render a 50% gray color, because you always end up in the middle of the wheel.

Example:

img {
  filter: invert(50%);
}

hue-rotate()

The HSL color wheel is represented in degrees. Using hue-rotate() you can rotate the color using a positive or negative rotation.

The function accepts a deg value.

Example:

img {
  filter: hue-rotate(90deg);
}

brightness()

Alters the brightness of an element.

0 or 0% gives a total black element. 1 or 100% gives an unchanged image.

Values higher than 1 or 100% make the image brighter up to reaching a total white element.

Example:

img {
  filter: brightness(50%);
}

contrast()

Alters the contrast of an element.

0 or 0% gives a total gray element. 1 or 100% gives an unchanged image.

Values higher than 1 or 100% give more contrast.

Example:

img {
  filter: contrast(150%);
}

saturate()

Alters the saturation of an element.

0 or 0% gives a total grayscale element (with less saturation). 1 or 100% gives an unchanged image.

Values higher than 1 or 100% give more saturation.

Example:

img {
  filter: saturate();
}

url()

This filter allows to apply a filter defined in an SVG file. You point to the SVG file location.

Example:

img {
  filter: url(filter.svg);
}

SVG filters are out of the scope of this piece, but you can read more on this Smashing Magazine post: https://www.smashingmagazine.com/2015/05/why-the-svg-filter-is-awesome/

TRANSFORMS

Transforms allow you to translate, rotate, scale, and skew elements, in the 2D or 3D space. They are a very cool CSS feature, especially when combined with animations.

2D transforms

The transform property accepts those functions:

• translate() to move elements around
• rotate() to rotate elements
• scale() to scale elements in size
• skew() to twist or slant an element
• matrix() a way to perform any of the above operations using a matrix of 6 elements, a less user friendly syntax but less verbose

We also have axis-specific functions:

• translateX() to move elements around on the X axis
• translateY() to move elements around on the Y axis
• scaleX() to scale elements in size on the X axis
• scaleY() to scale elements in size on the Y axis
• skewX() to twist or slant an element on the X axis
• skewY() to twist or slant an element on the Y axis

Here is an example of a transform which changes the .box element width by 2 (duplicating it) and the height by 0.5 (reducing it to half):

.box {
    transform: scale(2, 0.5);
}

[transform-origin](https://developer.mozilla.org/en-US/docs/Web/CSS/transform-origin) lets us set the origin (the (0, 0) coordinates) for the transformation, letting us change the rotation center.

Combining multiple transforms

You can combine multiple transforms by separating each function with a space.

For example:

transform: rotateY(20deg) scaleX(3) translateY(100px);

3D transforms

We can go one step further and move our elements in a 3D space instead of in a 2D space. With 3D, we are adding another axis, Z, which adds depth to our visuals.

Using the perspective property you can specify how far the 3D object is from the viewer.

Example:

.3Delement {
  perspective: 100px;
}

perspective-origin determines the appearance of the position of the viewer, how are we looking at it in the X and Y axis.

Now we can use additional functions that control the Z axis, and that add up to the other X and Y axis transforms:

• translateZ()
• rotateZ()
• scaleZ()

and the corresponding shorthands translate3d(), rotate3d() and scale3d() as shorthands for using the translateX(), translateY() and translateZ() functions and so on.

3D transforms are a bit too advanced for this handbook, but are a great topic to explore on your own.

TRANSITIONS

CSS Transitions are the simplest way to create an animation in CSS.

In a transition, you change the value of a property, and you tell CSS to slowly change it according to some parameters, towards a final state.

CSS Transitions are defined by these properties:

The transition property is a handy shorthand:

.container {
  transition: property
              duration
              timing-function
              delay;
}

Example of a CSS Transition

This code implements a CSS Transition:

.one,
.three {
  background: rgba(142, 92, 205, .75);
  transition: background 1s ease-in;
}

.two,
.four {
  background: rgba(236, 252, 100, .75);
}

.circle:hover {
  background: rgba(142, 92, 205, .25); /* lighter */
}

See the example on Glitch https://flavio-css-transitions-example.glitch.me

When hovering the .one and .three elements, the purple circles, there is a transition animation that eases the change of background, while the yellow circles do not, because they do not have the transition property defined.

Transition timing function values

transition-timing-function allows you to specify the acceleration curve of the transition.

There are some simple values you can use:

• linear
• ease
• ease-in
• ease-out
• ease-in-out

This Glitch shows how these work in practice.

You can create a completely custom timing function using cubic bezier curves. This is rather advanced, but basically any of those functions above are built using bezier curves. We have handy names as they are common ones.

CSS Transitions in Browser DevTools

The Browser DevTools offer a great way to visualize transitions.

This is Chrome:

This is Firefox:

From those panels you can live edit the transition and experiment in the page directly without reloading your code.

Which Properties you can Animate using CSS Transitions

A lot! They are the same you can animate using CSS Animations, too.

Here’s the full list:

• background
• background-color
• background-position
• background-size
• border
• border-color
• border-width
• border-bottom
• border-bottom-color
• border-bottom-left-radius
• border-bottom-right-radius
• border-bottom-width
• border-left
• border-left-color
• border-left-width
• border-radius
• border-right
• border-right-color
• border-right-width
• border-spacing
• border-top
• border-top-color
• border-top-left-radius
• border-top-right-radius
• border-top-width
• bottom
• box-shadow
• caret-color
• clip
• color
• column-count
• column-gap
• column-rule
• column-rule-color
• column-rule-width
• column-width
• columns
• content
• filter
• flex
• flex-basis
• flex-grow
• flex-shrink
• font
• font-size
• font-size-adjust
• font-stretch
• font-weight
• grid-area
• grid-auto-columns
• grid-auto-flow
• grid-auto-rows
• grid-column-end
• grid-column-gap
• grid-column-start
• grid-column
• grid-gap
• grid-row-end
• grid-row-gap
• grid-row-start
• grid-row
• grid-template-areas
• grid-template-columns
• grid-template-rows
• grid-template
• grid
• height
• left
• letter-spacing
• line-height
• margin
• margin-bottom
• margin-left
• margin-right
• margin-top
• max-height
• max-width
• min-height
• min-width
• opacity
• order
• outline
• outline-color
• outline-offset
• outline-width
• padding
• padding-bottom
• padding-left
• padding-right
• padding-top
• perspective
• perspective-origin
• quotes
• right
• tab-size
• text-decoration
• text-decoration-color
• text-indent
• text-shadow
• top
• transform.
• vertical-align
• visibility
• width
• word-spacing
• z-index

ANIMATIONS

CSS Animations are a great way to create visual animations, not limited to a single movement like CSS Transitions, but much more articulated.

An animation is applied to an element using the animation property.

.container {
  animation: spin 10s linear infinite;
}

spin is the name of the animation, which we need to define separately. We also tell CSS to make the animation last 10 seconds, perform it in a linear way (no acceleration or any difference in its speed) and to repeat it infinitely.

You must define how your animation works using keyframes. Example of an animation that rotates an item:

@keyframes spin {
  0% {
    transform: rotateZ(0);
  }
  100% {
    transform: rotateZ(360deg);
  }
}

Inside the @keyframes definition you can have as many intermediate waypoints as you want.

In this case we instruct CSS to make the transform property to rotate the Z axis from 0 to 360 grades, completing the full loop.

You can use any CSS transform here.

Notice how this does not dictate anything about the temporal interval the animation should take. This is defined when you use it via animation.

A CSS Animations Example

I want to draw four circles, all with a starting point in common, all 90 degrees distant from each other.

<div class="container">
  <div class="circle one"></div>
  <div class="circle two"></div>
  <div class="circle three"></div>
  <div class="circle four"></div>
</div>

body {
  display: grid;
  place-items: center;
  height: 100vh;
}

.circle {
  border-radius: 50%;
  left: calc(50% - 6.25em);
  top: calc(50% - 12.5em);
  transform-origin: 50% 12.5em;
  width: 12.5em;
  height: 12.5em;
  position: absolute;
  box-shadow: 0 1em 2em rgba(0, 0, 0, .5);
}

.one,
.three {
  background: rgba(142, 92, 205, .75);
}

.two,
.four {
  background: rgba(236, 252, 100, .75);
}

.one {
  transform: rotateZ(0);
}

.two {
  transform: rotateZ(90deg);
}

.three {
  transform: rotateZ(180deg);
}

.four {
  transform: rotateZ(-90deg);
}

You can see them in this Glitch: https://flavio-css-circles.glitch.me

Let’s make this structure (all the circles together) rotate. To do this, we apply an animation on the container, and we define that animation as a 360 degree rotation:

@keyframes spin {
  0% {
    transform: rotateZ(0);
  }
  100% {
    transform: rotateZ(360deg);
  }
}

.container {
  animation: spin 10s linear infinite;
}

See it on https://flavio-css-animations-tutorial.glitch.me

You can add more keyframes to have funnier animations:

@keyframes spin {
  0% {
    transform: rotateZ(0);
  }
  25% {
    transform: rotateZ(30deg);
  }
  50% {
    transform: rotateZ(270deg);
  }
  75% {
    transform: rotateZ(180deg);
  }
  100% {
    transform: rotateZ(360deg);
  }
}

See the example on https://flavio-css-animations-four-steps.glitch.me

The CSS animation properties

CSS animations offers a lot of different parameters you can tweak:

The animation property is a shorthand for all these properties, in this order:

.container {
  animation: name
             duration
             timing-function
             delay
             iteration-count
             direction
             fill-mode
             play-state;
}

This is the example we used above:

.container {
  animation: spin 10s linear infinite;
}

JavaScript events for CSS Animations

Using JavaScript you can listen for the following events:

• animationstart
• animationend
• animationiteration

Be careful with animationstart, because if the animation starts on page load, your JavaScript code is always executed after the CSS has been processed, so the animation is already started and you cannot intercept the event.

const container = document.querySelector('.container')

container.addEventListener('animationstart', (e) => {
  //do something
}, false)

container.addEventListener('animationend', (e) => {
  //do something
}, false)

container.addEventListener('animationiteration', (e) => {
  //do something
}, false)