# 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](money-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](people-decisions.md) to do an action.
3. The [physical action itself](results.md).
4. Their observation of the action.
5. Their [interpretation](people-image-why.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](people-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-why.md).

However, since [cultures](people-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](lawsaxioms-design.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.

Further, there are [certain non-negotiable rules](engineering-design-elements.md) for how specific elements should work, based on [universal human psychology](humanity-universals.md).

## 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](https://adequate.life/fix/)* 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](people-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](people-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-cs.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](https://adequate.life/fix/), 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.

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

Any small issue in a design becomes a large one [when it becomes large-scale](engineering-design-scaling.md).

## More information

[A tech-oriented dive into this content](engineering-design-computers.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/)