Over the years, I’ve had a lot of developers ask me questions about what I do. One question I’ve heard quite a lot is: “We already know what we need, and we’ve done this kind of thing before, so why not just start building it?”.
Even though UX is not the primary job of a developer, any software, even backend focused, has the goal of interfacing with users at some point. And as soon as you start to look at the world through that lens, there’s a lot to consider.
Just coming up with an interface, even one that has been done before, can run into lots of issues. The right design for the wrong application will waste time and money, and frustrate users. When you have a hammer, everything looks like a nail, even if the user has screws. And even if you really do have to hit a nail, why force users to pick up a sledgehammer for tiny nails?
It’s critical to understand why certain designs are chosen over others, what kinds of users and use cases you’re designing for, and what the fastest, most productive workflow would be. All of this needs to be thoroughly thought through well before touching a line of code.
I would hope every developer I work with would have a grasp on certain principles. When the user experience is considered upfront and developers are working in step with the UX designer, a project can go incredibly well from start to finish. Anyone who is designing experiences needs to consider the number one principle of UX.
Principle #1: Software is about the user first
I’ve interviewed a lot of UX designers, and one thing surprises me more than anything else. Many people who claim to do “UX design” are focused more on the look and feel of something than the far more critical focus: who is using this in the first place.
From games to paying bills, all software has the purpose of getting used by real people. The first and most important thing is to figure out who the users are, how quickly we can talk to them, and how quickly we can show them our design ideas. This may seem obvious, but I’ve seen this get ignored more times than I can count.
I’ve come across apps and real-world designs that constantly make me shake my head. Did anyone ever show this to another real person? Did anyone ever ask people to do basic tasks with it? Because the design stinks.
Some examples will help, and for that, let’s start by turning to the real world.
Light switches.
I’ve seen some wretched light switch designs. You’d think these have been around forever and what’s left to design. Looking at old designs of light switches makes it obvious that they’ve come a long way. I can’t tell from this picture which button does what. I’m guessing the top and bottom are on/off, and left/right are two different groups of lights. But who knows?
It’s not just the design of the panel that’s important, the location of light switches is just as critical. It should be a few feet tall and next to the door you came through. Anything else is poor design. I remember showing up at a cabin with my wife and two kids in the dark and stumbling around, feeling walls, wondering where the light switch was.
The cabin did come with electricity, didn’t it? I thought for a moment. Yes, it did. I just couldn’t find the light switch. I went back to the wall by the door and glided my hand up and down. No, it wasn’t just raised or lowered to the wrong height on the correct wall.
I bumped my shin going to the next wall over. No light switch there. Finally, I dropped my luggage, pulled out my phone, and turned on the flashlight feature. There! Across the room was a light switch panel with two switches. One was for the cabin, one for the bathroom.
Now, maybe they had a constraint when they built it. We deal with those all the time in development. Perhaps they could only have electricity on that one wall. But if they’d done a single user test, they’d have felt compassion for the poor folks bumping their shins in the dark and sent a wire along the wall to the proper spot. Not hard. Maybe a bit ugly. And priceless.
Another light switch story. I bought a new ceiling fan light at a hardware store based purely on how it looked compared to the other models. I didn’t bother looking at the extra “features.” They weren’t important to me. It turns out they were far more important than I could have imagined.
First, they offered a remote to control the fan and light. Initially, I thought, whatever, who cares. But after installing it I wondered, seriously, who wants another remote floating around? That remote has never once left the outlet holder that it came with, except for my kids to tease me.
Second, the control design is painful. The fan speeds are controlled with single button clicks. Not so bad. But the light is one central button with multiple purposes. A hard click will turn the whole light on/off. Holding the button will slowly dim the light, then bring it back up to the top. Where’s the bottom? Where's the top? Who knows. You have to guess every time. There’s no simple, obvious slider. I can’t tell how many times I’ve tried to brighten it to the top — the most common action — and went too far and needed to recycle the pattern for another ten seconds completely. Egads!
I could come up with a wide range of designs that immediately make more sense. A quick search online found this one that I like. It’s simple. It’s obvious. Physical buttons that you can touch in the dark and know immediately where it’s at.
I was sharing this at a community workshop I was doing on UX design, and a woman in the audience raised her hand. She had that very same fan system and remote and, guess what, — she didn’t even know the fading option existed!
The point of the story is this: don’t ship any design without testing it on real users first. Internal testers are great. Instinct is good. But real users with no previous connection are priceless. Until you watch those real users foible over faulty designs, it’s hard to truly appreciate just how much better something could be.
I mention real-world design examples first because all software design comes from real-world designs and experiences. We’ve migrated to flat designs rather than skeuomorphic, which is basically a fancy way of saying the trend used to make things look like they’re real-world so we’d grok it, and now that we’ve all gotten used to the software, they’ve taken the life out of things and made them flat.
Buttons used to look like buttons. Now they’re flat.
Icons used to be representative of the item it was modeled after in the real world. No more.
Regardless, that’s just a trend and it’ll change again most certainly. What’s most important is to remember, designs have their root in real users and real experiences, so that’s why we start there.
Let us take a look at one last example of bad physical design before we get into software. The design of the individual items in and of themselves are perfectly fine, but putting them together also needs attention. This design shows the principle. A single user test would have shown the error of this placement of these designs.
This is hilarious. This also happens all the time in software. I see designs that are disjointed so often, I’ve come to expect it. We create user flows so we know a user goes from A to B to C to D. Why make them bounce back to A every time to go to the next step? It’s completely unnecessary and also more common than you think.
In its simplest form, UX can be broken down into four main steps. I have a seven-step process that’s a lot more detailed and has all of this broken down further, but at its core, user experience design has some simple principles that even a child can.
Four Steps To Good Design
1. What problem are you trying to solve?
It’s common to gloss over this, especially if you start with a really cool idea or even if you have a business plan with all the money worked out. The problem statement nails down a specific user need that can’t be easily solved.
2. Who are you solving the problem for?
This is what I’ve been focused on so far. Since apps are about people, we want to know specifically which kinds of people are the ones we’re designing for. It won’t be “all people”. That’s just not realistic. Ideally, we create a persona, or a fake person representative of the type of user we’re building for.
3. Come up with some cool & crazy designs!
This is the fun stage, where ideation and designing comes in. In a large-scale software setting, this involves a lot of people, whiteboards, sticky notes, paper prototypes, and the like.
4. Test out the designs on real people.
You’ll never know for sure if you’re building the right thing unless the designs are tested out on the types of users you’re targeting. It’s a critical step in the process and, sadly, sometimes overlooked.
A Fictional App Example
Let’s consider an app to get specific. It starts on a Saturday morning, hanging around with my kiddos and wondering what to do with some old bananas. We suddenly realize: hey, maybe this is the next best app! What kinds of apps could we make for bananas?
This is a fun stage of divergence, and we jump right into our first idea. How to peel a banana.
We get straight to work! Since it’s an app people would use in the kitchen, we put it on an iPad. Here’s our first stab at it.
First step, let’s show a handy picture for how to hold the banana properly.
Second step, let’s throw in some laughs and make it interesting by showing how gorillas do it.
Third step, well, we’re having fun with ideas and this was a great picture we found online, so let’s go for it.
There’s an obvious problem with this approach. And I kept the example crazy to make it obvious what it is. We skipped steps one and two, and jumped straight into step three: coming up with ideas.
If we’d done the work of asking what problem we’re solving and for whom, and done the work of finding some real people who match it, we’d quickly find the issue with our idea. Nobody needs an app that shows how to peel bananas. Of course, this is obvious to us but companies have wasted millions of dollars on ideas that they never tested out on real users at the onset of the project.
If you’re unsure of the kinds of people to find for testing, the best thing to do is consider real-world scenarios and who might find themselves in that situation. So, let’s take a step back and consider our first scenario.
It’s a Saturday morning, and a father of two kids wants some inspiration for what to do with old bananas. Is this a realistic scenario? Yes; we know it is, because we are dealing with it. But peeling the banana was the wrong direction.
We don’t want to just eat bananas raw, but what else can we do with them?
What we really want to know is what kind of food we can make with them.
The next step is to do some research. If I look online, do I see other people who’ve run into this problem? Of course! There are plenty of banana recipes out there and also books entirely dedicated to banana recipes. There is absolutely a market for this, although it may be small and niche. But that’s ok. As long as we’re designing for real people with a real need, we can jump in and start coming up with some design ideas.
So, we start with our landing page. It’ll need to be renamed.
But wait. Again, we’re jumping in a little fast. Before we do designing, we need to actually go out and talk to some real people. We make a lot of assumptions all the time when doing designs and our goal is to move all of those assumptions to less and less risky ones. This means talking to real people and knowing more and more about those assumptions.
A quick conversation with the father and kids, and it’s clear that they’re starting with old bananas. We could add that as one of the landing page options.
When they click on the old bananas, let’s show a screen that highlights the old bananas.
Before we go any further, we need to talk to users again. A quick show-and-tell instantly reveals the shocking truth: they do have old bananas but nobody wants to see pictures of old bananas.
If not old bananas, what do they want to see? They may not know, and that’s ok. We can do some ideation and come up with ideas. We have to be careful here because sometimes they say they want something that they really don’t need. It’s not our job to build what they ask for, but what they need. In the world of design, we have a saying: UX is about being doctors, not waiters.
This means we serve what a person really needs, not what they think they want. It’s important to keep in mind when asking users what they want, that we don’t get dragged into that common mistake.
Some more ideation and testing shows that they really want nice looking photos of banana recipes. So, we redesign the app to match that. We find a few more filters that cover more areas of interest than where we started. And voila! We have our first stab at a real app design.
Let’s take a step back and look at the competition.
I like the Yummly app for recipes, so let’s see what they do for design.
The landing page is far more appealing than what we came up with. Why not jump right in and show banana recipes right away? I like that. I also like how they have more screen real estate to display appealing pictures, rather than the filters, which are all on a top bar.
Clicking the filter hones us into what we want. I like that it also offers suggestions. That’s a nice touch.
After putting “bananas” into the filter, it’s giving me some guided direction. That’s super helpful. I don’t know if that tests well with users: is it annoying, as popups and tours often are, or is it welcome and helpful. That would be something worth user testing.
I add the quick and easy filter and see some great results. True, they didn’t have a filter for old bananas, but overall, this is a beautiful design and fast to find things of interest.
Let’s go back and compare our design to Yummly’s.
Not bad. We have areas for improvement, but we got on the right track as soon as we started talking to real users, and going through the steps properly.
We figure out what problem we’re solving.
We talk to real users — those who have this problem.
We come up with design ideas.
We test our ideas out on real people.
I wouldn’t expect developers to run these kinds of sessions, or even attend the majority of them, but I’ve always found that they should be included in this process. At every step, a developer’s sense of feasibility and connection with the real user problem will help influence the app in a better direction.
Sometimes developers are the ones who come up with the best designs, and that’s great. The job of the UX designer is not to come up with the best design, but to know it when they see it. And having a connection to real users throughout the process is the best way to make sure whatever design is released is going to be a great success.
Of all the principles of UX I hope developers know, this is the most important. Just because something looks good, or the development flow makes sense, does not mean it is a good design. Good design is about users accomplishing tasks and solving problems. And the only way to validate a design is to test it with real users.
