For example, if you’re designing a card, what dimensions should the container be? What should be the width and height of the buttons? After that, what should the margin spacing be between all the elements within the card? Designing without clear constraints leads to decision fatigue and wasted time on minor details.

These card containers and buttons have different pixel sizes and spacing. Still, it’s hard to decide which design to go with because they look similar. How do you decide when there are so many arbitrary values and variations available? The answer is to build your own sizing and spacing system.

Building the System

Don’t struggle with arbitrary values when sizing or spacing elements. Instead, limit yourself to a predefined set of options to reduce decision-making time and ensure consistency across all elements and components.

Start with a sensible base value and then build a scale using factors and multiples of that value. A good base value is 12px because it’s a highly composite number with more divisors than any smaller number (1, 2, 3, 4, 6, 12). This makes it a foundational unit for various systems, including time (12 hours in a day/12 months in a year) and measurement (12 inches in a foot and a dozen).

It’s not as straightforward as just using multiples of 6 and 12, as there would still be too many options to choose from. For the system to be effective, it must consider the relative differences between adjacent values.

For instance, the relative difference between 48px and 60px avatars is 25%. However, the relative difference between a 480px and a 504px card width is 5%. This means the 5% difference is five times less significant than the increase from 48px to 60px.

In other words, the values at the lower end of the scale should be packed together because they have a high relative difference. On the contrary, those higher up the scale should be more spaced apart because they have a low relative difference. The key is determining how close or far adjacent values should be.

The Scale

The entire scale has a harmony and rhythm that can only be perceived mathematically. At the lowest end of the scale, the multiplier increases by 0.5 from 6px to 36px. From there, the multiplier grows by 1 up to 120px.

From 120px to 240px, the multiplier growth is 2. However, the multiplier growth is 5 as it progresses toward the higher end of the scale. Notice how the multiplier increases incrementally as it scales from low to mid to high.

Here’s how the complete scale looks. It stops at 780px but can be extended if needed. The multiplier growth would eventually increase from 5 to 10 and beyond.

Applying the System

Once you’ve established your spacing and sizing system, you’ll find that designing becomes much faster. Suppose you want to design a card and need to choose values for its elements. Simply take them from the predefined scale and test them out. Since you’ve already done the foundational work, decision-making becomes easier because you’re working from a smaller set of options.

This card is using sizing and spacing values from the system. Everything looks good except the card is too big. Instead of redefining the values for every element, all you have to do is pick the next value down in the scale from your original starting point.

The container goes from 480x360px to 420x300px. The avatar goes from 60x60px to 48x48px. The data boxes go from 192x96px to 168x72px. Even the width of the action buttons is one step down. However, the badge buttons remain the same because they take up minimal space.

Reducing the size of elements in a card often leads to uneven spacing. However, in this instance, the spacing values are perfectly aligned with the system. This consistent harmony is due to the appropriate sizing values. Once you take care of the sizing, the spacing tends to fall into place.

Finding the Optimal Range

This next example is a card for an e-commerce product. Start by determining which elements you’ll need. In this case, it’s a card container, a divider line, a title box, a color selector, a size selector, and an “Add to Cart” button.

Start with a container size that matches the product image since they’ll be married together. Then pick a divider line width that allows ample margins. Since the container width is 480px, all you have to do is scale it down one level to 420px. This results in 30px margins, which is sufficient.

Now you need to determine the appropriate size for the other elements. This task is simple because you can identify an optimal range on the scale that fits within the container’s dimensions. Since you’ll be stacking multiple elements vertically, their size shouldn’t be too large. However, if they’re too small, users may have difficulty clicking on them.

After trying different values, the optimal size range on the scale is between 30px and 48px, since 24px is too small and 60px is too large. Therefore, the ideal sizes to consider are 30px, 36px, and 48px. You can see how well that looks in the example.

The next step is to arrange the elements with optimal spacing. The ideal spacing range appears to be between 18px and 30px, as the outer options are either too small or too large. If one of the outer options looks best, do another comparison using that option as the “middle” value to ensure there are no better choices.

The optimal values for your design won’t always be adjacent on the scale. However, you’ll find this more common with spacing than with sizing. Generally, the heights of your elements should be more closely aligned, but the widths of your elements can have a broader range.

This sizing and spacing system will help you create better designs with less effort and time. By narrowing your options from a limitless pool, you’ll not only make decisions faster but also design with mathematical harmony and consistency.

The first thing to consider is the user’s task flow and default state. They start by creating a document and clicking the “Share” button to collaborate. This action opens the “Share” modal, where they can invite people or share a link.

The modal’s title displays the document’s name. Below that is the “Invite” text field, which contains a permissions menu and an action button. Below the field is the “Share Link” section, which also includes a permissions menu and an action button.

As you can see, there’s a design pattern here between the two, which means they need to share a similar structure. You have the field component on the left, followed by the permissions menu and the action button. Laying these elements out consistently makes the interface more intuitive.

Opening the permissions menu for the invite field allows the user to assign a role to the person they invite: Viewer, Editor, or Commenter. However, the permissions menu for the link field differs slightly. Instead of role names, use “Can View/Edit/Comment” for clearer language. As the permissions change, the text indicating the state also changes: “Anyone with the link can view/edit/comment.”

There is one permission that acts as a disabled state: the “Restricted” option. When that’s selected, the text indicates that “Only invited people can access.” In other words, the share link access will be revoked globally, and users will see an access denied page the next time they click it.

When people have accepted the invite, a list populates under the “Invite” field. The title displays the number of people who have access. The document owner is highlighted with an “Owner” badge. Each team member’s avatar, name, and email are displayed along with a permissions menu. The menu displays their current role. Clicking the menu lets you switch their role or remove their access.

Your users might not always have an avatar photo uploaded. In this case, you can use a color fill with their initials for their avatar. This allows users to view each other as unique entities when their personal photo isn’t available.

Another state to consider is the “Pending” state for people who have been invited but have not yet accepted. The badge indicates when people can or can’t access the document. It offers a “Resend” button to resend the invite if they didn’t receive it. There’s also an X button to cancel the invite if an issue occurs.

Designing a share modal that looks and feels intuitive requires careful thought and attention to detail. To do it well, you must consider the invite flow, permission changes, pending invites, and missing avatars. Getting these details right is what separates a frustrating sharing experience from a seamless one.

3 Separate Fields

Separating the date input into three fields increases cognitive load with no real benefit. Most users think of a date as a single entity, so fragmenting it into month, day, and year fields breaks that mental model and forces artificial pauses mid-entry.

Instead of typing a date in a single fluid motion, users have to click or tab between the fields. Less tech savvy users will actually click the next field which greatly slows down the task completion. Power users may press the tab key but that’s still an extra keystroke that requires additional effort and mental preparation.

Input validation and accessibility suffer as well. With a single field, it’s clear where the error message belongs. With three fields, designers have to decide whether to flag the first field, all three, or add a message beneath the group. Screen readers face a similar problem. Without careful ARIA labeling, the relationship between the fields may not be announced clearly.

3 Select Menus

When all three fields are select menus, the problems compound significantly. Selecting a date this way requires at least three separate interactions repeated across month, day, and year — open a menu, scroll to a value, select it. That’s a minimum of nine actions to enter a single piece of information, compared to typing six or eight characters in a plain text field.

There’s also a mismatch between the control and the task. Dropdowns are designed for choosing between a small number of options. A day field with 31 options, or a year field spanning decades, is pushing the format well past its intended use. Users end up scrolling through long lists for information they already know. The year field is the worst offender because users may be scrolling through a list of 50-100 options.

1 Field with Hint Text

A single text field with hint text but no constraints feels like the most permissive approach, but permissive isn’t the same as forgiving. Without any format enforcement, users will enter dates however they feel most natural. This creates a parsing nightmare on the backend and makes consistent validation extremely difficult.

Hint text may help, but users often ignore it. Studies consistently show that placeholder text inside a field disappears the moment a user starts typing. Placing the hint text outside the field isn’t much better because users either don’t read it or forget the format halfway through entry.

1 Field with Segmented Input Mask

An input mask that automatically inserts slashes and segments focus across month, day, and year is a far better approach. The input mask enforces the format structure, so there’s no confusion about whether to use slashes or dashes, whether the day or month comes first, or whether the year should be two or four digits.

Users see “MM/DD/YYYY” and start typing right away without having to think about the format. As soon as they finish entering the month, the focus automatically shifts to the day segment, then to the year, mimicking the feel of tabbing between fields without the extra effort.

The date stays visually cohesive, the cursor never has to leave the field, and the whole interaction can be completed with a single burst of keyboard entry. Entering a date this way is as fast as freeform typing and significantly faster than select menus.

The format hint remains visually persistent rather than disappearing on focus like the placeholder text does. Since the input is a single field, screen readers will treat it as a coherent unit rather than having to piece together meaning from three separate fields.

If you want users to select a date in the near future, you can offer them a calendar widget. Place a calendar icon to the far right of the input. When users click it, it’ll display a calendar widget that lets them select a specific date instead of typing it. This approach is best for scheduling tasks where the date input is initially unknown.

The bad patterns of separate fields, select menus, and unconstrained text inputs each introduce friction in different ways. A single field with a segmented input mask gives users the speed and simplicity of free text entry with just enough structure. This makes it the best pattern for entering date inputs on forms.

Look at how many dividers and containers can end up in a single layout. When there are almost as many structural elements as there are pieces of data, the result is clutter. Instead of guiding the eye, all those lines create visual noise that gets in the user’s way.

Cut Redundant Dividers

A common mistake is placing line dividers beneath elements that already have borders. Chip buttons, for example, have their own borders that act as dividers, especially combined with surrounding whitespace. Adding a line below them is redundant.

The same logic applies to containers. A container already has a border, so placing a line divider directly above or below it serves no purpose. As a rule, never use a line divider before or after a container. It only adds more noise.

You also don’t need a divider to separate a title from its controls. If there’s enough whitespace, the spacing does the job on its own. Once you strip out the unnecessary dividers, the improvement is immediate — more clarity, less noise.

Where to Use Dividers

The one place where line dividers work well is inside containers to separate rows of tabular data. Think of a table where the label sits on the left and its value on the right—that’s the proper context for dividers. Outside of that, if you’re already using containers, you don’t need them.

Color Fill the Containers

Containers without a color fill can look too similar to dividers. More outlines floating on the page just adds to the noise. Adding a fill to the container distinguishes them and establishes visual hierarchy.

The most important container should have the strongest color contrast. On a light background, that means a darker fill; on a dark background, a lighter one. Less important containers should recede with a more subtle fill.

This way, the user’s eye is naturally drawn to what matters most, and the supporting information stays out of the way without disappearing. A simple starting point is to use light-gray containers on a white background, or white containers on a light-gray background.

Use line dividers sparingly. If you’re using containers, their borders already handle separation. Dividers become redundant everywhere except inside tabular layouts. An interface full of outlines but no color fill creates visual noise that slows users down. Color-filled containers reduce distractions, establish hierarchy, and guide attention along a clear path.

One reason for this confusion is that the account menu is in the same area as the page-level actions. The account menu is a global control with actions that apply system-wide. Placing it close to page-level actions can lead users to think the account menu is also page-level, which can cause interaction issues.

Not only that, but when you put the account menu at the top, you’re creating two separate locations to access global controls. When users perform global tasks, they’ll have to scan both the sidebar and the navigation bar to find the right item. Is the item on the left or at the top?

A much better location for the account menu is at the bottom of the sidebar. When all global actions are on the left, it allows a more dedicated space for page-level actions. Users will know for sure that the buttons at the top are contextual to what they’re currently viewing. There’s no room for confusion when global and page-level actions are spatially separated.

Other user-related actions, such as notifications, help, and settings, can fit above the account menu. Keep some white space between these items and the primary navigation items. If you have a search bar, you can place it at the top of the sidebar. In other words, the sidebar usually has enough room to house all the items from the navigation bar.

If your app’s primary navigation is at the top, it makes more sense to place the account menu in the top-right corner. A bottom account menu works better when the primary navigation is a persistent sidebar.

No matter what type of navigation you’re using, the principle remains the same: never mix global and page-level actions at the same navigational level. Keep them visually and spatially separate for a better user experience.

It’s not enough to place a “My Account” button in the navigation bar with a list of menu items. In fact, this creates a poor user experience that requires much time and effort to interact with. Your design needs to do more to help users perform their account tasks efficiently.

Think about what the user has to go through. They have to search for the account button in the navigation and open the menu. As they scan the long list, they need to think about what each item means. If they’re not sure, they need more time to think it over. All of this increases the cognitive load when managing their account.

The first thing you need to do to make the “Account” button easier to recognize at a glance is to use an avatar. An avatar displays the user’s photo and name. It can also include their email or username below the name. When users see this, it’s obvious where they need to go to access their account.

If the user hasn’t uploaded an avatar image yet, you can display their initials or a placeholder icon instead. Either way, you’re using familiar visual cues to help the user recognize where to manage their account. A button label that says “Account” is simply not clear enough.

After users click their avatar, a long menu of items will only overwhelm them. To reduce cognitive load, place key menu items in the navigation bar next to the avatar. Commonly used items such as settings, notifications, and help & support are quicker and easier to access when they aren’t hidden inside the menu.

Having fewer menu items does take some load off, but users still need to think about what certain items mean if it isn’t obvious. To make this easier, you should include an icon and subtext for each item. This clears up any confusion when users perform their account tasks.

The icons provide a contextual cue for visual recognition. The subtext clarifies what is involved with each item, so users don’t have to think about it. The “Log Out” item is red, positioned last, and separated by a divider line to distinguish it as a destructive action that deauthenticates the user.

By following these design practices, you’ll create a far better account menu experience. Managing an account is crucial to user customization and satisfaction. When this is difficult to do, users can pester you with lots of support tickets and emails. But when it’s effortless, users feel empowered and in control and won’t need to bother you.

I know not everyone celebrates this, but it’s a very interesting time for our world. It’s the year of the Fire Horse, which represents a period of intense energy, bold action, dramatic transformations, rapid progress, and disruptive volatility.

In honor of this, I will be giving away 5 free copies of my ebook “Dos and Don’ts for Form Input and Selection.” I will also be working hard to release a new ebook this year. Can’t wait to share it with you.

To enter the giveaway, comment below what personal design project, idea, or vision you want to bring to life this year. Winners will be selected at random and will receive a message if they win. Good luck!

Update: Congratulations to the following winners. They’ll receive a message to download the book. Thanks to all who participated.

1. Melvin

2. Sophia

3. Wahinya

4. Susan

5. Norair

While rags and runts might seem like a minor detail, they create both visual and reading problems that affect user experience. As users read your body text, abrupt line breaks create an awkward pause in their reading momentum. When read aloud, this disjointedness becomes even more apparent.

Beyond the reading experience, rags and runts create a visual imbalance. They produce uneven right edges on left-aligned text, making paragraphs look asymmetrical. These irregular lines can also form distracting rivers of whitespace running down your page. Ideally, rags should vary subtly while maintaining consistent line length.

Use “text-wrap: balance”

One of the most powerful CSS properties for eliminating rags and runts is text-wrap: balance. Instead of letting the browser wrap text at whatever point it runs out of horizontal space, text-wrap: balance distributes text so that each line is roughly equal in length. This creates a symmetrical, visually harmonious block of text without any manual editing or tweaking.

Notice in the example how the rags disappear when text-wrap is set to balance. Both the heading and body text have straighter edges, making the card easier to read and the margins more aesthetically appealing.

However, text-wrap: balance isn’t a silver bullet for all body text. Since the browser has to calculate optimal line breaks across the entire text block, it can introduce a slight performance cost on very long paragraphs. This is why most browsers limit their effect to text blocks of six lines or fewer.

For longer body copy, text-wrap: pretty is a better alternative. It focuses specifically on preventing runts on the last line of a paragraph without rebalancing every line, making it more efficient for large blocks of text.

Best for Responsive Design

Smaller screen sizes are where rags and runts become most problematic. On desktop screens, wider text columns give words more room to distribute naturally across each line. But as screen width shrinks on tablets and mobile devices, text columns get significantly narrower. This forces the browser to break lines more frequently and at less ideal points.

By applying these two properties to your body text and headings, the browser automatically calculates cleaner line breaks across all screen sizes. For responsive designs that serve users across a wide range of devices, text-wrap: balance and text-wrap: pretty deliver the biggest returns on smaller screens.

“My” signals absolute possession. When users see “My Picks” or “My Photos,” they understand these are spaces they control and have personalized. The first-person perspective puts them in the driver’s seat.

“Your” signals contextual relevance. “Your Recommendations” or “Recommended for You” indicates content the system has curated for them. The second-person perspective positions the interface as a helpful assistant presenting personalized selections.

Personalized vs. Customized

Use “my” for items users create, modify, or control directly—such as their playlists, saved items, custom settings, and uploaded files. These reflect deliberate user action and ownership.

Use “your” for items the system generates or tailors based on user data—recommendations, location-based suggestions, algorithmic feeds, account summaries. These are relevant to the user but system-created.

Consider an events platform: “Events Near You” works for algorithmically suggested events based on location. “My Events” works for the user’s saved or created events. The distinction helps users quickly differentiate between discovery (what the system found) and collection (what they’ve chosen).

What About Skipping Both?

Sometimes neither is necessary—”Dashboard,” “Settings,” and “Library” work perfectly well when the context is clear. But in cases where users need to quickly distinguish personal content from general content, the possessive becomes a critical wayfinding cue.

Without “my,” users struggle to identify their owned content among site-wide options. Without “your,” they can’t tell whether the content is universally displayed or personally tailored, which reduces perceived value and relevance.

The Bottom Line

Possessive pronouns aren’t just politeness, but rather functional signposts. “My” empowers users by acknowledging their ownership. “Your” personalizes the experience by acknowledging the system’s awareness of them. Choose deliberately, stay consistent, and users will navigate with confidence.

A common approach is to allow menu items to bleed off the edges so users can scroll horizontally to navigate. However, this isn’t intuitive because not all users will perceive the horizontal scroll function and may only interact with the visible items.

Also, horizontal scrolling and scanning require more effort with the finger and eyes. It’s much harder for users to scan and scroll a list horizontally than vertically. The movement feels more awkward as it goes against the downward direction of the page flow.

Another approach is to hide all the items in a “hamburger” menu at the top. A problem with this is that users have to search for it among other icons. This might not require much effort, but it still creates some initial friction when you start navigating.

Not only that, but the icon is also in an awkward position at the top, requiring users to stretch their fingers to reach it. This isn’t a quick task that can be done with one hand. Instead, users have to use their other hand to click the menu button, further slowing them down.

Another problem with the “hamburger” menu approach is that it pulls users out of the page context. Instead of navigating a simple menu, it feels like they’re on a completely different page. They’ll experience this every time they open the menu to navigate.

A better user experience would be to turn the navigation bar into an all-inclusive drilldown menu. In other words, the bar itself becomes the menu. Instead of displaying the category items, you would display a label that encompasses all the items, such as “Shop Products.”

When users click the bar, it’ll drop down and display the main category items. As users click a category, the menu drills down to the next level of subitems, and so on until it can’t drill down further. If they navigate to the wrong level, they can click the back arrow button to reset.

The benefits of this approach are that users never lose sight of the page context, and interacting with it is fast and easy. They can easily accomplish this task with a single hand. It’s also easy to scan and scroll the item lists since they are displayed vertically.

For navigating large lists of item categories, this approach gives you the best user experience on mobile screens. The navigation bar is no longer crammed with multiple menus. Instead, it has become a single drilldown menu that’s faster and easier to navigate.

Imagine being confronted with 46 items organized into 4 columns. When users open the mega menu, they're trying to hold too many things in their working memory: the item they’re looking for, the category labels they're scanning, and their current position in the navigation structure. The result is working memory overload, where they feel overwhelmed, make slower decisions, or simply give up.

Users often do double work because they must constantly re-scan options they’ve already seen when they can’t remember what was in the previous column, or which items they’ve already dismissed. In other words, there’s no scanning structure to follow because the mega menu dumps the entire site architecture onto users at once.

The Accessibility Burden

A heavy cognitive load isn’t the only issue. Mega menus are also a burden on accessibility. Screen reader users must tab through every single focusable element to reach their desired link. If their target is the 46th item in the menu, they need 46 tab presses. If they accidentally tab one too many times and leave the menu, they have to start over from the beginning.

When a sighted user sees a mega menu, they can quickly scan the visual layout, ignore irrelevant sections, and jump directly to what they need. But screen reader users experience mega menus sequentially—they must listen to every single link announced, one after another, often with no clear indication of when one category ends and another begins.

Progressive Disclosure Menu

Progressive disclosure menus solve the cognitive overload problem by breaking navigation into manageable steps that align with how working memory actually works. Instead of presenting all 46 items simultaneously, users first see only the top-level categories: Living Room, Bedroom, Dining, Office.

Once they select a category, they see only the items within that section, reducing their immediate choices to a digestible number. This approach respects the natural order of human decision-making: make one choice, see the results, then make the next choice. It dramatically reduces cognitive load because users only process information relevant to their current step in the journey.

For screen reader users, this is transformative. Instead of listening to 46 links announced sequentially with unclear boundaries between sections, screen reader users hear 4 category options, make a deliberate choice, and then encounter only the 10-15 relevant items within that category. This transforms navigation into a logical progression that’s easy to follow.

If they realize they’ve chosen the wrong category, backing out and trying another doesn’t mean they have to restart from scratch. Instead, they return to those same 4 category options they’ve already visited. After each selection, screen reader users receive confirmation of where they are before hearing the next set of options. Users know they’re moving forward through a structure rather than lost in a list.

Adaptable Menu Size

Mega menus display a single menu in a large size to fit every category and item list all in one space. Progressive disclosure menus save more screen space than mega menus because they can adapt to the size of the item list. Since each category has their own item list size, you don’t have to use a large menu for smaller lists. You can use a smaller menu to display a smaller item list.

Scanning Structure

Mega menus don’t provide users with a controlled scanning structure. Users can start scanning from anywhere and end up anywhere, which can cause them to re-scan the same items. On the other hand, progressive disclosure scanning is more controlled. Users will consistently scan the categories on the left first before moving to the items on the right. This reduces randomness and chaos during scanning, which improves navigational efficiency.

Conclusion

The best menu navigation doesn’t show users everything at once. It guides them toward what they need, one thoughtful step at a time. For screen reader users, this cuts navigation time from minutes to seconds and eliminates the cognitive exhaustion of processing endless lists.

Stop defaulting to mega menus because that's what you've always done. The evidence is clear: progressive disclosure reduces cognitive load, improves accessibility, and helps users complete tasks faster. Choose navigation that serves your users, not navigation that burdens them.

When a modal appears, it obscures the very information users need to make informed decisions. For example, viewing version history in an overlay prevents users from comparing changes against the current state. Instead of seeing all the information they need, they must hold it in their working memory.

Not only that, but editing in a modal also means losing sight of the surrounding data that provides essential context. This modal interruption slows down the user’s workflow and creates friction between them and the data they’re editing. When it comes to editing, they can’t afford to make costly errors.

The human working memory is notoriously limited and unreliable. Our brains are not designed to hold too much information at once. Research suggests we can handle a few chunks, but even that capacity degrades under cognitive load, stress, or distraction. Therefore, it’s not ideal to force users to use their working memory on tasks.

The problem compounds when tasks require comparing or synthesizing information. If a user needs to check whether their edit conflicts with another field’s value, or verify that reverting to a previous version won’t disrupt current work, they’re juggling multiple pieces of information simultaneously.

Each additional item pushes working memory closer to its breaking point. Details get fuzzy, confidence wavers, and users resort to inefficient workarounds, such as opening and closing modals repeatedly or giving up on thoroughness.

Inline cards offer a more intuitive approach that keeps the context fully visible. The version history expands below the card when users click on it. The expansion feels natural, like unfolding another section rather than being taken elsewhere. Because context remains intact, users can make informed decisions with less cognitive effort.

When a user clicks the edit button on an inline card, the card transitions to reveal the edit fields in place, replacing the read-only display. The transformation is immediate and spatial—users see where their edits are because they happen in the exact location they just clicked.

It’s important to note that the edit state should not cover the version history section, as users may need to view it while editing. The edit state should only cover the read-only data above the version history section.

All surrounding elements remain visible and accessible, preserving the full context. To complete the interaction, users must either commit their changes with the “save” button or abandon them with the “cancel” button, both of which return the card to its default state.

The edit state itself becomes a temporary yet stable workspace where users can reference adjacent information and make changes without the pressure of a modal demanding their immediate attention. Users can see related fields and maintain their spatial orientation within the current context.

Inline cards represent a fundamental shift in how to think about data management. It’s not always necessary to disrupt the user’s workflow with a modal display. Doing so will only cause context loss and increase cognitive load.

Instead, opt to maintain the user’s spatial orientation, context, and continuity for a more seamless experience. For tasks that involve editing, comparing, or interacting with surrounding data, the better design choice is inline cards.

For example, if you’re listing a property for sale, it’s important to consider the presentation, as this can influence its chances of selling. Unfortunately, most forms do not offer a preview of how the user’s input will appear when the listing goes live. Instead, users only see standard text fields without any indication of the output.

Not knowing how their input will appear in public can give them second thoughts when submitting the form. It creates a level of uncertainty and anxiety that can affect the task performance and completion rate. However, there’s an intuitive way to provide users with a preview of the output as they fill out the form.

Rather than presenting the property listing as a standard form, you can design it to resemble the card display that appears after submission. This approach allows you to showcase the form as a “template” inspired by the card output.

The form fields need to be positioned identically to the card’s data. Additionally, the empty upload field should match the size of the preview image on the card. As a result, users get a sense of the public listing before it goes live so that there are no surprises.

This output form is for the card display only, which is what the public sees first. However, you can also use an output form for the details page that appears after the user clicks the card.

The details page contains more fields and images. The key is to preserve the layout, field positioning, and image sizes in the form so that it matches the output. Notice that the positions of the fields align with where the data is displayed. Also, the empty upload fields are sized to match the images in the listing. Overall, the form layout mirrors the page layout.

Output forms are not only effective for public-facing data but also for visual input. Most of the time, the images in a post influence the chances of achieving the desired outcome. Therefore, users must ensure that images are displayed correctly before publication.

In this case, if the user accidentally uploads the wrong house images, it won’t sell. Not only that, but if the image order isn’t correct, it could also affect sales. For instance, the featured image should be the most attractive, since it will make the first impression.

When the form input matches the output, users have a better idea of how their information will look in the post. This gives them certainty and peace of mind as they enter their input, increasing the likelihood that they will successfully complete your form. Use output forms whenever you have visual input or data that’s displayed publicly.

When you have borders within borders, there’s more visual noise that interferes with the user’s viewing experience. The borders are harsher on the eyes and become a distraction as users scan for information. Not only that, but the UI looks less like a finished design and more like an incomplete wireframe.

Borders are actually visual elements that receive fixations. When you have a lot of them together, they can slow down scanning. It’s harder for users to decide what to look at because there are too many elements competing for attention.

That’s why it’s better to use surface shades over borders. Surface shades are easier on the eyes because they lack harsh edges and blend more easily with the background. Instead of hard lines to distinguish elements, it uses subtle depth to make a two-dimensional design feel three-dimensional.

The best way to create surface shades is to derive them from your accent color. Take your accent color, decrease the saturation to 0, and increase the brightness to 100. Now incrementally add a little saturation and reduce the brightness to create a light shade. From there, add a bit more saturation and reduce the brightness slightly to create a dark shade. Play around with it until you fight the right balance.

As you can see, the saturation and brightness of the shades vary in tiny increments. You don’t need much variance, since the surface shades are meant to be subtle. On a white background, the light shade should be the first surface layer you use. Any other elements placed on top of the light shade element should use the dark shade. Stacking these surfaces create depth for a better visual experience.

The same principles apply to interfaces with a dark background. The many borders create visual noise, making it difficult to distinguish the different elements. Every element looks like a button, but that’s not the case.

Surface shades solve this by separating the groups with depth. Now users can see the surfaces that make up the data cards, along with the buttons stacked on top of them. They can also see that the global elements in the top bar differ from the ones in the data cards.

If you examine the saturation and brightness levels of the shade, you can see that the dark shade has incrementally more saturation and less brightness than the light shade. This same pattern also exists with the shades used for a white background. Also, the difference in the values is only a few percentage points.

It’s okay to use borders on your design, especially when you need to divide and group content. However, when you have borders wrapped around borders, it’s too much. A better approach is to use surface shades to create a more visually appealing and easier-to-scan interface. All it takes is three surfaces and two shades to level up your design.

There’s a reason the words inter-face and sur-face include the word “face”: they’re both intended to present something to the viewer. In other words, a design with only borders lacks a proper face for presentation and viewing.

Borderless radio buttons have no container for the text label. This makes the radio buttons harder to notice, read, and click. Just take a look at the example below. The options look like a cluster of mangled text scattered across the screen. You have to hone in on the details to read and process each option. Selecting an option shouldn’t require this much cognitive effort.

Making your radio buttons easier to read and click is simple. Add a border and surface around each option. Notice how the border creates ample whitespace between each option for better readability. It no longer looks like a disorganized cluster of text.

Also, the selection cue is much more apparent. Instead of only a filled-in circle, you can highlight the border surrounding the selected option. In addition, it’s easier to click because the button surface acts as an interaction cue.

Typically, users would click the circle or the label. However, the target is so small that it’s hard to hit consistently. Also, the text label sometimes isn’t made clickable and can vary in length. The border and surface allow users to click every option with consistent accuracy.

A border and surface are even more essential when you present options with more than a single string of data. Sometimes you’ll have options that display data, metadata, and descriptions to help users make the best selection. This text is too complex to read because everything is clustered together. In other words, there’s no visual hierarchy to help differentiate the primary information.

Adding borders and surfaces to each option creates a hierarchy for better readability. You can use the left and right sides of the container to place different data, as well as the top-to-bottom locations. Instead of reading the data like a lengthy paragraph, users can scan the hierarchy and process the information more quickly.

Borders and surfaces also allow you to style your interface. You can add your brand color to the selection cue to make it more appealing. You can use a solid color or a gradient to make the experience more pleasant.

Your radio buttons should always have borders. Any radio button without one is incomplete in its design. Users should always be able to notice, read, and click radio buttons with ease when selecting their input. You can only achieve this by adding a border around them.

Brightly colored buttons with white text labels are inaccessible to users with visual impairments. This includes color blindness and low vision, which commonly affects the elderly.

To check your button accessibility, use an online color contrast calculator to calculate the contrast ratio. It needs to be 4.5 or higher to meet the level AA accessibility standard. Unfortunately, most bright button colors fail the test.

As you can see, every bright color except indigo fails the AA standard. This means you need to tweak the colors to fix the accessibility issue. There are a couple of ways to do this.

You can either use a black text label or darken the hue. Certain colors fare better with one approach over the other. For instance, to fix a red, blue, or magenta button, it’s best to darken the hue. On the other hand, to fix a green, pink, yellow, orange, or aqua button, it’s better to use a black text label.

When your buttons pass the AA standard, they’ll be accessible to visually impaired users. To put it to the test, this example demonstrates how darkening the hue and using a black text label improves readability.

Now, when users perform an action, they won’t hesitate or second-guess themselves. Instead, they’ll be able to click the buttons with more certainty. Next time you use a bright button color with a white text label, check whether it passes the AA standard. If not, you know what to do.

With two columns, users have to scan vertically and horizontally to fill out the form. The fields are overpopulated on the left and right sides. It’s almost as if they have to fill out two forms in one. In their minds, they think this is going to be a lot of work, and they don’t have much time. As a result, they change their mind about completing the form, and you lose another customer.

If you don’t want to lose more customers, stop displaying your fields in a multi-column layout. Instead, start using jointed fields. Jointed fields conjoin two related fields and remove the margin between them to create a stronger relationship.

Designers often use a double-column layout because certain fields go better together in the same row. Stacking them vertically would not indicate their relationship. Therefore, they’ll stack them horizontally so users can associate the two as siblings.

For instance, the First Name and Last Name fields work better in the same row. Instead of displaying them as separate fields, display them as jointed fields that share a common border. This removes the margin spacing and brings them together for a stronger visual relationship.

The benefit is that users won’t see these as two fields anymore when they glance at the form. It’ll look like a single field, which is far less overwhelming when you have multiple rows stacked.

If you examine the two-column form, you’ll notice that every field in the same row is put there because they share a data relationship. Yet this relationship isn’t clear to users when they look at the form. Only by using jointed fields can you make the relationship apparent.

Above is what the two-column form looks like with jointed fields. It displays the same number of fields, but they no longer overwhelm users. The data relationships are distinguishable as you scan each row. The result is a lower cognitive load to complete the form.

Notice that a jointed field doesn’t have to be split equally. It’s better to reduce the field width for shorter input strings and increase it for longer ones. If both strings are similar in length, you can split the jointed fields equally.

There are specific data fields that have fixed input strings. Those are the field widths you can reduce. For instance, phone numbers, postal codes, apartment numbers, and card numbers all have fixed input strings. By reducing the field width, you give the adjacent field more space to accommodate longer and variable input strings. The different field widths also help users recognize specific data more easily.

Although jointed fields look like a single field, they are basically separate fields with no margin spacing between them. Therefore, validation should work separately for each field. You would highlight the erroneous field and display an error message below the offending field.

Jointed fields are a simple and effective concept and technique. You want to strengthen sibling relationships and reduce perceived data density. The margins separating these fields are what’s preventing users from making this cognitive connection. What started as 18 fields now feels like 9, a significant change that affects user perception and behavior.

A truly “clean” design is achieved through the art of de-emphasis. Most designers overemphasize elements, resulting in a cluttered, overwhelming interface. The example below illustrates this perfectly.

There are only five buttons, but it feels like there are more. The buttons may work, but they aren’t pleasing to look at or use. The emphasis should be applied to the most important element, while everything else should be de-emphasized. Here, everything is emphasized.

The Law of De-Emphasis

In this case, the text labels have the highest priority. If users can’t read them, they won’t click them, making the buttons unusable. To redesign the buttons, start with the text labels first and remove everything else. This means no button shapes, borders, or colors.

The text labels aligned in a horizontal row are a good start. However, there isn’t a visual cue to indicate the affordance. As a result, it’s easy to mistake them for plain text that runs together rather than clickable buttons.

Button borders are not a good option for this because they would overemphasize the elements. Remember, the goal is to emphasize the text labels over everything else, not create visual competition. Instead, use light and subtle button surfaces.

Additionally, apply a heavier font weight, such as a medium or semibold, to make the text pop to the foreground. Bold is sometimes too heavy, so make sure to find the right balance.

Adjusting font weights is a better approach to increasing contrast than enlarging text or darkening the shade. You won’t always have room for larger text, and a darker shade can create visual inconsistencies with other elements.

A light gray fill is the most common color for a button surface. However, this might not be ideal because it can make the button appear disabled. To avoid this, add a colorful tint to the gray. Now, it looks blue-gray rather than pure gray, eliminating the possibility that it’s a disabled button.

These buttons already look much better than the original design. However, you can also de-emphasize the quantity of text that’s displayed. With so many text labels, users will have to spend more time and effort reading them to ensure they click the right one. By de-emphasizing the heaviness of text, you allow users to make decisions via symbolic recognition.

The “Start Conversation” button can be represented by a speech bubble, and the “New Note” button can be represented by a document. Since both buttons create new data, they should be grouped on the same button surface. In general, similar actions belong together like siblings.

In addition, the arrow button from the original design uses a triangle icon that’s overemphasized. A better icon would be an ellipsis to represent “More Actions.” You can also use a pencil to represent the “Edit” action. However, leaving it as a text label is also fine since you have a balance between text and icons.

Sometimes you’ll have actions that can’t be well-represented by icons. For example, what icon would work well for “Follow?” Nothing concrete comes to mind. Therefore, it’s fine to use a text label for these rare cases.

When using icons, it’s essential to provide tooltips for users who can’t recognize them initially. The labels appear when they hover their mouse over the icons. Over time, they’ll be able to recognize them with ease by symbolic recognition. In the long-term, this is much faster than reading text labels.

Conclusion

The path to a clean interface isn’t about adding more visual elements—it’s about knowing what to remove. De-emphasis requires restraint: resisting the urge to make every element stand out. When everything is emphasized, nothing is.

Clean UI design isn’t minimal for aesthetics. Instead, it’s minimal because it removes everything standing between the user and their goal. Follow the law of de-emphasis, and you’ll create interfaces that are delightful to look at and pleasant to use.

In a password change flow, users may see a modal dialog that says, “Your session will expire and you’ll need to log in again.” Users might think “Cancel” abandons their password change, but they already changed it. This step just warns them that their session will expire. A clearer label to use is “Not Now,” so users don’t think they’re reversing the password change.

When saving a file that already exists, a modal dialog may say, “A file with this name already exists in this location.” Does “Cancel” cancel the process entirely, or just the replacement? A better label is “Keep Both,” so users know they created an extra file.

In a permission request, users may see a modal dialog that says, “This app would like to access your location.” Does “Cancel” deny permission or just dismiss the dialog? A better button label would be “Don’t Allow” to make it clear that they’re denying the request.

In a background process warning, the modal dialog might warn users that “Closing this window will interrupt the sync.” Does “Cancel” cancel the window close or the sync? A better label for the button is “Keep Open” to avoid users thinking they’re canceling the background process.

For upgrading a subscription, a modal dialog may say, “You’ll be charged $99 today and billed monthly.” Does “Cancel” mean don’t upgrade or cancel their current subscription? A clearer label is “Nevermind,” so users won’t think the button will cancel their current plan.

If users try to exit an app, the modal dialog may say, “Download in progress. Are you sure you want to stop it?” Users could think that the “Cancel” button cancels the entire download. A clearer label would be “Go Back,” to prevent the exit and let users know their download won’t be interrupted.

Conclusion

As you can see, there are many contexts where the “Cancel” button can confuse users and increase cognitive load. Instead of using the same label to dismiss every modal dialog, consider an alternative that better suits the context. Here’s a list of other dismissal labels that may work better than “Cancel.”

• “Keep [X]”

• “Go Back”

• “Return to [X]”

• “Continue [X]”

• “Don’t [X]”

• “Stay [X]”

• “Nevermind”

• “Not Now”

• “Maybe Later”

Most designers will display every modal dialog the same way. It’ll have a confirmation message with a couple of buttons contained in a floating box. The problem with this approach is that not every message has the same severity. It’s necessary to indicate these differences in the design so users never take the wrong action.

Informational State

The first state a modal dialog can have is informational. This is indicated by a blue “i” icon. When users see this, there’s no sense of urgency because the actions have no consequences. Therefore, they can act casually without the fear of clicking the wrong button.

Warning State

In contrast, the warning state alerts users to proceed with caution. It has an exclamation mark icon with an orange/yellow color. Use this state to save users from a potentially destructive action.

For instance, if a document couldn’t save the changes due to a network issue, you can warn users and let them retry their connection. Instead of allowing the destruction to happen, the “Retry” button gives them a chance to avoid data loss.

Danger State

However, a state that’s more severe than the warning state is the danger state. It also has an exclamation mark icon, but it’s red. Use this when the action will directly result in data loss.

For example, a confirmation to delete data results in the destruction of the data. It’s not a warning state because the “Delete” action isn’t trying to save users from an accident. Instead, it’s intentionally deleting the selected data.

Success State

The safest state that allows users to act without severity is the success state. It has a green checkmark icon. When users see it, it signals that a task has been successfully completed. The primary action guides them to the next natural step, while the secondary one keeps them on the current page.

An example of this is uploading files. The modal dialog in a success state informs users that the file has been uploaded and offers the option to view it. This is the next natural step most users would want to take after an upload. However, some may want to continue uploading more files, which is why “Upload Another” is the secondary action.

Conclusion

These four states signify the severity level for each modal dialog. Higher-severity states demand more attention and consideration so users can always take the appropriate action without error.

• Success - Very low severity

• Informational - Low severity

• Warning - Medium severity

• Danger - High severity

Without these four states, each modal dialog looks the same. As a result, users treat them all the same when making a decision, which can lead to mistakes. Sometimes it’s no big deal, but other times it can cost users a lot of time and money. Therefore, it’s imperative to indicate these four states in your modal dialogs using the proper colors and icons.