The other day, I was golfing in my league, at a course I had played many times. As I was trying to figure out which club I should use for my second shot, I looked around the course for something specific—an indicator to let me know how far away I was from the pin. This course plants bushes on either side of the fairway at 150 yards out.
But I questioned what I saw. The bush didn’t look the same, and there were other bushes both closer and further down the green.
I asked my partner if the bush in question was the 150-yard marker, and he confirmed. I joked that if the course started planting more of these bushes on all of the holes, it would be quite infuriating.
And then I thought about a large aspect of my job—user interface design—and making interactions clear and meaningful.
The user experience aspect of a designer’s role involves making sure that we are building software that helps users do their jobs. The user interface part is about making sure users can complete their tasks quickly, efficiently, and stress-free.
To do those things, designers need to build trust with the users.
Trust is gained when users’ interactions have expected results, for example:
- “I expect this button to change colors when I hover over it.”
- “I expect that button to be more important than this button, because it is larger and a distinctly different color.”
Every time a designer makes a decision regarding how the UI looks or behaves, we are establishing rules—rules that we have to remember to follow as we build out more aspects of the UI. But these rules are also absorbed by users without much thought on their end.
Best Practices and the Problem with Components (Sometimes)
To save on development costs, we sometimes rely on prebuilt components. You’ve probably heard of Bootstrap and Material Design. These are component and design libraries that have all of the basic assets: buttons, calendar widgets, toggles, forms, tables, etc. They are easy to use as-is and mildly simple to adjust the style (colors, fonts, sizes), but a bit more complicated to manipulate and “stretch” how they work if needed.
All component libraries have their own best practices. None of them are wrong, but that doesn’t mean they can all be correct. If you’ve ever used both an Android and an iPhone, you know that they have completely different interfaces when it comes to setting an alarm.
When designing an app, if we just need a basic alarm feature, we could select the component from whatever library we are using. But what if we already chose a library that doesn’t have the alarm feature we want, or more importantly, doesn’t allow us to build additional functionality into it?
Can we just use both libraries? Yes.
But we shouldn’t. With every different library we use, we start to inherit additional rules and styles. And they will compete with each other.
Why Designers “Can’t Just Do That”
We actually can, but we don’t want to.
As I said before, with every feature, every page, and every interaction, we are building a set of rules and expectations that we want the user to absorb. But we also know that every variation, every exception, and every time users question something about the UI, it represents another opportunity to lose their trust.
It could be something as large as having two different components to handle setting an alarm. But it could also be something as small as why one multi-select tool has round pills, and another one has square pills. While both versions work exactly the same, they look different. And it’s in that split-second of uncertainty that we can start to lose the trust of our users.
The Missed Shot
Back to my golf game. I had a decision to make about my next shot, but I was confused about the distance. It felt longer than 150 yards. I was supposed to trust the bush. It had to be correct, but I second-guessed myself. In that time, I lost trust in what the course was telling me.
As designers, we have the power to remove that doubt.