UX (User Experience)

The subjective quality of the user’s motivations and feelings towards the interactions with a product.

A company tends to design systems that mirror their communication structure e.g. ‘shipping the org’. You can see this in large scale software where the UX feels clunky, compartmentalized when it ought to work together as a unit.

By analyzing frontend analytics events we can derive the ‘hot paths’–sequences of actions users often take. If we also know the user’s goals we can then calculate the state space and optimal path (e.g. A* pathfinding). With that we can calculate the frequency in which users choose an optimal path.

Parts of the user experience that are not quite broken, but subtly in incongruous. For example, they might have elements that use slightly different styles, UI patterns, or fell out of sync with the product. The neglected UX within an app tends to add up over time (UX entropy) before it is noticeable enough to become a high priority. Addressing the issues with neglected UX tends to take a lot of time and is rarely apparent to others.

User experience research (UXR) is a function that works with users and analyzing data to learn about and test ideas. This serves as a way to avoid common biases when building products and making decisions (e.g. confirmation bias, availability bias, etc) by talking to real people outside of an organization.

Having a delightful UX (user experience) is obviously good, yet not provable. Attempts to apply a formalization like conversion, net promoter score, or other metric usually fails to directly observe the effect of good (or bad) user experience. In that way, UX is a G-statement that we all intuitively know to be true.

Notion is a popular wiki that I started using more seriously recently. Looking at Notion through the lens a text editor (the predominant way users create content) reveals a number of quirks.

It seems possible to generate all states of a purely functional UI so that it can be analyzed and audited.

When organizing the information architecture for a website of applications, there should be no straight line hierarchies. This happens when there is a hierarchy of items, but one of the categories only contains a single item. This is confusing to users and unnecessarily adds another layer for users to traverse.

The user’s evaluation of the quality of a product is not separate from the aesthetics. This is especially important for products that are not observable by the user e.g. software or infrastructure. They can’t physically inspect the quality and rely on other signals as a proxy—the website, UX, documentation, etc. This isn’t strictly logical (you can simultaneously have a beautiful website and a terrible product), but an important factor nonetheless.