Below you will find advice on improving the UX of your designs WITHOUT hours of user research sessions, paper prototyping playtime, or any other trendy UX buzzwords.
Who’s this article for?
- Developers. You created your own app, but every time someone downloads it, they struggle to use it. And you know if they’re telling you this, then it’s really bad.
- Graphic designers. Looking to make the transition into digital, but trying to learn UX by reading articles online is… a very painful way to die 😬
- PMs. Your job is already like 25% UX designer. Would be nice to level up those skills.
- And the hustlers. Anyone working on digital side projects nights/weekends. This one’s for you too 🍻
If you’re already a UX designer, this is probably not for you.
The focus of the article is entirely on the single most lacking skill in aspiring UX designers (or UX-adjacent folks who find themselves designing screens).
It can be called “speaking interface”.
Very often when clients hand over the initial wireframes (or the living, breathing, in-browser MVP) there are completely obvious UX mistakes all over them. And they’re not things you need hours of research and A/B testing to discover, more like dead simple mistakes.
For lack of a better example:
You don’t need to be a genius to understand that if you can only select ONE thing from a list, you need RADIO BUTTONS, not checkboxes. To understand that, you just need to be able to speak interface.
Interface fluency is something anyone can achieve.
You just need the presence of mind to (A) pause every single time you’re confused or frustrated by some app, (B) verbalize what about the interface makes you confused/frustrated/etc., and then (C) figure out how you could avoid that in your own designs.
Rinse and repeat that non-stop and you’ll be a pro in no time.
The four little rules below will help eliminate these pain points in your own designs. They’re the heuristics that are a level or two deeper than “use radio buttons if the user can only select one thing”. But, if you can remember to obey the things in this checklist, you’ll be that much closer to creating designs that your users can use easily right off the bat, freeing up your time for other, more important things.
(That’s when the other UX designers can lecture you on the newest academic user research methodologies!)
1. Obey the Law of Locality
Put interface elements where they affect change.
All else being equal, you should put the elements in your interface near where they affect change. This is because, when a user wants to make a change to the system, they will unwittingly glance at where that change will happen.
So, let’s say you have a list of things. Where do you put the “ADD A NEW THING” button?
Q: Well, where does the change happen?
A: At the end of the list.
Great, put the button at the end of the list.
WAIT. You’d think this would be pretty simple. But there’s a temptation.
The temptation is to just put it where we have space for it.
For instance, if you have a menu, maybe you’d think “We have a menu! Why not just put it in the menu!?” 
The answer is, of course, because users won’t look for it there.
(And the ultimate answer is that having a place where “we just put things” will ultimately render your app an unusable mess that people will abandon the first chance they see a half-viable alternative)
Unfortunately, this behavior is quite common. Have you ever noted this interface?
Your users want you to follow the Law of Locality.
So, now that we know it, let’s use it.
Bam.
But maybe you’re a born UX designer and you always visualize what happens when there’s 1000 items instead of 5 and you realize: there’s still an issue here. If the user creates a TON of playlists, this button will disappear hundreds of pixels offscreen!
So maybe you could anchor the button near the bottom of the list, but have it always be visible, no matter how many hundreds of playlists the user has created. 
2. ABD: Anything but Dropdowns
Any time you feel tempted to use a dropdown, ask yourself if one of these 12 controls is better instead.
One non-obvious lesson of UX design is that dropdowns are pretty much the worst control.
Welcome to hell!
They’re not always bad, but you’re working against the following:
- Dropdowns take too many clicks/taps. One to open, a few more to scroll around to the right option (on mobile), another to select the right option, and (on mobile) another to close. (Compare to the single click use-cases of many of the options listed below)
- Dropdowns don’t show you the options! You have to click into them to see the possible values, and on mobile, you can often only see a couple at a time.
- Long dropdowns are ridiculous to navigate. A country dropdown for an app used worldwide could have 195+ countries. At some point, almost any other method of asking a user their country would be quicker than having them scroll through a dropdown.
This is pretty straightforward, so let’s just cover some examples for the various major cases of dropdown replacement.
If you’re choosing between 2 options…
We already have some fantastic options for allowing users to choose 1 of 2 things, all of which (A) show the options right away and (B) require fewer taps/clicks.
For questions to which there is no “default” answer, and either might be picked with roughly equal frequency, try a segmented button. 
If there is a “default state” that corresponds to “Off”, try a checkbox. A checkbox is also good for settings that don’t affect change until the user presses Save or Submit.
Similar to the checkbox is the switch, which is good for changes that should apply immediately.
Checkboxes and switches only make sense when there are two options. However, the following controls make sense for 2 to roughly 5 options, so you might try some of the following instead.
If you’re choosing between 2–5 options…
We covered segmented buttons above (and they apply here too) but it’s worth mentioning that when there are more options, vertical segmented buttons allow even more flexibility of answer length.
Radio buttons are similar, but particularly useful if you need to display a couple sub-elements for each choice.
For detailed displays of just a few choices, cards are where it’s at.
A good trick is displaying visual options literally. 
Tesla likes it too, apparently.
If you’re choosing between many options…
When there are enough options that scrolling through them is annoying, consider a typeahead control. It’s like a search bar that shows top matching results as you type.
If you’re choosing a date…
Picking a date from dropdowns is the worst. If you ever do this 👇, then you’ve failed as a UX designer.
But what do you use instead? Well, it depends. First question: what type of date are you picking?
For dates in the near future, you want to make it DEAD SIMPLE to pick dates in the most common range (e.g. for scheduling an appointment, it might be the next, say, 14 days). It’s perfectly OK if picking dates outside of that range is a little tougher.
A calendar control fits the bill rather well for near-future dates. If you know the date to-be-picked is most likely in the next 2–4 weeks, you’re golden.
Date text inputs are probably the best option for high-variability dates, where (A) there’s no reason to favor any date over another, meaning (B) all options will be equally difficult to select.
Remember, input[type=date] is your friend… on desktop, at least
If you’re choosing a number…
Numbers come in all kinds of flavors, but you’re most likely to be tempted to use dropdowns when you’re dealing with counts – e.g. the number of tickets, the number of people, the number of rooms, etc.
How often do you need 1 ticket? Plenty.
How often do you need 10 tickets? Not so much.
How often do you need 10,000 tickets? Is this some kind of cruel joke? 
3. Pass the Squint Test
If you squint your eyes, the Most Important Thing should catch your eye first – and the least important elements should catch your eye last.
Pop quiz: what does a user need to do to use this page?
It’s blurred out so you have to go by gut instinct, but it’s a data entry form, to give you a hint
The best guess would be two things:
- Check any applicable checkboxes (??) in the yellow area
- Press the blue “Submit” button
Did you guess the same?
Wrong and wrong. 
- The “checkboxes” are actually very small numerical text inputs. (If you already read Anything But Dropdowns, you know small numbers should be steppers)
- The Most Important Thing (“Find Options” – which is a very confusing way to say “Submit”, by the way) is gray and unnoticeable. A much less important thing (“Help”) is immediately next to it, but bigger and more visible.
The Squint Test says the Most Important Thing must be the most visible thing. What’s the MIT? The ticket textbox (or stepper 😉) controls and “Submit” button.
4. Teach by example
If you’re introducing users to new concepts, a few examples can be worth 1000 words (which your users wouldn’t read, anyways).
We have a weird tendency to try and explain things in words when examples would be much clearer.
Consider Teeming.ai. Headlines on the page read:
- “Teeming takes the isolation out of remote work”
- “Teeming helps with remote team building” as well as “learning, problem solving, having fun, and motivating each other”
- “Teeming and video for synchronous [communication]”
- “Works with all your favorite video platforms”
But here’s my question for you. What does Teeming actually do?
It’s tough to tell. It has probably something to do with… good vibes for remote workers?
This page obviously needs examples of what it does, how it does it and how it’s useful.
But examples aren’t just for landing pages. Here’s what you see when you first sign into project management tool Basecamp.
Rather than seeing a totally blank page, you see two obviously pre-fabricated example projects that teach you, by example, how the whole app works (and also gives you an idea of what the tool will look and feel like when you’ve been using it a while).
Seriously, you can browse through fake chat logs by fake users discussing fake file uploads and fake to-do items. 
If your app allows users to create something, a showcase is a great way to teach by example just what’s possible.
So: if your app does something new and unfamiliar – or relies on new and unfamiliar concepts – you should get acquainted with the ways of teaching by example.
The moment you realize that you’re introducing something users won’t have seen before, you should start thinking: how can I give an example to make this clearer?
Conclusion
Before doing any user testing or studies, start with a good foundation and don’t make the obvious mistakes. These 4 rules will help you with that:
1. Obey the Law of Locality
2. ABD: Anything but Dropdowns
3. Pass the Squint Test
4. Teach by example
Once you’ve followed these rules, it’s time to dive deeper and start observing which specific things work or don’t work for you. But first, don’t make the obvious mistakes.
4 Rules for Intuitive UX
PS. For more on date pickers, see Date picker design best practices, and when you’re ready to start user testing: Qualitative research: 5 ways to find out what your customers (truly) want.
