The Hidden Complexity of “Just”
Designers often see the world through a different lens. Every minor obstacle becomes an exercise in how we can make something better. I bet you can think of a time this very week when you saw something and thought “Why’d they design it like that?” or “I bet I could design this better.” This proclivity toward wanting to fix things or make them better mostly serves us well. But in evaluating other work without a full understanding of its background, we can land on oversimplified solutions that don’t take the real world into account.
The problem with “just”
All too often, a quick response solution is phrased as “Why didn’t they just do X?” or “If I was working on this, I would just …” Maybe we don’t use the word just, but the connotation is still there. This is a simple fix, right?
We often sneak “just” into statements as a way of implying that there’s a simple, obvious way to do something. Using “just” as a crutch allows us to overlook assumptions and ignore experience. “Just” implies that not enough thought was given in the first place, without actually giving much thought ourselves.
Let’s look at an example
Even a [simple feature] requires some up-front thinking, some design.
Every so often, someone laments the fact that Twitter doesn’t allow you to edit your tweets. We’ve all been there. Typos happen! Why couldn’t Twitter just add an edit button? All we need is a simple button that — when clicked — allows you to edit a published tweet. What could be simpler, right? After all, Facebook allows to you to edit your status. What’s the big deal?
Did you catch that little “just” hidden above? It implies that adding a button is all they really need to do. But is that it? Let’s take a look at some of the potential pitfalls hidden underneath that “just”. Here are just a few scenarios that could play out:
- Someone publishes a tweet that gets a lot of attention. It generates thousands of retweets within moments. Then the author edits the tweet to something hateful. Now all those people who retweeted the original look like they endorse hate.
- Someone responds to another person’s tweet with an insult. A bunch of well-meaning followers of the original person respond opposing the insult. The insulter then changes their original insult to make it sound benign, but a slew of responses seems to pile onto them unfairly.
- A sitting President tweets in support of a candidate then retroactively revokes that support after the candidate falters by editing the original tweet.
- And on and on.
I’m willing to bet that even as you read the scenarios above, you thought “Well, to counter that, they could just …” Oops, there it is again. And now we’re spiraling out to a web of increasing complexity hidden under well-meaning intentions.
Why couldn’t they “just” …?
Next time you offer feedback or think about how you’d fix some feature of a favorite app, pay attention to how you frame it. If you find yourself using “just” or “simply” to gloss over implementation details, ask yourself what you might be missing. Here are just a few common possibilities:
- We tested that, and it made things worse, confused users, or led to other problems.
- We don’t want that action to be easier.
- The outcome of that solution doesn’t fit with our product principles.
- The cost of making that change outweighs the value it would provide.
- That solution is duct tape, and we’ve been working on something that could solve the problem at a more fundamental level.
- Someone in leadership dislikes that solution and refuses to provide the necessary resources to make it happen.
- Or finally, we hadn’t thought of that! What are the advantages and disadvantages of that option?
What to do when you “just” want to …
We’re not going to change our nature overnight and stop thinking of better ways to do things. In fact, we shouldn’t. That capacity for improvement is what drives us to become better designers. So how can we avoid the pitfall of “just”? Here are some ideas:
- Catalog your own assumptions before coming to a final conclusion. Explain what problem you are solving, and why you think your solution is better. What fundamental assumptions are you making that explain those?
- Challenge yourself to come up with 2–3 alternative solutions. By looking at other options, you force yourself to look at the problem from different angles and unveil pitfalls your initial thought may have ignored.
- Explore how your solution could fail. Consider how both unintentional confusion and intentional malice from users could affect how your idea could make things worse.
- Present your idea to others. A fresh perspective will often shine light on things you may have missed. Even the practice of explaining it to someone else may illuminate pitfalls your initial solution ignored.
- Ask the makers of the project why they haven’t implemented a solution like yours. Make sure to frame it from an angle of genuine curiosity and friendliness instead of spite and superiority.
Learning to “just”
“Just” makes me feel like an idiot … “Just” is a dangerous word.
That word can sneak into other places as well. How many times have you read (or written) documentation where the instructions tell you to “just” perform a task that assumes detailed knowledge of a domain you have little experience in?
- Just use Craft to fill data in your Sketch file …
- Just install this script via NPM …
- Just recruit a few remote participants …
The swift progress of technology far outstrips our ability to master every aspect of it. When writing or teaching others about something, don’t assume they have the same underlying background and experience that you have. When you’re tempted to tell others to “just” use this technology or “just” modify that technique, take a few extra moments to examine your assumptions and provide some extra context. Remember, we’re all beginners in one way or another, and do your best to help your fellow beginners along.
Originally published at uxcellence.com on November 17, 2017.
