# How design (UX/UI) works

Visual design creates a user experience (UX) that designates how people [understand](understanding.md) the nature and implications of [created works](creations.md), and in most [capitalistic](economics.md) societies closely connected to [advertising](marketing.md).

Good design contains a *lot* of psychology because users create models in their mind of how something is supposed to work, so it dovetails with most of our [cognitive biases](mind-bias.md).

Throughout all good design, a few traits perpetually resonate:

1. The product itself uses both knowledge of the world and knowledge in the users' minds.
2. The experience simplifies the structure of tasks.
3. Things to do and things that happen are readily visible.
4. There are obvious associations between action and purpose.
5. Both natural and artificial constraints are intentionally exploited as a [type of power](power-types.md) (rather than as a hindrance or challenge).
6. When all else fails, creates [standards](standards-computers.md) to nail things down.

We tend to need both order and variety. Too much [order](understanding-certainty.md) feels boring and oppressive, while too much [variety](people-changes.md) feels chaotic and unpleasant. While the definitions are *very* distinctive, the balance resonates within all of design.

## User-based

Users travel through a predictable flow of thought as they use something (known as a "user story" in the industry):

1. A [purpose](purpose.md) they want to accomplish, which doesn't change throughout the process.
2. A [decision](decisions.md) to do an action.
3. The [physical action itself](results.md).
4. Their observation of the action.
5. Their [interpretation](image.md) of the state of the thing they're interacting with.
6. An [evaluation](understanding.md) of that state.

As they attempt to perform an action, they perform a complex [decisions-based calculus](decisions.md) to determine whether they still want to keep doing it.

- In general, people choose the path of least resistance in their decision-making calculus, and good design fosters the decisions they would naturally *want* to make.
- If the object isn't designed well enough, they'll stop using it.
- When that object has alternative objects for accomplishing the same task, they may use another object.
- If that object is absolutely necessary to perform the task, they'll either have to exercise willpower to complete it or will find [a creative way](mind-creativity.md) to *not* perform that task at all.

On a large-scale, many projects have lengthy meetings that discuss the size of a logo or the precise location a webpage opens to because absolutely *inane-looking* details can provoke dramatic philosophical distinctions within the user's [story](stories.md).

However, since [cultures](culture.md) change and [technologies](technology.md) improve, a good design at one time can easily become a bad design later.

## Rules

Good design distills into a wide variety of [reliable axioms](engineering-design-rules.md). These span the entire range of psychological perception and [bias](mind-bias.md), and social scientists and UX designers are *constantly* discovering new ones.

Anyone who follows the rules can design well, even when they're not very [creative](mind-creativity-how.md).

However, the rules of good design are *not* mechanical. Over-engineering a product can destroy it far faster than missing a few good design standards.

## Communication

Every tool has several parts:

1. The part the user interacts with (the "interface"), which is the domain of UX.
2. The part which actually *[fixes](fix.md)* a problem (like a screwdriver tip or [graphical interface](engineering-design.md)).
3. Supporting parts that help the first two (i.e., technical things).

A designer is *literally* communicating nonverbal information to the user through how they built the object and interface. If the designer fails through implication, they must use labels and instructions.

- If there are any written instructions, the design has room for improvement.

If the designer *doesn't* communicate their ideas well, the user is abandoned and forced to make their own conclusions.

- Usually, they'll conclude wrongly and misuse the product, which will generate frustration.
- Great design means the user will feel as if the object is an invisible extension of their own body.

The only way a designer can successfully communicate an idea is to know what *they* want the user to do.

- This should be a comparatively small set of tasks compared to *all* the available features.
- The set of tasks should only be given one at a time.
- Each decision they must make is a task in itself.
- The fewer the required tasks, the more seamless the experience will feel for the user.

Most users blame *themselves* when struggling with a product:

- They treat the design as somewhat infallible or don't imagine a human designed it.
- They don't realize that the designer is communicating to them.
- When in doubt, treat the designer as a bad communicator.

The simpler things appear, the louder the communication becomes, so the design should *only* convey correct information.

- Put interface elements nearby where the change happens.
- Make things understandable with relevant graphics or pictures.
- Take advantage of empty areas (white space) to give "silence" to the design.
- At the same time, if a graphical element is vague, it's *worse* than putting a text label.
- Text labels should be easy to read even in a dark room, and all abbreviations should be commonplace.

Choice overload can be a very frequent problem, and every [decision](decisions.md) will wear down the user. For that reason, unpack the scope of decisions with a rigid procedure:

1. Start from the user's initial needs.
   - Show how each choice's consequences can [feel](mind-feelings.md).
2. Provide easier, smaller decisions before the larger one, with as few selections as possible.
   - Break out the decisions into multiple questions and start with fewer options, then sequentially progress to more.
3. Avoid *any* unnecessary friction which could make decision-making more difficult for the user.
   - Make categories as meaningful as possible for the customer.
   - When a decision is likely, pre-select for them to allow them more convenience.
   - Personalize the experience for them, but not so much that they [feel their privacy was violated](faang.md).
4. Delay optional or difficult tasks.
   - Remove the least-selected items completely, especially when there's no distinctive difference between elements.

The easiest way to figure out what the design communicates is to squint your eyes until it's blurry, then look at the design.

- The most obvious things will stick out more than the rest, often through color or size.

One of the most important components of design is to give reliable, rapid feedback. The user *must* know their action mattered, or what they should have done instead. The best way to give feedback is with constraints, such as graying out or concealing a button, locking off something mechanically, or limiting permissible [text input](computers-keyboard.md) into a textbox.

UX doesn't only apply to visual elements:

- Even without [computers](computers.md), push-button interfaces may still have light/dial feedback (e.g., heavy machinery).
- Even without any visual indicators, an interface can be completely audio-based (e.g., a phone number's directory tree).
- Many UX designers simply focus on visual elements because it's the most familiar sense most of us use, so sound can become *extremely* annoying or risky when misused or mismanaged.
- The design should incorporate what happens if the sound settings are lowered or off (e.g., <50% volume) and the possibility that the user will *not* see a visual input (e.g., away from screen).

Users can only draw from their [environment](reality.md) (observations) or [memory](imagination.md) (expectations), so the design should incorporate existing [cultural expectations](culture.md).

Good design works with (and never fights) the user's natural impulses. The most cathartic experience for a user is when they have an *easier* time using something than they're [accustomed to](habits.md). If people ever feel frustration over a particular product, [there's an untapped market there](entrepreneur-1_why.md).

## Documentation

In the absence of being able to reliably communicate, [documentation](language-writing-documentation.md) is a necessary evil. However, the best documentation creates standards and protocols that clarify *explicit* rules on how things should be.

Make sure to record the documentation *before* wrapping up the project or closing everything in. After the concrete has hardened, the software has been compiled, the network is live, and the engineers have left, there should be plenty of information to indicate how everything works inside.

If there's a [computerized](computers.md) text code (e.g., [VIN](autos.md), [MAC address](networks-computer.md)), make sure the content is legible:

- Avoid using similar symbols (e.g., S vs. 5).
- Group the elements out with standardized characters (e.g., 513-424-0945, 8/192.168.0.1).
- Make the letters *very* distinctive from their background (e.g., embossed, painted with thick strokes).
- If anyone will ever read it out loud, avoid similar-sounding letters (e.g., F vs. S).
- The complete alphabet, minus the above: A, C, D, E, 6, 1, K, L, M, N, P, R, 5, T, U, X, Y, 0, 2, 3, 4, 7, 8, 9.
- One alternative is to use military callsigns: Alpha, Brave, Charlie, Delta, Echo, Foxtrot, Golf, Hotel, Indigo, July, Kilo, Lima, Mike, November, October, Papa, Quebec, Romeo, Sierra, Tango, Uniform, Victor, Whiskey, X-ray, Yankee, Zulu.

## Forcing functions

Forcing functions require the user to do something before something else.

- A lock-in prevents leaving something without doing something first (e.g., can't remove the key until car is in park, confirmation to save before quitting).
- A lock-out stops something without doing something else first (e.g., a lock opening after using a key, greyed-out button before making a selection).

They are extremely valuable to create user constraints, but use them sparingly because people *hate* them.

While indirect system interaction is fine when the work isn't critical, the system should *always* allow the user to override the product's intended design whenever needed. Otherwise, this can cause tremendous damage as the user panics.

## Human error

People make mistakes, and high-quality products usually don't. Most products create a very [logical](logic.md) issue that's [easy to diagnose](fix.md), but human mistakes tend to group into several classes:

1. Capture error, where a familiar *and* unfamiliar action is the same, so the familiar action wins out by virtue of [habit](habits.md).
2. Description error, where the inner characteristics of the action are mixed up (but the form appears to be the same), which often comes by being distracted or stressed.
3. Data-driven error, where the information in someone's memory is mixed up.
4. Associative activation error, where an unrelated thought guides an action.
5. Loss of activation error, where someone forgets something and breaks a routine.
6. Mode error, by failing to identify a state-based situation.

To accommodate this, good design incorporates reliable ways to handle human error, typically through a few avenues:

- Keep logically related elements nearby each other.
- Keep dangerous actions far apart from commonplace actions.
- Make everything simpler or more straightforward, which may involve rearranging the placement of objects or moving less-used elements out of the way.
- Communicate warnings better, which may use symbols but will likely require text. Use this sparingly because it distracts from the design of the original item.
- Design more forcing functions to create constraints about the situation. Again, use sparingly or the user will learn to hate the product.

## The design's elements

Each design has to go through a *lot* of testing to make sure it works correctly. The organization designing the object will typically provide a [marketing](marketing.md)-driven [image](image.md) to:

- Using "personas" of various types of people to rapidly define what [purposes](purpose.md) that user can use the interface for.
- Creating an "information architecture" to visually inform users of their location relative to the rest of the interface.
- People feel supported throughout the experience, often where they can summon [extra documentation](language-writing-documentation-cs.md) or contact a person.
- Each person's task is an "iteration", which they will expect to repeat with the same results each time, to create a reproducible "user journey".

Generally, combining elements and grouping them with optical illusions creates simplicity (at least until the user has to *use* it with too many controls), and most expert designers tend to find [creative](mind-creativity.md) ways to merge multiple seemingly unrelated elements.

### Colors

Beyond [marketing](marketing.md), colors also communicate subtle information of their own:

- Warm versus cold colors determines the mood of the experience.
- Grey shades tend to imply an inhuman experience, but are necessary to offset a colored background.

Colors create instant judgments and [feelings](mind-feelings.md) that bypass the conscious mind.

- Literally *seconds* after someone sees a color, they've defined [beliefs](values.md) about that thing.

Warm Colors (red, orange, yellow, gold, pink):

- Tends to feel exciting
- Can stimulate hunger, impatience, and aggression
- Without other colors to dilute it, can agitate or overstimulate

Cool Colors (green, blue, purple):

- Gives a calming effect
- Without other warm colors, can feel cold or impersonal

Neutral Colors (white, grey, silver, brown, black):

- Great for mixing and as a design background
- Tones down other colors' intensity
- Without other stimulating colors, might feel boring

In general, it's a good idea to use a *lot* of neutral colors to wash out most of the experience, then focus attention with either warm or cool colors to evoke the correct feeling.

Some colors in particular provide strange, counter-intuitive associations.

- People usually dislike yellow, but people who prefer yellow adore it.
- The shading of blue can make something feel either highly masculine or highly feminine.
- Black is extremely bold and polarizing.
- People calm down after thirty minutes of looking at pink, but bright pink is visually overwhelming.

### The object's structure

The structure should reinforce the way the user should [understand](understanding.md) what's important and what they should "do":

- A visual hierarchy that makes people focus on the most important piece of content first, then move to the next most important, and so on. You should easily see that dominance if you squint or take your glasses off.
- Make the "[call to action](marketing.md)" as clear and distinctive as possible compared to the rest of the product.
- Elements aligned with other elements to give a sense of order and to connect related concepts.
- Handle sharp corners carefully because they create a harsh contrast from our associations within nature and point away from the elements *within* those boxes.
- If the interface can use a low-tech solution that plainly communicates an elaborate concept (e.g., indicator light, dial), it's often superior to a more advanced element (e.g., touchscreen).

Avoid "Z-patterns" across the flow of the information where the eye moves left-to-right, then back to left again:

- Set a line length limit of 50-60 characters and never go past 70, meaning narrow and tall information blocks.
- Place labels *above* input fields, not to the side.

### Object selections

A user must be able to quickly gather relevant information and [decide](decisions.md):

- A "default" option or configuration the user will usually use.

### Conveying media

Media (like images, video, and audio players) must be easily presented with the understanding that the user may not fully perceive it at all times, with clear fallback plans for when the media doesn't function correctly.

All media should "prime" the user to what they should next expect.

Set simple typography and color on complex backgrounds, and complex typography and color on simple.

### Typography

Pay close attention to [font](engineering-graphics.md) choice. Text details like like text placement, font, heading size, and spacing will evoke *many* [feelings](mind-feelings.md), often [by saying *much* more than the designer may be aware of](engineering-design-font.png).

The typography should fits the [emotional association](mind-feelings.md) the designer wants the user to experience.

- Typically, only give up to 2 fonts per interface, though 1 font type is often ideal.
- The font should have a serif to make it more authoritative, though it's much simpler if it's sans serif.

Make sure to use a legible font size that allows *anyone* using the product to read it without squinting or magnification:

- The font should typically be 20-point or more unless it's paragraph/content text.
- The kerning should allow each of the letters to be close enough to identify as words, but far enough that they're not overlapping.

White text with a black outline can read on *any* color background.

Do *not* mix-and-match styles, and keep everything at least *somewhat* the same throughout the design.

## Features and presenting them

When users are dissatisfied with a product but don't know why, they tend to ask for unimportant or unrelated features.

Adding features comes with a paradox: more features can make something more useful, but also more complicated.

- Eventually, all products throughout their d/evolution keep adding features to satisfy user requests, which eventually makes the thing less usable.
- Very few controls make the product look easy to use and difficult to operate, but more controls make it feel more complicated.
- The ideal middle ground is to give the same number of controls as the same number of functions, then organize them by use.

There are a few important ways to handle more features:

1. Only present features and group them according to their use, which requires understanding the frequency the users *want* those features. Not grouping them will cause confusion.
2. Either avoid adding unnecessary features or make them unnecessary attachments to the core design experience, since they'll get in the way otherwise.
3. Keep the design as simple for the user as possible. This means keeping the number of controls as the *same* as the number of features: too few and the design is cumbersome, too many and the design is complicated.
4. Intuitively hide away less-frequent features. Hiding them away without communicating where they are will make the user think they don't exist, and some of them may need it!
5. Pay close attention to obsolete or unnecessary features as they arise. Those features need removing.

Frequently, focus groups can add features that destroy the core [functionality](purpose.md) of the product.

## Design at scale

Often in large organizations, a [committee](groups-large.md) makes changes to the UX, and it tends to follow a lengthy procedure for it to roll out.

First, there are a variety of techniques to learn what the users' optimal behaviors will be:

- Focus groups will ask for opinions and feelings related to specific cues.
- Card sorting, where people organize and categorize information in a way that makes sense to them.

There's a *lot* of testing that goes into most large-scale visual designs:

- A/B testing, through exposing alternative interfaces side-by-side.
- Diary testing, collecting information via users writing a "digital diary" about their experience as they use the interface.
- Gorilla/monkey testing, where the users repeatedly behave incompetently.
- Guerilla testing, by going to public places and getting feedback.
- System usability scale, where people are interviewed on 10 1-to-5 questions on how much they like the interface.
- Task-based testing, by giving people instructions and observing how well they do them in the interface, as well as any hangups in their flow.

The entire experience of UX testing can be harrowing for designers and UX developers, since test subjects are only talking about what they [feel](mind-feelings.md) versus the creators focusing on [reality](reality.md) or on an [idealized aesthetic](values-quality.md). However, every $1 invested in good UX can often make a return of $2-100 in practice.

However, A/B testing can yield inaccurate results when implemented alone. People often enjoy novelty but don't realize its adverse effects. Large organizations frequently make a decision after *extensive* A/B testing that doesn't capture an ideal product, and they're forced to make a difficult decision:

1. Keep it as it is, with all its terrible elements.
2. Rework the change, which will often confuse the users who have to adapt.
3. Make another change to compensate, which will often confusing a *different* subset of users.

The best prevention is to make design decisions that, if they were wrong, won't make a dramatic difference to results. By pure [statistical reality](math-stat.md), designers are almost *guaranteed* to foul up on something:

- Give *many* options for the user, even if it looks ugly or unwieldy in the end.
- Make small modifications, step-by-step, instead of large changes.
- *Always* maintain [convention](habits.md), even if the designers hate it.
- Keep everything as open as possible to allow people to [fix](fix.md) and [improve](creations.md) on it later.

Plus, design decisions are subject to the perils of [miscommunication](language.md) and [power dynamics](power-types.md) that come with any [large group](groups-large.md). To avoid it, projects often develop in as many phases as necessary to prevent working on a wrongly defined [purpose](purpose.md):

1. First, get consensus on an idea, which typically has to be realistic, but whoever approves it must [believe](understanding-certainty.md) in it.
2. Conduct plenty of focus groups and research to find exactly what people would want or how they would use the thing.
3. Designers/engineers will typically create wireframes and stock prototypes of the thing. These wireframes often give a visual aesthetic of what the final product will look like, but lack most details.
4. After someone approves it, the creators will create a near-finished work without any features. This is the first time the thing actually "exists", but it's pretty lame by comparison to the final product.
5. After another approval, the product is slated for final production, which will often involve testing to make sure that it can be mass-produced or shown to the public.
6. Finally, after another round of approvals, it's shipped out the door, with numerous tweaks and updates as things fail.
7. Maintain a continuous design cycle that *constantly* harvests feedback and updates the product to get better.
8. If the product itself has become obsolete or needs to be abandoned, use the information from it for a *new* design, and start at step 1 again.

To combat the extra complexity, there are a few major ways to improve interface changes:

1. Understand *exactly* the kinds of people using the interface. This often requires including someone in the discussion who would normally *not* talk with the designers/developers, and preferably isn't part of the organization at all.
2. Create a "visual language" that demarcates a consistent pattern across the entire organization, often with a style guide.
3. Put together a shared set of components the entire organization is supposed to use.
4. Constantly communicate as things change, using one system for all discussions.
5. Keep designers and [engineers](engineering.md) constantly discussing with each other about any changes.
6. Constantly [document](language-writing-documentation-cs.md) as things change, and keep it integrated with the style guide.
7. No matter what, *always* maintain constraints on what designers can do (e.g., time limits, space limits).

If the product is particularly complex, divide out the rate of the design's change into "layers":

- Site - its location or designated place, (hours to never)
- Skin - its exterior structure (minutes to every 20 years)
- Structure - foundation and load-bearing capacity (weekly to rarely)
- Services - people who must maintain it (hourly to every 7-15 years)
- Space Plan - changes *inside* the element (every few months to every 10-30 years)
- Zeitgeist - shared awareness and understanding (every few months to every 2-3 years)
- Stuff - the inner workings and miscellaneous domains

It's worth indicating that "slower" design elements tend to constrain the "faster" ones.

Generally, the size of large organizations and the work required tends to inhibit completely free customization. In simple commodities this isn't a problem, but more high-end products need more freedom for the users to explore and [identify](identity.md) with the object.

Another risk of large-scale endeavors is complete blandness. Since people can get easily offended at small distinctions, the best form that offends nobody is incredibly boring. It also pleases very few people as well.

### Big issues in design

Most of the time, UX developers follow safe fashions, but frequently they'll [run a fashion out to its most extreme](trends.md) and make the interface almost unusable, often for a few broad reasons:

- Designers became intimately familiar with what they were designing, and have very limited interaction with the users. Often, they may only know what marketing professionals or their friends think.
- Designers have seen the same old, tired thing. They tend to not understand that the thing exists in its current form is because it was often *the* best way to do it, or they're disregarding conventions that everyone is used to.
- When a new design trend or [technology](technology.md) becomes popular, designers tend to abuse it.
- Sometimes, [managers](mgmt-1_why.md) will override the designers' professional experience, testing, and common sense based on their personal preferences or interests.
- Often, once a product has become complex enough to fulfill a specific use, its complexity forms a [cult-like](marketing.md) culture around it that elevates the object as more valuable than what it actually *does*. At that point, it satisfies [market demand](economics.md) through appealing to an [image](image.md) of sophistication, while being awful for the user (and also opening up the opportunity for [a better version](entrepreneur-1_why.md) elsewhere).

There are plenty of examples of bad fashions:

- Using touchscreens instead of buttons in [automotives](autos.md).
- Having [internet-connected](networks-computer.md) devices that don't need to be connected to the internet.
- Aggressively auto-connecting Bluetooth when the user doesn't want it.
- Giving "popular choices" that are *clearly* not popular.
- Washing out the visual contrast for style reasons, but making it somewhat unreadable.

The best solution, in all respects, is to get users using the thing as soon as possible, since making large changes can become very difficult or expensive. After all, the marketing professional and even the *designer* can't understand how the user interacts with it as much as the user.

### Dark patterns

One of the more sinister uses of UX is to create "dark patterns" that steer users to make decisions they otherwise wouldn't have taken:

- Motivating a service upgrade that someone may have not wanted to pay for.
- Provoking the user to give information they likely wouldn't have given.
- Create friction against actions they don't want the user to take (e.g., unsubscribing, deleting user profile).
- Requiring the user to repeatedly decline a permission or service, ignoring the user's response, or intentionally causing the app/site to crash once they select it.
- Requiring a login to an otherwise-free service (like cat videos), even when the user doesn't want to give a login.
- Requiring users to speak to a human being to cancel their subscription.
- Showing a product is out of stock, with a completely identical product with the same price, but with a clear reduction in its weight.

Most engineers often compromise when they're instructed to design those patterns, and evil prevails when good people do nothing.

### Addiction

Very frequently, UX developers are motivated to create elements that draw the user in indefinitely. Even when something is free, more time with the software means the person is more likely to spend money on an upgrade, give data that can be sold, or increase the value of selling [advertisement space](marketing.md).

The obsession with "user engagement" (i.e., [addiction](addiction.md)) makes "user experience" in many become "user exploitation", and it'll present itself through many subtle dark patterns:

- Creating a feeling of urgency with relative timestamps (e.g., "3 hours ago" instead of "6:15 PM").
- Making an endless loop of behavior with infinite scrolling instead of a "More" button or link.
- A fake points system with icons that reinforce the experience with interaction and feedback.
- Tweaking the system to promote or bury certain user-made content, either through hidden [algorithms](computers-programming-algorithms.md) or at the developer's/company's whim.
- Making leaving the service frustratingly difficult, or requiring a human being to finalize the process.

## Additional reading

[A tech-oriented dive into this content](engineering-design.md)

UX in General

- [Laws of UX](https://lawsofux.com/)
- [growth.design's UX Case Studies](https://growth.design/case-studies)
- [Can't Unsee, a UX game](https://cantunsee.space/)
- [A quiz on UX misconceptions](https://10ideesrecuesenuxdesign.castoretpollux.com/en/)
- [The Design of Everyday Things by Don Norman](https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things)
- [Web Design in 4 minutes](https://jgthms.com/web-design-in-4-minutes/)
- [DesignCourse (YouTube)](https://www.youtube.com/c/DesignCourse/featured)
- [Design Principles](https://principles.design/)

Colors

- [A scientific synopsis of color](http://jamie-wong.com/post/color/)
- [How to pick more beautiful colors for your data visualizations](https://blog.datawrapper.de/beautifulcolors/)

Fitts' Law

- [A Deep Dive Into Fitts' Law](https://timmarco.com/fitts/)