Behind my desk, in a frame, there's a pink sticker. If you're ever on a video call with me, and you squint, you will see it on the shelf just below where I also have a beautiful, handmade replica of a late Neolithic Irish food vessel. On the sticker is a rainbow, and it says, "It's just f*cking computers." You can't read it from that distance, but now you'll know what it says.

I made the sticker 5 or 6 years ago because I was working on a project where a perfectly nice but overconfident CEO had decided to project manage a thing himself, and if you're at all experienced, you'll know that way only leads to chaos and despair, which is exactly where we went.

I did my best with what I had power to affect, and I gave what I thought was my most productive advice, along with what I hoped was a solid set of deliverables. And they built a thing that was, to be frank, a huge turd. And they were happy with it. I found it hard to process: rather than actually use the hard work and deep thought I'd put into research, design, and craft, they took pieces of it and squished it into a turdy mess, and felt fine about it. I learned a lot on that project. They paid me on time, and they were incredibly nice. But I still felt sad that they hadn't wanted my best work, not even the pretty OK work I had done for them.

Around that time, I came across one of those "how do you explain your UX job to your mom?" social media posts that always make me lose my temper, especially as a mom-type who is perfectly capable of understanding a wide range of job descriptions, even though I am only really interested in the details if you're something like a professional falconer (they exist!) or you work in the sewer or on a ship.

People were sharing stories about trying to explain UX processes at holiday meals, and joking that their moms still just tell people they do "something to do with computers," and I'm like...Does it matter that much that the person who taught you to eat with a fork and use underpants has a clear understanding of what UX is, when the executives at your own company probably don't? I don't care if people that have nothing to do with my work understand what I do for a living. I worried a little bit that I should. (For the record: my mom does understand what I do, but, to my shame, I am not entirely sure what she did before she retired). 

But the perception of what we do is true, and it’s fine. Stuff with computers. It is what we do. There are better things to talk about at the dinner table, like dogs we’ve met or how all the Cybertrucks will be crusty, heat-buckled Dutch ovens by the end of their first summer parked in the driveways of the world’s most divorced dudes. If I did my best on that project and this perfectly nice person didn't care that it could have been better, who cares? My job isn't more important than theirs, and they took as much of the work that I did as was necessary to theirs, and moved on. I know what I would do differently now, but I could only have fixed it if they decided they also wanted it to be good.

It’s hard because I’m deeply invested in my work. I care a lot about my clients, about the people I work with, and I find it incredibly satisfying to dive into someone else's problems, and isn’t it exciting to find them all because every problem is a bit of human texture that reminds us we’re in charge, not the machines. I love doing a great job and, even more, I love helping other people do a great job.I care what "good" looks like and I want other people to care about that, too. But we're not always set up for success. And that frustrates me because of what our job actually is. 

Our job isn't to make things for people to use

I like making good things that work, but when it comes to the craft part, I don't think of my job as helping people use products. I have always believed that our job is to help people stop using products. 

If it's the right kind of product and we can give them a moment of delight or joy—rather than take their time to do a little attention-seeking interaction dance—that's great. But mostly our job is to get them to not care at all about the product because it's just a thing that does a thing. They should not have to waste their one wild and precious life getting mad at that thing. Even if I’m building a login flow, the goal is to help them log out again as quickly as possible.

And that's because of this thing that I also believe, and exists in permanent tension with the "just f*cking computers" idea, which is that nobody wants to use any software, ever.

Nobody wakes up in the morning thinking, "I want some software."

We're all overrun with apps, some of which we choose to use, probably to communicate with the friends we could be hanging out with if we didn't have to spend so much time yelling for computer reasons, and some are the computer reasons we are yelling. These things that force us to use our brains for purposes other than growing tomatoes or making friends with neighborhood dogs. The only reason we don’t throw our phones into the sea is that this is how we talk to our friends. We want to be creative, express ourselves, and connect with other humans. We do not want to use software.

I'm not talking about the jobs-to-be-done framework, where customers "hire" your product to solve a problem for them. That's always made me sad because the example people use is this thing where someone is "hiring a milkshake" for the value it provides. The JTBD framework flattens out all human interactions with things in the world as if our brains and bodies are some kind of neoliberal honeycomb of market opportunities. I want a milkshake. I want to drink a milkshake, preferably with a friend, while we sit around and talk in person.

Software, I do not want.

There are some things that can be intrinsically enjoyable that also require effort, and which, when they run smoothly, are delightful. Taking a train, for example. If you like driving, maybe driving a nice car on a smooth road with no traffic. But the job of the road is to get the driver where they’re going, as safely and efficiently as possible. And in fact, creating more and more road and highway systems created more and more demand, more traffic, and more misery (and fewer intrinsically delightful trains). Like roads, software might solve a real problem of getting a person from one experience to another experience, but it has become a problem in itself. The user need isn’t about the road, it’s about not being on the road anymore.

I do not want any software 

I believe that this mindset is the healthiest way to design and build things that people will use and not hate us for building. For me, it's a way to remind myself that all humans have a whole rich, challenging life outside of the little screens I'm making for them. So that even when I'm focused on user needs and user problems, I can keep it just out of the corner of my eye: the person I'm making this for doesn't actually want to be here, and that’s OK.

We want speedy internet and fast-loading services because we want to stop pushing buttons and opening accordions as quickly as possible. Pavel Samsonov talked about this, pointing out how far the user story has strayed from its goal, and the reality that the ideal is that people reach their goal without using software at all. 

It's what I think helps me design and create and plan and defend my work with integrity. It helps me remember that I am not entitled to more of a user’s time than this problem is worth. If I make the solution more annoying than the problem, they will choose to live with the problem, and that makes me part of the problem. I don’t need to make them like me or this product, I’m here to get them through this thing.

I share this Facebook update with permission from my friend, who had this thought around the time I started writing this post, which was just going to be a shortish LinkedIn post at first (and now I have a blog, I guess).

There’s still a clown show of articles being published about how people are “addicted” to screens and the infinite scroll, but how much of the time spent looking at screens is actually frustration? Even the best experience possible is still part of a landscape of other experiences that most of us aren’t choosing to use. The person you saw mopping their brow, shouting “Representative!” down the phone has also been forced to use half a dozen software products today.   

Reminding myself that nobody wants to be there helps me think about where users are in the world, outside of a flow or a step. Are they standing in the rain, with a sopping wet sock because the mud just sucked the rain boot off their foot? Do they have to close this modal we’re building with a wet finger? Are they sitting comfortably, on a couch, covered in dogs, and someone on our team wants to send users a push message? Will moving their elbow to snooze the message disturb a warm, sleepy labrador who was dreaming of a cheese wheel? Are we making them—don't say it—create another password?

I am frustrated by bad design because I want to design the kindest, least irritating things I can for all the other people who want to be relieved of clicking and scrolling, so they can drop down and just pet a dog. For example, I like making password reset flows simple because I don’t think anyone should need to push things out of their brains that they actually want, in order to remember the strong password they need for a system that’s not worth anything to them (don’t talk to me about password managers—most regular people don’t use them). 

And at the same time, we’re often up against what Ed Zitron calls The Rot Economy. A lot of the time, we’re not there to design for those users who don’t want to be there, we’re there to “make the number go up,” or soothe the ego of someone who doesn’t listen to people at our level (and then we blame ourselves for bad stakeholder management, which is a whole other article). We should make the software as usable and non-infuriating as possible, but we can’t fix everything because we’re not in as much control as we sometimes act like we are. Even if what we’re building hasn’t been absorbed into the rot, it exists in a landscape full of it, and nobody is happy.

So, breathe in, nobody wants to use any software. 

Breathe out, it’s just fucking computers. 

I can do the best job I can with the constraints I’ve been met with, and I can try to get them back out of the software as quickly as possible, but I can’t fix the fact that they are using software when they’d rather be eating mozzarella sticks. Because I, too, would rather be eating mozzarella sticks.

It’s OK to call them “users”

Calling them users (or whatever more specific term we have for the user group, which is always best) is a way to remind ourselves that what we build is only the tiniest part of most people's lives. I get frustrated when people say we should say "people" when not all people use the stuff we make, nor should they. We do not need to overstep our relevance. 

Users are a subset of people and they are, for us, defined by the time and effort they spend with our product, which, if we do our jobs well, is not any more than is absolutely necessary. They get to go back to being people when they're not using our product. (Even though, in reality, they're probably moving on to another piece of software they don’t want to use.)

I say all of this because I enjoy the craft. I enjoy my work. I enjoy working with good people to make a thing that the users and customers or whatever we can call them can finish using, close down, log out of, or click X to close. I hope nobody ever screams at their phone or their computer because of what I've done. I'm sure they have, and I hate it. 

Breathe in, nobody wants to use any software, and I’ve made someone shout because hey guess what, someone wanted me to write a tooltip instead of thinking through the users’ information needs in the flow beforehand. 

Breathe out, it’s just fucking computers, and there’s only so much I can do to make it easier for users to swallow the fact that management wanted to replace human interactions with software that they don’t want to use. 

I can make the software as usable as possible, but I also need to remember that it’s not in the software where we’ll fix the problems that cause the software to exist in the first place. This little meditation reminds me that we don’t need to overegg what we make with a million features, and it’s our job to dig in to the real problems (feature request lists are one type of computer-related screaming for me), but we can still hold on to the fact that the software, even if it solves a real problem, likely solves a manufactured problem that might have been caused by the existence of some other software or process, all of which is getting in the way of petting a dog or eating 4 mozzarella sticks in a row off the appetizer tray. 

Our job is to help them close the thing, and go from being a user to being whoever they want or need to be. We don’t need to delight people in the software itself. Delight in software is almost always a delay.

There’s so much delight in the world to be had. We need to get out of their way and let them sniff the corn-chip paw pads of a sleepy dog, take in the smell of the rain, have appetizers with a friend they only otherwise talk to on an app, or drink a milkshake too quickly and get brain freeze.