User Experience

I believe the way most organizations produce digital products is fundamentally broken. The elephant in the room is a dated understanding of the role of both design and engineering, which in turn shapes how organizations hire, manage, and produce digital things. These companies invest billions of dollars building teams, processes, and tools on top of an immature discipline and an outdated waterfall model that ends up being detrimental to productivity, team happiness, and ultimately, the resulting experiences we bring to life.

In the case of the seeming egalitarianism and beneficence of the voice from the cloud that says “You Are Not Your User,” what I hear in that voice is the ringing of a cash register, and the creaking of the crank on the side of a box that software development efforts disappear into, and that money comes out of.

A mechanism that would seize up instantly if some still small voice were to propose the opposite of what the thunder says: that you and your user are one.

As we’ve been researching what design teams need to do to create great user experiences, we’ve stumbled across an interesting finding. It’s the closest thing we’ve found to a silver bullet when it comes to reliably improving the designs teams produce.

The solution? Exposure hours. The number of hours each team member is exposed directly to real users interacting with the team’s designs or the team’s competitor’s designs. There is a direct correlation between this exposure and the improvements we see in the designs that team produces.

Different they may seem, search, tags, folders, hyperlinks, and algorithmic recommendations are all really interface ideas trying to address the same fundamental problem: looking for the needle in an information haystack.

...When designing an interface for finding a note in a small pile of personal notes, or building an app to organize a small team’s working documents, most of the “finding stuff” interface ideas are in play. It’s in these situations where I want to make the argument: prefer interfaces that let the user incrementally move towards the right answer over direct search.

Humans are much better at choosing between a few options than conjuring an answer from scratch. We’re also much better at incrementally approaching the right answer by pointing towards the right direction than nailing the right search term from the beginning. When it’s possible to take a “type in a query” kind of interface and make it more incrementally explorable, I think it’s almost always going to produce a more intuitive and powerful interface.

We don't necessarily need to constantly interact with people “around” us on the web. The sensation of being in the quiet companionship of someone else, like reading next to them in a cafe, is what we're missing. The sense of ambiently sharing space – of being co-present – while engaged in other activities is a staple of shared public spaces that we're still figuring out how to design in the digital realm.

The top scenario (delivering a front tire) sucks because we keep delivering stuff that the customer can’t use at all. If you know what you’re doing – your product has very little complexity and risk, perhaps you’ve built that type of thing hundreds of times before – then go ahead and just do big bang. Build the thing and deliver it when done.

However, most product development efforts I’ve seen are much too complex and risky for that, and the big bang approach all too often leads to huge expensive failures. So the key question is What’s your skateboard?

In product development, one of the first things you should do (after describing what problem you are trying to solve for whom) is to identify your skateboard-equivalent. Think of the skateboard as a metaphor for the smallest thing you can put in the hands of real users, and get real feedback. Or use “bus ticket” if that metaphor works better.

This will give you the vitally needed feedback loop, and will give both you and the customer control over the project – you can learn and make changes, instead of just following the plan and hoping for the best.

[Complex] functionality still deserves tests - for two reasons. One, it still matters that they don’t regress - and their complexity makes them all the more likely to. Secondly, testing complex features often forces engineers to architect the feature in such a way that it can be tested. The early establishment of tests can motivate narrower interfaces and less coupling, leading to a better long-term codebase.

...Better than beta cohorts is dogfooding. Send real users through the feature that you don’t want to test automatically, but have those users be you. You can’t rage quit your own product, and your eyeballs make for a great dynamic alerting service (just remember to close them for eight hours every night).

...Our solution at Graphite has been to run a roulette script, randomly deleting one of our engineers' Graphite accounts every day at 9 a.m. We don’t just reset onboarding—we delete their account, tokens, configured filters, uploaded gifs, and more.

Android and iOS share a common problem: they copied desktop text editing conventions, but without a menu bar or mouse. This forced them to overload the tap gesture with a wide range of actions: placing the cursor, moving it, selecting text, and invoking a pop-up menu. This results in an overly complicated and ambiguous mess-o-taps, leading to a variety of user errors.

It’s less of a problem if you only do short bursts of text in social media or messaging apps. But doing anything more complicated like an email gets tedious. However, in my user study on text editing, I was surprised to find that everyone had significant problems and rather severe workarounds for editing text.

Some of my best friends are designers. But I think we can all agree that - however well-meaning - they can be a little obsessive. Whether it is fretting over tiny details, or trying to align to a grid which doesn't exist, or spending time removing useful affordances in the name of æsthetics - they always find a way to make something prettier at the expense of usability.

Google used to have some beautiful logos for its apps. Each had a distinct shape, style, and colour. Then, someone decided that they all needed a consistent visual language. And this mess was born.

Any individual trying to use the Internet for community use at the South Pole, as of October 2023, likely faced:

• Round-trip latency averaging around 750 milliseconds, with jitter between packets sometimes exceeding several seconds.
• Available speeds, to the end-user device, that range from a couple kbps (yes, you read that right), up to 2 mbps on a really good day.
• Extreme congestion, queueing, and dropped packets, far in excess of even the worst oversaturated ISP links or bufferbloat-infested routers back home.
• Limited availability, frequent dropouts, and occasional service preemptions.

These constraints drastically impact the modern web experience! Some of it is unavoidable. The link characteristics described above are truly bleak. But – a lot of the end-user impact is caused by web and app engineering which fails to take slow/intermittent links into consideration.

If you’re an app developer reading this, can you tell me, off the top of your head, how your app behaves on a link with 40 kbps available bandwidth, 1,000 ms latency, occasional jitter of up to 2,000 ms, packet loss of 10%, and a complete 15-second connectivity dropout every few minutes?

I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.

Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.

Thinking [in terms of loops and arcs] allows us to let go of a specific journey or sequence, and imagine dozens of scenarios and possible sequences in which these skills can be learned. This doesn’t mean there aren’t more fundamental skills that other skills build upon, but we can let go the tyranny of how, precisely, a person will move through a system. We’re free to zoom in and obsess on these loops, which does two things for us:

• Approach the design of a system as the design of these as small but significant moments of learning.
• Consider the many ways these loops might be sequenced, with the exact order being less important.

Unfolding functionality
MouseOver
MouseDragging instead of Value-Slider
Memory Dots / Five Favorites
Transparency & Shadows
Full Screen Mode, Rooms Metaphor
Workspace – Desktop
MetaWindow

Thus, I came to the conclusion that the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. The separation of any of these four components would have hurt TeX significantly. If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important.

It’s easy to move the cursor from Amazon’s main dropdown to its submenus. You won’t run into the bootstrap bug. They get away with this by detecting the direction of the cursor’s path.

At every position of the cursor you can picture a triangle between the current mouse position and the upper and lower right corners of the dropdown menu. If the next mouse position is within that triangle, the user is probably moving their cursor into the currently displayed submenu. Amazon uses this for a nice effect. As long as the cursor stays within that blue triangle the current submenu will stay open. It doesn’t matter if the cursor hovers over “Appstore for Android” momentarily – the user is probably heading toward “Learn more about Cloud Drive.”

And if the cursor goes outside of the blue triangle, they instantly switch the submenu, giving it a really responsive feel.

Instead of spending time planning and concocting roadmaps, replace that activity by talking to current or potential customers on how their lives can be improved, and letting that determine your next feature. Injecting the actual customer who uses the software into the development process is key to creating value. The more proxies you have between the developer and the customer, the less the product will meet customer needs.

There is no point to having a large backlog because the bigger the backlog, the higher the unvalidated assumptions, and the lower the chance that it creates any customer value. I have made too many mistakes assuming that something is valuable, when nobody cares about it. A large backlog should be looked at with an extremely high degree of skepticism, as the size of your backlog is inversely proportional to how often you talk to customers.

Planning time is best used focusing on how to build the feature, not what to build. The what should come directly from the customer, with the software development process needing a direct physical line to customer - no proxies.

Visionary designers have lost their conceptual integrity to an industrial complex optimized for consensus, predictability, and short-term business gain. The rise of customer-obsession mantra and data-driven culture cultivated a generation of designers who only take risk-free and success-guaranteed steps towards the inevitable local maxima of design monotony.

I decided to record every broken interaction I had during one day.

If I decided to invest time into thinning this list down, I could theoretically...reduce this list from 27 down to 24. At least 24 annoyances per day I have to live with. That’s the world WE ALL are living in now. Welcome.

Users are accustomed to a minimum of quality, and they expect that of all new products.

If our product does not [meet basic expectations of quality], people will automatically believe that it is a bad product and they will not take it seriously. It is not what they expect.

Hence my suggestion that the MVP has died and the MAP: Minimum Awesome Product was born.

Say you’re trying to test whether people like pizza. If you serve them burnt pizza, you’re not getting feedback on whether they like pizza. You only know that they don’t like burnt pizza. Similarly, when you’re only relying on the MVP, the fastest and cheapest functional prototype, you risk not actually testing your product, but rather a poor or flawed version of it.

Two studs wide and angled at 45°, the ubiquitous “2x2 decorated slope” is a LEGO minifigure’s interface to the world. These iconic, low-resolution designs are the perfect tool to learn the basics of physical interface design.

There are three types of work that UX Researchers need to do:

• Macro-research is strategic in nature, business-first, and future-thinking. It provides concrete frameworks that guide macro business decisions.
• Middle-range research is focused on user understanding and product development.
• Micro-research is closer to technical usability, eye tracking, and detailed interaction development.

The biggest reason UX Research is facing this reckoning is that we do way, way too much middle-range research.

Middle-range research is a deadly combination of interesting to researchers and marginally useful for actual product and design work. It’s disproportionately responsible for the worst things people say and think about UXR. Doing so much of it just doesn’t deliver enough business value.

Designers are often working at least one sprint ahead of engineers. While one sprint might not seem like much of a lag, a typical product team learns a lot after the design hand-off. ...Instead of working ahead, we should finish designing as close to the end of a sprint as possible: just-in-time design.

Both patterns are easy to use and work on mobile.

But there’s an even more important lesson here.

Because Victor was thoughtful, no doubt. He looked at the slider, spotted an issue and came up with better UX.

But improving a bad pattern doesn’t make it good. You’re usually better off finding another pattern altogether.

We are quietly replacing an open web that connects and empowers with one that restricts and commoditizes people. We need to stop it.

There’s a distinction to make: The set of features you choose to build is one thing. The level you choose to execute at is another. You can decide whether or not to include a feature like ‘reset password’. But if you decide to do it, you should live up to a basic standard of execution on the experience side.

Features can be different sizes with more or less complexity, but quality of experience should be constant across all features. That constant quality of experience is what gives your customers trust. It demonstrates to them that whatever you build, you build well.

Analytics apps don't tell you much about usage behavior. You might be able to see how many users performed an event, or how many times they did it. But none of the analytics packages out there are good at showing you how often people do things. Are they using to-dos once a week? Every day? Only signing into the app once a month but happily paying for years?

Time matters. You can't understand usage without time.

Even among front-end developers, few people actually grok this mental model of a user. It's why most React(-like) apps in the wild are spaghetti, and why most blog posts about React gripes continue to miss the bigger picture. Doing React (and UI) well requires you to unlearn old habits and actually design your types and data flow so it uses potentially invalid input as its single source of truth. That way, a one-way data flow can enforce the necessary constraints on the fly.

The way Stanley likes to encode and mutate his data is how programmers think about their own program: it should be bug-free and not crash. The mistake is to think that this should also apply to any sort of creative process that program is meant to enable. It would be like making an IDE that only allows you to save a file if the code compiles and passes all the tests.

You can’t pick up a piece of code and feel its weight or texture in your hands. Code is an “information artifact” rather than a physical or graphical one. You interact with APIs through the manipulation of text in an editor or on the command line.

Yet this is interaction by the standard definition, subject to the complexities of human factors. So we should evaluate code, like any tool, not merely on whether it performs its intended task, but whether it is easy to become proficient, and whether using it is efficient and enjoyable. We should consider the affordances and even the aesthetics of code. Is it understandable? Is it frustrating? Is it beautiful?

Programming interfaces are user interfaces. Or, to put it another way: Programmers are people, too.

Design has very little to do with what tools or methodologies you use, or what your job title is, or what you have a degree in, or even anything like “creativity”; design is about your relationship to constraints. Rather: to what extent are you defining constraints rather than just obeying them? Design is about taking a universe of possibilities and converging onto exactly one outcome. Being handed a set of constraints which you treat like immutable laws of physics (because many of them are) and solving within that envelope is what engineering is. To wit: what most designers are doing most of the time is actually a form of engineering, and engineers are always doing at least some design.

This is because genuine design—the power to define constraints—is a privileged political position within an organization, and not everybody can occupy it. In other words, the “seat at the table” comes first. Design is Steve Jobs infamously dropping an iPod prototype into his fish tank, pointing at the bubbles coming out and yelling at his staff to make it thinner. It doesn’t matter what your title is; Jobs is the designer in that scenario.

I've already talked about adding "Juice" and "Oil" to your game designs; Windex is a third metaphorical game design fluid to add to your chemistry set.

To recap, Juice is all about making each individual input explode with ostentaious flavor and delight, whereas Oil is about quietly removing frustration and pain from the act of performing inputs in the first place.

Windex is about making it abundantly clear what the heck your game mechanics are actually doing, and removing as much obfuscating dirt and grime that gets in the way of that.

After all, what's the point in driving a juicy, well-oiled car if you can't even see through the windshield?

In her piece "A drop of love in the cloud" (2018), artist Fei Liu writes about the like/heart button as a flattening affordance of giving affirmation and love. The text-editor provides a much more expressive input.

But even people who can't communicate well because of language barriers can express love through actions, like cooking food. Can we create other "love inputs" that might allow us to "reach across the chasm of a seamless signal"?

What is expressing "real" love or affirmation about? Is it about effort, thoughtfulness, generosity, something else? What might a thoughtful or generous interface feel or behave like?

1. Design educators and industry leaders have never reached a consensus about what comprises a “good enough” foundational education for digital design.
2. We do not properly retire methods (or ways of conducting them) that have been shown to be ineffective.
3. Design team seniority levels are meaningless.
4. We’ve collectively lost the safety (and subsequently the desire) to explore and fail.
5. We afford well-known design leaders too much power to dictate how design is discussed and conducted.
6. We have no ethical standards.
7. Inclusive design and accessibility are afterthoughts — both in design education and in practice.

All the annoying bumps, barriers, and inconsistencies that start accruing around each new feature, if left unsolved, can limit the amount of value users can extract from the product. And if you don’t effectively identify and remove these barriers in a deliberate and structured way, any additional functionality will simply add to the problem.

A worst-practice UI experiment.

Increasingly, I think UX doesn't live up to its original meaning of "user experience." Instead, much of the discipline today, as it's practiced in Big Tech firms, is better described by a new name.

UX is now "user exploitation."

"Design engineering is the name for the discipline that finesses the overlap between design and engineering to speed delivery and idea validation. From prototyping to production-ready code, this function fast-tracks design decisions, mitigates risk, and establishes UI code quality. The design engineer’s work encapsulates the systems, workflows, and technology that empower designers and engineers to collaborate most effectively to optimise product development and innovation." — Natalya Shelburne

The “case study?” column was the whole point of the spreadsheet — identifying which projects I still needed to write up for my portfolio — but at this point I looked at the sheet, and thought “This is honestly a better overview of the work I do than any ‘portfolio’ I’ve seen”.

So I tweeted a screenshot, joking/trolling that it WAS my portfolio (I didn’t include any winks or notes that I was still planning a “real” portfolio), but people didn’t respond with the lulz I expected — they got the idea, or took it at face value and said they were going to do their portfolio this way too!

The horizontal axis represents the investment the organization makes. As investment increases, the organization spends more resources on improving the quality (remember, Noriaka was a quality guy at heart) or adding new capabilities.

The vertical dimension represents the satisfaction of the user, moving from an extreme negative of frustration to an extreme positive of delight. (Neutral satisfaction being neither frustrated nor delighted is in the middle of the axis.)

It’s against the backdrop of these two axes that we see how the Kano Model works. It shows us there are three forces at work, which we can use to predict our users’ satisfaction with the investment we make.

We are truly living in an era of user-hostile software, and when I say “user-hostile” I mean it as “software that doesn’t really care about the needs of the user but rather about the needs of the developer.”

I personally do not know anyone who asked for an online account requirement before they can use a keyboard; however, some product lead somewhere decided that it’s important to better “understand the customer” and “maximize marketing reach” through some weekly “Hey, we have a new keyboard!” newsletter.

A series of problem-solving experiments reveal that people are more likely to consider solutions that add features than solutions that remove them, even when removing features is more efficient.

For a long time, these four quadrants have been pretty distinct, because search and recommendations, while they occupy opposite ends of the same spectrum conceptually, have different tooling and architectures, and machine learning goals. You can even tell the way org structure of companies who hire for the teams have developed: usually there are distinct search and recommendations teams.

What happens in today’s world, when we have LLMs? We now have the collision of three different sets of user expectations.

Visualised aggregations of click activity are a low effort, low signal waste of time and best avoided in favour of actual research.

I’ve noticed a recent trend on the web — or at least, on the parts of it I’ve visited. Maybe you’ve noticed it too.

Here’s what happens: you’re on a website, and one of these little prompts pops up...[to] let you know that there’s an app, and that the website you’re on...well, it’s not quite the app, is it?

...Sometimes, the website wants me to install the app — no, it needs me to install the app. It’s like a paywall, but for apps. An appwall.

In recent years, these prompts have gotten more prominent, and occasionally impassable. And I think that trend’s interesting. Why would a company promote a native app over their perfectly usable website?

It feels like a glimpse into that company’s design priorities. And it’s possibly providing us with insight into the business value they place on the open web — a medium that’s meant to be accessible everywhere, on any screen, on any device.

And it really does feel like these glimpses are becoming more common.

A survey of people in user experience and product management shows that these professionals disagree on who should be responsible for many key tasks, like doing discoveries and early design.

I recently built an education tool.

Like other enterprising folk, I stumbled into a ethical dilemma: (1) my product probably shouldn’t be paywalled, but (2) I also don’t want to be poor.

My solution: uglify the UI for non-paying consumers.

We deployed our tool. Almost no one used it.

The handful that did use it, used it once or twice and barely interacted with it. After a few days, zero people were using it.

Why did they tell me they wanted these features?

To design a system means to orchestrate the interplay of its elements.

Such a system is considered “interactive” if it is open, which means that there are ways to engage with the processes that are happening inside of it. There is of course a range of interactivities which spans from very basic reactive behaviour to highly complex conversational interactions.

You’ve all seen them, tiny switches that let you toggle a setting. And maybe, just like me, you sometimes pause, thinking “…Is it on or off?” That’s because toggles suck!

...Just use a checkbox or radio group! It’s quick to implement, accessible from the start, and doesn’t make the user think.

So we all know Super Mario, right? And if you think about when you’re collecting coins in Super Mario, it doesn’t stop the game and pop up an alert dialogue and say, “You have just collected ten points, OK, Cancel”, right? It just does it. It does it in the background, but it does provide you with a feedback mechanism.

The feedback you get in Super Mario is about the number of points you’ve just gained. When you collect an item that gives you more points, the number of points you’ve gained appears where the item was …and then drifts upwards as it disappears. It’s unobtrusive enough that it won’t distract you from the gameplay you’re concentrating on but it gives you the reassurance that, yes, you have just gained points.

Apple is the first major operating system vendor who had abandoned a four-decades-long tradition. Their new visionOS — for the first time in the history of Apple — will have round checkboxes.

How should we even call these? Radio checks? Check buttons?

Anyway, with Apple’s betrayal, I think it’s fair to say there’s no hope for this tradition to continue.

I therefore officially announce 2024 to be the year when the square checkbox has finally died.

Send feedback and bug reports
without leaving your website. Collect live website feedback from team, clients, and users.

Multiplayer mode and live cursors create the feeling that you’re sat with friends and teammates, so it's natural that designers started experimenting with them to improve product experiences. They've gone from default browser elements to becoming little components in themselves - they can be arrows, shapes, floating avatars, or videos that bring voices onto the canvas – depending on the user needs.

The apartment I’ve lived in this past year quite frankly and very succinctly encompasses everything I kind of hate about architecture, about design, about the ways people in the profession are expected to live their lives for the benefit and the consumption of others.

...We weren’t using the apartment the right way; namely, we didn’t decorate or live like an architecture critic and a mathematician theoretically should. Our apartment wasn’t photogenic. There were too many bikes in the living room. We still had a garbage $300 Wayfair sofa that felt like sitting on cardboard. There was clutter. This beautiful apartment wasn’t meant for our kind of ordinary and this was made known several times in subtle and rather degrading ways, after which our lease was not renewed, to the relief of all parties involved. Even if it meant moving again.

The longer I lived in the apartment, the more I hated it, the more I realized that I had been fooled by nice finishes and proximity to transit into thinking it was a good apartment. As soon as we’d got in there, things started to, well, not work...All of the niceness, the glitzy brand names, the living materials were not meant for everyday use, even by gentle individuals like ourselves. They were made solely for looking at, as though that were the point of all habitation.

Recently, I’ve been thinking about developing domain expertise, and wanted to collect my thoughts here. Although I covered some parts of this in Your first 90 days as CTO (understanding product analytics, shadowing customer support, talking to customers, and talking with your internal experts), I missed the most important dimension of effective learning: getting your hands dirty.

...So often executives take a view that the constraints are a problem for their teams, but I think great executive leadership only exists when individuals can combine the abstract mist of grand strategy with the refined nuance of how things truly work. If this stuff seems like the wrong use of your time, that’s something interesting to reflect on.

1. Good design principles are memorable.
2. Good design principles help you say no.
3. Good design principles aren't truisms.
4. Good design principles are applicable.

As Nosrat provides a simple list of essential ingredients for any great meal, can we describe a simple list of essential components for digital products?

Here are four elements that I believe are the foundation of great digital products: Research, Empathy, Simplicity and Speed.

I always have a hard time wrapping my mind around some of the classic user questions: What is this thing for, is it for novices or professionals, etc? I do my best to avoid these questions, because the best thing you can possibly accomplish as the maker of a tool is to build something that gets used in ways you didn’t anticipate. If you’re building a tool that gets used in exactly the ways that you wrote out on paper, you shot very low. You did something literal and obvious.

Magic things happen when you trust your users and just show them everything you’ve got.

For example, I found some rare films playing that I had no idea about. Matrix in German (!), but once a week and only in one cinema. Or Mars Express, they play it in three cities only, excluding mine. How do you find out about stuff like this?

Here, I discovered it. I looked at the data and you started seeing stuff that otherwise is completely invisible.

Figma is not a design tool. It is a drawing tool. That these get conflated demonstrates the shallowness of so much design practice.

That computers should be easy to learn and use is a rarely-questioned tenet of user interface design. But what do we gain from prioritising usability and learnability, and what do we lose? I explore how simplicity is not an inevitable truth of user interface design, but rather contingent on a series of events in the evolution of software. Not only does a rigid adherence to this doctrine place an artificial ceiling on the power and flexibility of software, but it is also culturally relative, privileging certain information cultures over others. I propose that for feature-rich software, negotiated complexity is a better target than simplicity, and we must revisit the ill-regarded relationship between learning, documentation, and software.

Interactive digital technology is forcing another major paradigm shift that humbles as well as frees the traditional graphic designer. The digital delivery of interactive communications design media allows our audiences to “finish” our work. Communications design “pieces” will increasingly be delivered to audiences as potential experiences to be initiated by each receiver and “read” in a unique way based on each receiver’s preferences, interests, values, needs and even moods. Websites, CD-ROMs, interactive TV and advertising, and tailorable software are examples. Designers find they cannot control many variables of how a home page downloads, not only because of the vagaries of differing electronic formats, but even more due to the preferences of our audiences who are increasingly opinionated and educated in the subtleties of form in typography, imagery and sound. Interactive media encourages audience members to create and add content.

This environment requires a much different visual design strategy than that of the traditional perfectionist designer. What are the implications for graphic designers trained in the modernist traditions of clarity, formal refinement and professional control? We can no longer think of our work as the production of as precious perfect artifacts, discrete objects, fixed in their materiality. The designer is no longer the sole author, realizing one’s own singular vision. This forces a reordering of our design intentions. The designer is an initiator, but not a finisher, more like a composer, choreographer or set designer for each audience member’s improvisational dance in a digital communications environment.

If you’ve interacted in the product strategy sessions, you’ll find I’ve historically been opposed to A/B testing - to running behavioral experiments.

...Now you might ask, why would I be opposed to such a thing within our product? There are many, many reasons I am opposed, but the one we should care about is how it fosters a culture of decision paralysis. It fosters a culture of decision making without having an opinion, without having to put a stake in the ground. It fosters a culture where making a quick buck trumps a great product experience. That goes wildly against our core values, how we built Sentry, and what we want Sentry to be. Pixels Matter, one of our core values, is centered around caring about the small details, and that by its very nature is subjective. What details? Which ones matter? Those decisions all center on taste, and around someone making a subjective decision.

Software applications can utilize spatial interfaces to afford users powerful ways of thinking and interacting. Though often associated with gaming, spatial interfaces can be useful in any kind of software, even in less obvious domains like productivity tools or work applications. We will see spatial interfaces move into all verticals, starting with game-like interfaces for all kinds of social use-cases.

Figmaism — an obsession with tooling at the expense of other (and often more important) skills.

“CEO-ification” refers to the trend of nonprofits and charities to increasingly mirror corporate and military structures. Often they will adopt similar language, hierarchies, and strategic approaches.

...In truth this stemmed from Taylorism, also known as Scientific Management. This theory was developed by Frederick Winslow Taylor in the late 19th century, but influenced today’s corporate language by introducing efficiency-focused terms like “time and motion studies” and “optimised workflows.”

...I spoke to Bryony Shannon about this on the Let’s Talk Ideas podcast. Bryony argues that the words we choose reflect our values and feelings, and shape how we think and act. She argues that when language focuses on processes, bureaucracy, and transactions, it can reduce people from individuals to labels – like “service user” or “case.” These words distance us from the very people we were employed to develop relationships with.

Those relationships then become mere transactions. As Rob Mitchell has said, when you’ve got a form and a process for every relationship “Love becomes relationships. Relationships become processes. Processes get processed.”

Frederick Winslow Taylor would have loved today’s world of process, customer segmentation and journey mapping. Such methodologies can approach humans lives as something that can be managed just like a car production line, or a canning factory producing baked beans.

Many developers don’t speak to users or collaborate with the business, instead they take direction from email threads and poorly written tickets. Remote, outsourced and offshore developers know this only too well. Even with better access to people, these developers would struggle to navigate organisational complexity, political decision-making, and siloed systems.

...Software development works best when developers interact directly with users, hearing about their experiences with the software and discussing what should come next. Conversations replace the need for requirements, and ideas and concepts are quickly put together and pushed out the door. Developers confidently release to real users because high-quality processes guard against adverse effects. Feedback happens in near real-time; a simple comment, under-the-breath muttering or facial expression is often enough to gauge reception. It sounds like fantasy, but commercial software really was built like this, and still is in many startups and small companies.

Customers have trouble distinguishing between essential features and those that are just "nice to have." Examples of the latter class: those arbitrarily overlapping windows suggested by the uncritically but widely adopted desktop metaphor; and fancy icons decorating the screen display, such as antique mailboxes and garbage cans that are further enhanced by the visible movement of selected items toward their ultimate destination. These details are cute but not essential, and they have a hidden cost.

/

Increased complexity results in large part from our recent penchant for friendly user interaction. I've already mentioned windows and icons; color, gray-scales, shadows, pop-ups, pictures, and all kinds of gadgets can easily be added.

I’m concerned with how I witness the work of user experience practitioners getting treated: like it’s just a set of motions toward a product’s all-important implementation, and one that we try to compress, due to its ostensible superfluity. Once the implementation is finished, the UX work appears to usually get discarded.

In today’s software, live video feeds are stuck inside static rectangles that can’t go anywhere. MakeSpace flips all that on its head. Your cursor is your live face, and you can roam free, controlling who and what you want to be close to.

What I sense is a real tension between the web as we know it, and the web as it would be. It’s the tension between an existing medium, the printed page, and its child, the web. And it’s time to really understand the relationship between the parent and the child, and to let the child go its own way in the world.

The problem with HTML is that most designers don’t know how to code. And HTML prototypes are usually more expensive to create compared to Figma.

But HTML prototypes are realistic and almost identical to the real thing...This makes research insights far more reliable.

Also developers have less to translate. Sometimes developers can use the code that has already been used for the prototype.

“But what if the designer can’t code?”

You either:

• Make do and increase the risk to UX
• Hire a designer that can
• Train your designer to use code
• Give your designer a developer to work with

“Do you really need to create an HTML prototype if you’re just testing the general flow?”

No, probably not. But at some point, you’re still going to want to test a high fidelity version to give you confidence and reduce risk.

Sometimes the problem is to discover what the problem is.

Whereas Juice is highly visible, Oil is really something you only notice when it's missing. A well-oiled hinge is smooth and silent, but a rusty one squeaks, groans, and annoys the crap out of you. If juice is all about making your game come alive and enriching interactions by maximizing the output you get for a single input, Oil is about minimizing the friction and effort that goes into making an input in the first place.

To put it another way:

Juice adds pleasure,
Oil removes pain.

In no objective sense were things better for UX [in 2010]. Most companies didn’t know it existed. Most who did, drastically underinvested in it. Those who were willing to invest in it were savvy enough to listen to thought leaders, but that was a paltry percentage of the real work to be done.

What’s happened by 2021 is that UX is not interesting in and of itself anymore. UX is a given. As Joe Lamantia said in a mailing list I’m on, “it’s furniture.” And the challenges and frustrations people are expressing are largely due to this maturation.

We’re moving from “the dream of UX” to “the reality of UX.”

This is the soul of what was lost in the jump from terminals to GUIs. Terminals, as the spiritual descendants of punchcard automation, invite you to marshal armies of automata. The GUI puts you at the center of the HCI loop and waits for each click or press—you turn the crank.

...If GUI is manual, and automation is automatic, maybe AI opens up the possibility of semi-automatic software?

The failure mode of automation is literalism and lack of reasonable limits on behavior = brittle. But LLMs are good at doing what you mean, not just what you say.

While Link can move a single pixel at a time, in any direction, the longer he continously moves in any direction the more he gravitates toward aligning himself with the underlying grid of the screen. The tile grid for LoZ is 16 tiles wide by 14 tiles high (including 3 tiles for the status display at the top of the screen). Each tile is 16×16 pixels. Link operates on a half-tile grid, though (32×28 tiles, 8×8 pixels each). As Link moves, if he’s not currently aligned with the half-tile grid, he is adjusted, one pixel at a time, toward the closest correction. As a result, if Link is 4 pixels off alignment he’ll line back up with the grid after moving 4 pixels.

...The correction prevents the subtle but annoying problem wherein the player would “snag” on the corners of objects that he anticipated passing by. The more the player moves contiously the more aligned Link becomes, which has the same effect as speed-sensitive steering in a car.

...The result for both actions in both games is the same: the player’s desire is successfully expressed in the gameworld, regardless of the potentially pedantic ways of the computer.

The best way to test a product is to use it yourself. What does it mean to dog food or fish food a product?

Dogfooding (verb) means using your own product before it's launched. Dog fooding can help with quality assurance, user experience, and potentially new ideas.

I'm not sure the first person to use the term, but it most likely comes from "eating your own dog food" – i.e., making dog food that you yourself would eat. Dogfooding usually (nowadays) refers to using a product much closer to release.

Fishfooding is a more nuanced version of dogfood for a much smaller selection of testers for a much earlier product.

To fishfood a product or use a product in fish food is common at Google, the only place I've heard the term regularly used.

The reason I’m mildly hostile to Lego is it takes away too much friction and engineering messiness in favor of simplicity of UX (PX? play experience?) and aesthetics (apparently this has been a trend known as “juniorization”).

...As a personal preference, I like to see the higher-dimensional messiness of real-world engineering reflected in a tinkering medium.

See, observe, learn how data are collected at moment and place of measurement. "You never learn more about a process than when you directly observe how data are actually measured," said Cuthbert Daniel, a superb applied statistician. See with fresh eyes. Walk around what you want to learn about. Talk to those who do measurements. See how numbers came to be.

Do those measuring know the desired answer? Are those measuring skilled, alert, honest, biased, incompetent, sloppy, tired and emotional?...Artifacts and errors in measurements measured? How are outliers adjudicated?

15 years ago, I helped design Google Maps. I still use it everyday. Last week, the team dramatically changed the map’s visual design. I don’t love it. It feels colder, less accurate and less human. But more importantly, they missed a key opportunity to simplify and scale.

There are two kinds of dark mode.

On one side, you have what we like to call the “performative dark mode.” You’ve seen a couple of your users say they desperately want dark mode but haven’t really dug into why that is. After all, it’s trendy. This kind usually involves flipping the colors and writing a blog post about it so you can get some eyeballs on the update. You will get cheered on social media and get some “FINALLY!! 🔥🔥” replies.

The other one, which we see as the better option, is making dark mode one piece of an accessible and readable UI/UX that presents your features well to all your users. Not to say you can’t write a blog post about your new dark theme or high-contrast UI. You should, because it’s true, people love a refresh. Especially when it’s well thought out, mindfully executed, and part of a real commitment to good UI/UX.

These two takes are similar to how people perceive UI versus UX. While aesthetics and visuals are extremely important and can be a great hook, long-term value can only be created when the overall experience (how your product feels) matches how your product looks.

That means that every visual choice you make — layout, colors, typography, images — must be focused on getting a distracted, rushed, and emotionally-driven brain through their initial sub-conscious vetting and into the kind of systematic processing — detailed and focused review — you assume they’ll do initially.

3: The best way to improve software UX is regular direct observation, by everybody on the team, of the work done.
20: Have some personality.
27: Minimalism is garbage.
35: Metaphors are fantastic.
36: Naming things is fantastic.
41: Try to write HTML that would make sense and be usable without the CSS.
69: The buyer is quite often wrong. That fact never changes their mind.
70: Working on a functioning app’s codebase does more to increase its quality than adding features.
72: A good manager will debate you, and that’s awesome.
83: The term ‘project’ is a poor metaphor for the horticultural activity that is software development.

The experience we have using the web deserves our attention; when the web loses, we lose too.

The front web is systematically undermined, and the main targets are precisely the aspects that make the web a powerful medium.

While these attacks are systematic, I'm not sure how conscious and intentional they are: are we never satisfied with what we have and we keep trying to improve it, or are we just “breaking things”?

Whether we are breaking things around or trying to improve the front web, what is clear to me is that instead of getting the most of it, we just keep making it heavy, inaccessible, unmanageable, and offering a very bad UX. It is hard to say who is benefiting from these attempts.

It turns out there are no “simple” concepts. There’s a surprising amount of detail all around us.

I’d argue that this is a useful mental model for consultants working with clients. (Is the client changing? Sort of? It doesn’t really look like they’re changing): clients have a surprising amount of detail.

Vintage models blended in, new ones stand out.

When photography pioneers used Leicas, the cameras weighed 200-300g—perfect for discreet shooting. Modern Leicas tip the scales at over 700g and cost around $10,000. Hardly inconspicuous under any aspect.

This reminds me of how Apple stopped making the iPhone mini and now sells bulkier, pricier models. Leica's rangefinder cameras have also forgotten their original goals.

...Leicas take beautiful photos, but a heavy status symbol seems at odds with the heritage of street shooting candid shots. Like you don't need a Pro phone to be a professional at anything except doomscrolling, or like Hemingway didn't write his novels with a Mont Blanc, you also don't need a Leica to take great pictures. Especially now, especially for street photography.

That's what many brands now do: they sell you a status symbol, but not the ability to have fun and get better at a craft.

A Small Matter of Programming asks why it has been so difficult for end users to command programming power and explores the problems of end user-driven application development that must be solved to afford end users greater computational power. Drawing on empirical research on existing end user systems, A Small Matter of Programming analyzes cognitive, social, and technical issues of end user programming. In particular, it examines the importance of task-specific programming languages, visual application frameworks, and collaborative work practices for end user computing, with the goal of helping designers and programmers understand and better satisfy the needs of end users who want the capability to create, customize, and extend their applications software.

As a banana who lives among humans, I am naturally interested in humans, and in the social sciences they use to study themselves. This essay is my current response to the Thiel question: “What important truth do very few people agree with you on?” And my answer is that surveys are bullshit.

...The ordinary survey, in its ordinary conditions, is of no evidentiary value for any important claim. Just because there exist rare conditions where survey responses tightly map to some condition measurable in other ways does not mean that the vast majority of surveys have any value.

Here’s the harsh truth: I’ve reviewed more than 1,000 portfolios in my design career so far and I turned 90% of them down because of one thing — the linear design process.

By “linear design process” I mean cookie-cutter case studies that always read the same. The designer learned about a problem, conducted user interviews, created user personas, proceeded to sketches, then mockups and wireframes, made everything beautiful through visual design, created a prototype, and tested it with five users. Everything was perfect so they also created a design system which is not a design system but a style guide. But they call it a “design system” because it’s trendy and a keyword for the recruiters. 

It’s like finding a product that you want to buy online and it only has 5-star reviews. When everything is shown as perfect it loses credibility — are the reviews fake? It’s the same when I review your cookie-cutter portfolio — when everything’s perfect I wonder whether it’s all fake.

...Here’s how you fix it: Include the messy details and tell a story

Adding half a second to a search results page can decrease traffic and ad revenues by 20 percent, according to a Google study. The same article reports Amazon found that every additional 100 milliseconds of load time decreased sales by 1 percent. Users expect pages to load in two seconds—and after three seconds, up to 40 percent will simply leave.

Can you keep up? If you’re designing sites with rich content, lots of dynamic elements, larger JavaScript files, and complex graphics—like so many of us are—the answer might be “no.”

It’s time we make performance optimization a fundamental part of how we design, build, and test every single site we create—for every single device.

Jakob Nielsen says that Flash is “99% bad.” I have to agree. Flash always reduces usability.

On the other hand, every time I read Jakob Nielsen, I get this feeling that he really doesn’t appreciate that usability is not the most important thing on earth. Sure, usability is important (I wrote a whole book about it). But it is simply not everyone’s number one priority, nor should it be. You get the feeling that if Mr Nielsen designed a singles bar, it would be well lit, clean, with giant menus printed in Arial 14 point, and you’d never have to wait to get a drink. But nobody would go there, they would all be at Coyote Ugly Saloon pouring beer on each other.

When developing an app or service, a lot of time and thought is put into the onboarding experience.

What's the optimal flow? How do we introduce people to all the great features we built? How do we make sure they don't skip past the important parts?

First impressions and all that. It's a never-ending process.

I wish the same were true for offboarding. For making it as easy and painless as possible for someone to move out of a platform.

My ideal offboarding experience is as easy and frictionless as possible. It's about offering the best possible service right up until the end.

The better you know something, the less you remember about how hard it was to learn.

The curse of knowledge is the single best explanation I know of why good people write bad prose. It simply doesn’t occur to the writer that her readers don’t know what she knows - that they haven’t mastered the patois of her guild, can’t divine the missing steps that seem too obvious to mention, have no way to visualize a scene that to her is as clear as day. And so she doesn’t bother to explain the jargon, or spell out the logic, or supply the necessary detail.

It’s called the Rabbit R1, and it … well, I don’t know what it does. The webpage says it’s “your pocket companion,” and it runs on “a personalized operating system through a natural language interface,” and it has a “push-to-talk button” and a “far-field mic” and a “360° rotational eye.” The page gives me an “Order Now” button and links me to a 25-minute “keynote” which could be or say anything, there’s no information. There’s an FAQ page, which also offers no information about what this thing is. Are these people serious? They make an entire webpage for this thing and a way to buy it and they can’t spare one word to tell me what it does? What is going on in Silicon Valley? Do the people there think they only have to say Here’s A New Thing and people will line up to buy it?

"How often do you..." vs "How often would you..." vs. "Last week did you?". The responses to those could be wildly different. Did you check your words as closely as you checked your results?

If you slide back a few steps, you'll see that it's all a judgement call. How you asked, what you asked, when you asked, which words you paired together, how you started the question... All these things matter. In fact, they are the matter that form the answer.

And you know what? There's no right way. Which is the exactly the point I'm trying to make.

Your hard data comes from subjectivity. A sense of solidity built from mush. False confidence at the finish line, from a shapeshifting starting line.

To understand the user interfaces on microwave ovens, you need to understand that microwave UI designers are aliens. As in, literal nonhuman aliens who infiltrated Earth, who believe that humans desperately want to hear piercingly loud beeps whenever they press a button.

...This is the same species of aliens that thinks humans want piercing blue lights to shine from any household appliance that might go in somebody's bedroom at night, like a humidifier.

...Nobody knows why they insist on hollowing out and inhabiting human appliance designers in particular.

Metrics come up when we’re talking about A/B testing, growth design, and all of the practices that help designers get their seat at the table (to use the well-worn cliché). But while metrics are very useful for measuring design’s benefit to the business, they’re not really cut out for measuring user experience.

In a column entitled "March of the Engineers," the humorist and social critic Russell Baker lamented the complexity and sophistication of his office's new telephone system...Baker closed his column by defining the new telephone system as "another bleak example of the horrors created when engineers refuse to leave well enough alone."

In The Design of Everyday Things, Donald Norman wrote that "new telephone systems have proven to be another excellent example of incomprehensible design."

Too often, a popular consumer app unexpectedly gets worse: Some combination of harder to use, missing features, and slower. At a time in history where software is significantly eating the world, this is nonsensical. It’s also damaging to the lives of the people who depend on these products.

...Maybe we ought to start promoting PMs who are willing to stand pat for an occasional release or three. Maybe we ought to fire all the consumer-product PMs. Maybe we ought to start including realistic customer-retraining-cost estimates in our product planning process.

We need to stop breaking the software people use. Everyone deserves better.

Too many product managers and product designers want to spend all their time in problem discovery, and not get their hands dirty in solution discovery – the whole nonsense of “product managers are responsible for the what and not the how.”

Noted designer and architectural theorist Bernard Tschumi would call the predictable repetition of events inside an architectural space a sequence: a linear series of actions and behaviors that are at least partially determined by the design of the space itself.

Problem

No building ever feels right to the people in it unless the physical spaces (defined by columns, walls, and ceilings) are congruent with the social spaces (defined by activities and human groups).

Solution

A first principle of construction: on no account allow the engineering to dictate the building’s form. Place the load bearing elements—the columns and the walls and floors—according to the social space of the building; never modify the social spaces to conform to the engineering structure of the building.

In biology, when researchers want to observe animals in their natural habitat, it is paramount that they find a way to do so without disturbing those animals. Otherwise, the behavior they see is unlikely to be natural, because most animals (including humans) change their behavior when they are being observed.

Indifference towards people and the reality in which they live is actually the one and only cardinal sin in design.

The duty of industrial design is first and foremost to users and the users are, generally, human beings, with all their complexities, habits, ideas and idiosyncrasies.

Computers can aid humans in our most noble endeavors: art, science, thinking, self-improvement. But today’s dominant computing platforms increasingly work against the needs of creative professionals. Ink & Switch is an independent research lab working on this problem.

We can imagine, for example, mechanisms by which a user debugs a particular formula by bringing up a view of the spreadsheet in which irrelevant rows and columns are filtered out, and related cells are highlighted.

After the first websites demonstrate the commercial and aesthetic potential of the web, the media industry floods the web with a surge of new content. Amateur webzines — which define and voice and tone unique to the web — are soon joined by traditional publishers. By the mid to late 90’s, most major companies will have a website, and the popularity of the web will begin to explore. Search engines emerge as one solution to cataloging the expanding universe of websites, but even they struggle to keep up. Brands soon begin to look for a way to stand out.

The ability to significantly extend the functionality of the product via firmware upgrades feels like it‘s increasingly possible to reveal new devices from within the existing device. It’s almost as if one simple firmware upgrade had me sensing that battery life had just increased, that there were additional functions, that I felt like I had a whole new iPod. The physical aspects of the product—control wheel, four navigation/select buttons, screen and a couple of ports—are abstract enough to enable improvements by simply remapping new elements of the software.

Learning to design is, first of all, learning to see. Designers see more, and more precisely. This is a blessing and a curse—once we have learned to see design, both good and bad, we cannot un-see. The downside is that the more you learn to see, the more you lose your “common” eye, the eye you design for. This can be frustrating for us designers when we work for a customer with a bad eye and strong opinions. But this is no justification for designer arrogance or eye-rolling. Part of our job is to make the invisible visible, to clearly express what we see, feel and do. You can’t expect to sell what you can’t explain.

This is why excellent designers do not just develop a sharper eye. They try to keep their ability to see things as a customer would. You need a design eye to design, and a non-designer eye to feel what you designed.

Not only is web performance a user experience issue, it may well be the user experience issue. Page speed has a proven demonstrable direct effect on user experience (and revenue and customer satisfaction and whatever other metrics you’re using).

AI and automation is often promoted as a way of handling complexity. But handling complexity isn't the same as reducing it.

In fact, by getting better at handling complexity we're increasing our tolerance for it. And if we become more tolerant of it we're likely to see it grow, not shrink.

...But something that can genuinely reduce complexity, rather than just mask it, is good design.

Good, user-centered design is how we can deliver services with just enough complexity - enough to model the rich diversity of people's circumstances, but no more.

It is something to be able to paint a particular picture, or to carve a statue, and so to make a few objects beautiful; but it is far more glorious to carve and paint the very atmosphere and medium through which we look, which morally we can do. To affect the quality of the day, that is the highest of arts.

Design thinking sells a fantasy. It sells you the fantasy that with some guidelines, templates, and sticky notes, you can do what IDEO does just like how they do it.

…if it were true that design thinking lets you do what the best designers do, IDEO could put themselves out of business. If they were really selling you the absolute guide on how they solve problems, innovate, and design, you wouldn’t need IDEO. Their idea to save their business from a slump hypothetically cannibalizes their business…Unless they knew that it wouldn’t.

[We observed that] most people just used Excel to make lists. Suddenly we understood why Lotus Improv, which was this fancy futuristic spreadsheet that was going to make Excel obsolete, had failed completely: because it was great at calculations, but terrible at creating tables, and everyone was using Excel for tables, not calculations.

Bing! A light went off in my head.

The great horizontal killer applications are actually just fancy data structures.

Spreadsheets are not just tools for doing “what-if” analysis. They provide a specific data structure: a table. Most Excel users never enter a formula. They use Excel when they need a table. The gridlines are the most important feature of Excel, not recalc.

Word processors are not just tools for writing books, reports, and letters. They provide a specific data structure: lines of text which automatically wrap and split into pages.

PowerPoint is not just a tool for making boring meetings. It provides a specific data structure: an array of full-screen images.

1. Nothing
2. Loading
3. None
4. One
5. Some
6. Too Many
7. Incorrect
8. Correct
9. Done

We're bombarded by more information than ever before. With the rise of all this information comes a rise of the amount of bullshit we're exposed to. Death to Bullshit is a rallying cry to rid the world of bullshit and demand experiences that respect people and their time.

...As the landslide of bullshit surges down the mountain, people will increasingly gravitate toward genuinely useful, well-crafted products, services, and experiences that respect them and their time. So we as creators have a decision to make: do we want to be part of the 90% of noise out there, or do we want to be part of the 10% of signal? It's quite simple really:

• Respect people and their time.
• Respect your craft.
• Be sincere.
• Create genuinely useful things.

I've had clients ask "What do I buy to make this accessible?" or "What can I buy to improve usability?"

In all these cases there are unscrupulous people who will sell you a magic cure-all - but the real answer is that these things are a process; not a product.

Yes, you can buy tools which will help improve your security / accessibility / usability etc. But unless you put processes in place to get people to use them effectively, the tools are useless.

Security is a verb - it is a doing word.
Accessibility is a verb - it is a doing word.
Usability is a verb - it is a doing word.

Buy nouns which support your verbs.

Driving down the cost of operating all those systems is core to your business as a vendor, and that’s argument toward elegance in architecture on its own.  However, probably just as important to your offering is the effect of what you have in the background has on your user’s experience.  And obviously, that’s something that your customers care deeply about.

“No modes.” – There’s a story about Macintosh development at Apple in the early 80’s. Larry Tesler and Jef Raskin fought hard against software that forced the user to change “modes.” Larry Tesler even had a license plate that said “NOMODES.” ...Unfortunately, even in 2010 enterprise software is rife with ‘modes.’ ...Companies built by acquisition frequently “smush” their web products together and make you switch applications as well and then call that “integrated.” Yuck. 

Switching “modes,” as it were is a key clue that what a vendor is selling you isn’t truly connected under the covers.

Usability and aesthetics usually go hand in hand. In fact, there is even what we call the “Aesthetic Usability Effect”: users perceive beautiful interfaces as easier to use and cut them more slack when it comes to minor usability issues.

Unfortunately, sometimes usability and aesthetics can be at odds, also known as “form over function”.

I've been thinking a lot about the type of software I want to build and use. I spend so much of my screen time using large feature-heavy software, which are one-size-fits-none at best or outright hostile. I'm left frustrated, distracted, and wanting something better.

I write lots of mini software projects as a hobby, and a couple have been successful. By success I don't mean that other people use them, but instead that I keep using them. Or that my toddlers played with a couple mini games I built, which taught them to use a keyboard and mouse. These are not things I'd ever put on my resume or claim as examples of good code, but I'm oddly satisfied each time I build one.

...Building software for yourself that you'll actually enjoy using is an adventure in self-discovery. You'll learn a little more about what motivates you and how your brain works. Starting with something small like a to-do list helps you focus on your personal user-stories instead of getting caught up building complicated internals.

Of course the output of a solid design process can be groundbreaking and beautiful. It's also true to say it requires a creative mind to find solutions to tricky problems. But one of the things I love about design – and service design in particular – is that it's more about fixing the basics than coming up with the shiny thing.

When you fix the basics – through a process of internal service design – you get satisfied customers, more efficient operations, and happier people in your organisation. Those are the real by-products of a design project that is successful, meaningful and has a positive impact.

I was building some flatpack furniture the other day (my life is so glamorous) when I came across an interesting example of how not to write technical documentation.

Drill a hole in part A and insert part B once you have ensured part C has been aligned after its connection to A.

Most people can handle reading a whole sentence to figure out what's going on. But, after a tiring day of building, it is somewhat annoying having to juggle instructions into actions.

Most readers will assume that instructions are written in linear time. Do this, then that. But that example is non-linear. What it is trying to say is:

Connect part C with part A. Then align part C and part A. Then drill the hole in part A. Then insert part B into part A.

It is slightly less interesting writing. But it presents all the actions in the order they need to be taken.

I see this temporally-mixed anti-pattern all the time.

Last week I saw several articles about the passing of human-computer interface expert Larry Tesler. Most of the headlines mentioned his invention of cut-copy-paste, but if you read more deeply one of the things he really emphasized was eliminating modal interfaces—he even got a vanity license plate that said “NO MODES”.

I realized this morning that this is exactly my gripe with the Workday timesheet application: it’s extremely modal, where the one we used to use with our in-house developed HRMS was almost completely modeless.

...In summary, this interface is almost completely modal: each page only lets you do one thing, and you have to click through pages and pages to complete the full task.

This is why Larry Tesler fought against modal interfaces: they make it harder to get the job done. And he had this figured out back in the 1970s. Too bad big software companies like Workday still don’t understand this, or don’t care.

I believe our job as designers is to give you what you need as quickly and elegantly as we can. Our job as designers is to take you away from technology. Our job as designers is to make you smile. To make a profit by providing you something that enhances your life in the most seamless and wonderful way possible.

You could think of this as an example of end-user programming. But I’ve always found this term a bit odd, because it implies a dichotomy: either you’re a programmer, or an end-user.

To me, the more interesting distinction is the context of use. I’m a professional programmer, and there’s a whole class of problems that (a) I know I could solve by writing some code, but (b) they’re not really Serious Business™.

...To me, the distinction [between end-user programming and casual programming] is important: I’m specifically interested in ways of making the power of programming available in a much more casual, informal way.

My dad was a pharmacist. Whenever I was ill, he’d tell me to take paracetamol. So I did. And it made me feel better. But paracetamol doesn’t actually make you better. It only makes you feel better. It treats the symptoms, not the cause.

For example, let’s say you have a headache because you’re dehydrated. But you don’t know you’re dehydrated so you take paracetamol. And the headache goes away. But you’re still dehydrated so your headache comes back later.

In this case, what you needed was a glass of water. You needed to treat the cause, not the symptom. But the problem is that not all ailments go away instantly with a glass of water. Some ailments take longer to heal. So people take a pill, feel better and go about their life. But over time this can lead to more problems.

I see the same thing happen all the time in UX.

No matter how fancy your Figma file is or how beautiful and lovingly well organized that Storybook documentation is; the front-end is always your source of truth. You can hate it as much as you like—all those weird buttons, variables, inaccessible form inputs—but that right there is your design system.

...being honest about this is the first step to fixing it.

In retrospect, 2023 felt like the closing of a chapter. At least for a class of design leaders, who spent more than a decade participating in a massive expansion of design’s role across every sector of business, from tech to accounting firms and insurance companies.

...The very people who advocated successfully for a “seat at the table” when design first made inroads into big business (and jump-started thousands of creative careers) find themselves at major crossroads with fewer seats left.

<a href=“LINK_URL” target=“_blank”>
    LINK_TEXT
    <img aria-hidden=“true” src=“ICON_URL”/>
    <span class="visually-hidden”>Opens in new tab</span>
</a>