UX, Compassion, and Software
User eXperience design, or UX is often thought of as “sketching our application’s screens and fretting over stuff like accessibility while sipping espresso.” But there’s not always espresso. And UX is not just sketches, it’s the part of a broader, and much older discipline — communications. It’s time to start thinking about UX broadly, as something that extends in all directions. From the documentation you write for your customers, to the software you build for yourself, to even how your team interacts with each other — all of these things are UX.
When you use a well-made application and it actually does the thing you wanted the application for, you are benefiting from the work of a skilled UX designer. When you can’t find settings, the application doesn’t do what it promised, and you want to chuck your phone across the room, you are having a poor user experience.
But why do we think of UX as a narrow thing?
UX is not positioning buttons, it’s not skeumorphism vs. flat UI, it’s not the ordering and placement of screens — those are the result of user experience design, but not the meat of it. Good UX comes from serious thinking and consideration along a line of questioning similar to this: “Who is going to use this thing? Why do they need it? What do they think the thing we’re making will do for them? How can we make sure it does that?” It is having compassion for the person who has to use what you’ve built — respect for their needs and wishes, their ability, and their time.
It’s a common mistake in the software world to assume that the user cares about your software. “Surely,” you imagine, “surely they will read this beautiful documentation, delight in our philosophy, admire our code, and come away with a better person for it.” But let’s be honest: they won’t read your docs or your code. Your philosophy doesn’t matter because they’re not looking to become a better person. They’re trying to solve a real problem that they have. If they cannot solve their problem before frustration sets in, you lose. And they lose too — what could have been a beautiful interaction, helping them on their way, is yet another frustration piled on the litany of computer-induced frustrations they’ve had.
Mentally, I’ve moved UX to the broader category of “Communications” because there is no reason to limit “user experience” to software only. Communications, not “communications technology” — the study of how to effectively share thoughts & ideas.
Effective communication requires close attention to the audience and consideration of both the audience’s understanding and the communications medium. What works well in a live presentation does not work in a written piece. What works in a magazine article doesn’t work in a blog post. What works in a blog post doesn’t work in an internal wiki page.
Good communicators strive for an understanding of their audience — both who that audience is, and how they think about the world. How they will receive the message. Then they get to work, and tailor their message to that audience. To do this well requires compassion because we’re really only familiar with one perspective: our own. The more the message fits with the audience’s world view and thinking, the better it is received.
So let’s consider, for a moment, the UX of the environment that surrounds your software project — documentation, team members, source code management, planning, marketing, etc.
When a potential user comes to your project’s page on GitHub for the first time, they are having a user experience. What does the README tell them? Does it help them meet their goal? Can they find what they need? Does it explain the project clearly and simply? Do they feel welcomed or are they put off?
When you commit code to your software, is it clear why you changed every line? Are your commits tiny and focused, or do you just git commit -am "Did this that, and the other, fixed something else."?
I now consider crafting commit history and splitting big commits into smaller hunks another facet of UX. When someone reads the history of this branch, will they see the logical progression of commits?
So much of what surrounds your project is writing. Issues, wiki pages, documentation: screens full of text that someone must read and interpret. Consider reading these also part of the total user experience.
When you write, how much do you assume the reader knows? That is an important question. It pays to take your fancy college writing down a notch. Use smaller words and shorter sentences to make your points. Drop your (parenthetical discussions) and interesting side disussions, and “quotes from literary sources.” Don’t waffle, make your points clearly and logically. State assumptions. Study good technical writing and learn from the plethora of bad documentation you come across.
Yet good user experience is more than good writing. It’s also taking into account that humans use your software. That humans forget things, and make mistakes. It’s leaving signs so they can find their trail later on, and it’s reducing the risk of making a catastrophic mistake.
When you solve an IT problem for someone at work, do you spread that knowledge around your team? Do you quickly move on to the next thing, or do you write documentation? Do you leave breadcrumbs in your group chat & other communications? Thinking about these things I’ve started carefully crafting chat messages to add lots of searchable “hooks” for someone to find later. I cross-link articles I write on the internal wiki. The more places someone can find a piece of information, the better.
When you design a system, do you account for mistakes? This is the hardest part of designing a good user experience. When your team does a deployment, how many things do they have to remember? How do they make sure they’re not shipping new defects? Assuming perfect memory and flawless execution is a trap — people are not machines! People get sad, upset, hungry, argue, fight, and forget. How many mechanical steps can be taken out of the operator’s hands and scripted, leaving the human to focus on what’s important to them?
Let’s stop thinking about UX as a narrow discipline, and embrace the wider perspective. Having compassion for the people who use the things we build makes us better builders.
Producing tools and systems considerate of people makes the world a better place. People need systems built with human constraints in mind, systems that help them do what they need to do. Systems that remove friction, not add it. Systems that respect a person’s time and attention instead of wasting it.
Work respectful of these human constraints doesn’t just have legs — it has wings.