Industry Insights from Our Experts

Designing for Your End Users, Not Yourself

Filed under Developing Teams, Usability

As developers, we take a great deal of pride in our work. Most of it is entirely unnoticed by the people that use what we have spent hours building and designing: the end users. That really cool, almost poetic, bit of code we wrote? They don’t see it. They click a button, and the thing works. That’s what they care about. As a developer, that’s what you care about. It needs to just work.

Recently I was sitting in a meeting where a business analyst was sharing with the dev team the business requirements for the next big feature of the software we are working on. At one point, there was a question about the order in which three fields should be presented and their values filled in. As developers, we had a certain opinion and raised this thought to the BA. She saw where we were coming from, but then made a statement that rang out in my head.

This is how the users think.

As the discussion went on, I thought about that expression in greater detail. Yes, we as developers had an opinion on usability, but our end users think of things in a different order than we do. The end result is the same, but the path to get there is different for all of us.

This reminded me of a friend of mine who told me about how, when she was in high school, her math teacher would tell them that he wanted the class to show their work, and not just provide the answer. So she showed her work. The thing is, her process, while arriving at the correct answer, wasn’t the way the teacher did it, and wasn’t the way the textbook showed it could be solved. So, the teacher would tell her that her work was incorrect even though the final answer was correct. Why? It boiled down to the statement above.

This is how the math teacher and the math textbook authors think.

Personally, I think it was an injustice, but in school, “there’s the teacher’s way, or there’s the hallway”.

The problem is that when we don’t think of things in the way that our end users see things, and don’t put ourselves in their shoes, then we wind up building for ourselves, and not for the people that asked us to build something in the first place. And this leads to confusion and awkwardness for the end user to interact with our system we built. Even though it may fill the business need, it fails completely in the eyes of the end user.

A non-programming case study

Let’s put down the code for a moment and step out into the real world for a moment. (Man it is bright out here isn’t it??)

My daily commute to work takes me through a certain LRT  (light rail transit for non-Edmontonians) station. When I get off the train at this station, I step onto the platform, and go through a set of doors to be presented with an escalator going up, and a set of stairs that would be the way down. Here in Canada, we drive on the right side of the road. We tend to even walk on the right side of a sidewalk as pedestrians. When faced with a set of double doors, we tend to favour the ones on the right side because generally traffic going somewhere is to the right of traffic that is coming from that somewhere.

So imagine how much confusion, awkwardness, and bumping into people happens when, stepping through those doors, the escalator to go up is on the left, and the stairs coming down are on the right. Trust me, it isn’t pretty.

Getting to the top of the escalator, you are now faces with two sets of double doors. And these doors lead into a pedway that goes over the road below. However, now it becomes quite clear that these doors were designed that people crossing from the platform side to the opposite side, are meant to go down the right side of the hallway. So now passengers have to change lanes again.

Getting to the opposite end of the hallway, another two pairs of double doors greet you to reiterate this idea of right and left for leaving the hallway vs coming in respectively. Going through those doors, we are now back to stairs to go down to ground level on the left, escalator coming up on the right. Which means that people coming up the escalator have to cross over traffic that is trying to get down, and vice versa. Again, trust me, this isn’t pretty to watch; or be a part of.

This train station wasn’t designed with enough thought about the pedestrians going through it. As such, traffic through the corridors of this station gets congested easily and it isn’t an enjoyable experience to get through there. Granted, I do not get run over by cars travelling down the road, and I am also in no danger of getting hit by an oncoming train! So in that respect, the station has solved the business need. But it didn’t cater to the need of the people using it or how they think to make it intuitive or enjoyable.

What does this have to do with designing for end users?

When designing a user interface, we as developers have a responsibility to cater to our customers’ needs and desires since they are ultimately the ones paying the bill. Granted, we may warn them about certain pitfalls or things that may not be feasible. (i.e. drawing a red line with blue ink anyone?)

But our design and layout choices need to focus on how our end users think and what they are accustomed to. When we drastically change things to what they aren’t used to, then chaos and confusion sets in.

Consider the radical change that was made between Windows 7 and Windows 8.x with the Start Menu to the Start Screen. For most people this was a very jarring experience and grew to be one of the biggest reasons you heard people say, “I hate Windows 8!” Beta testers begged and pleaded for this design to not happen, but their pleas went unheard, and well, you know the rest.

Usability is a tough nut to crack. There’s no doubt about it. While we can’t please everyone all the time, so long as we are designing with the majority in mind, we wind up providing an experience that is great for all involved.

After all, happy end users makes for happier developers.

Copyright 2017 by Quercus Solutions