Ever encountered poorly written code? How about a confusing UI in a program or web page? What about accidentally pulling a "Push" door? Each of these cases is a form of bad design through poor User Experience (UX) in their different mediums for their different users.

As a developer, graphic designer, systems engineer, back end, front end developer, hardware developer, managers etc, we all play a part in the overall experience in whatever we are making. For example:

• Working with spaghetti code has a poor UX for the developer that needs to deal with it.
• Code or servers that performs unnecessarily slow (think waiting minutes for a web page to load) has poor UX, regardless of how nice your loading screen is.
• A website without appropriate accessibility considerations has a poor UX for those that rely on these aspects (eg. alt/aria attributes).
• Confusing/ambiguous language regarding a form or dialog, increasing the chances that the wrong option is selected. Even if the right option is selected, better language can improve a poor UX.

I mentioned earlier about accidentally pulling a "Push" door, this is actually quite a common faux pas and comes from subtle design aspects of a door. Having a handle instinctively implies "Pulling" so unless a door can open both directions, only one side should have a handle. This issue with doors, whether you "Push" or "Pull", is called Norman Doors, named after Donald Norman. He created a popular book The Design of Everyday Things which goes into detail about "affordance" and user-centered design.

Affordance in Design

Affordance can be understood as "the action that is most implicit". Going with the door example earlier, a handle affords pulling while a plate affords pushing.

The idea through implicitly known actions is that you don't need to teach users how to interact/use/understand everything. The less you need to teach a user, the better the experience.

It is important to note that not every action is implicit to everyone - users come from different backgrounds and have different experiences. You don't teach advanced programming topics to absolute beginner programmers. Similarly, you don't design a command line interface for a non-technical user. You need to design for the consuming user.

User-centered Design

Thinking about the user-first in a design process, you would be asking questions like:

• Who are the users of the feature/change/document etc?
• What are the user's goals?
• What is their experience level with this type of feature/change/document?
• What functions does the feature/change/document need to perform?
• What is the environment/context is the user in?

Let's look at an example:

• An employee and manager (the Users) have access to an Intranet which will have a new "Time sheet" system added.
• An employee would use it to put in time sheets (Employee Goal). A manager uses it to manage resources (Manager Goal).
• All employees know how to use such a system (Employee Experience Level) but not all managers do (Manager Experience Level).
• A manager might need to print a Work-In-Progress report (Manager Function). An employee needs to enter time for specific clients (Employee Function).
• Employees are often off-site (Employee Environment/Context).

When designing interfaces etc, breaking down a user like this is extremely helpful for identifying non-obvious requirements.

Developers are users too!

For developers, you actually have an additional user that isn't likely documented - your developer colleagues! Writing something only a handful of your colleagues would understand due to its complexity is pretty bad. Also writing something in a completely different platform than anyone has worked on before isn't going to win you any friends when something breaks at 3am and they need to debug it.

Everyday ways to improve UX

Depending on where you work or what you work on, you may or may not be "officially" involved with the UX of what you are building. I'm here to tell you that doesn't matter!

It starts as simply as asking questions and looking at requirements from a different perspective. If you're a DB admin and know a slow query can be improved, tell your backend developers. If you are a backend developer that knows just learnt about GraphQL, tell your frontend developers (if they didn't already know). If your frontend developers see that fields 3, 5 and 7 in a particular form could be misinterpreted, talk to your boss about changing that. If you're a Senior Developer, helping the Junior Developers on your team write easier to read code.

Each little bit of UX improvement like faster queries, cleaner code, more flexible APIs and less ambiguous fields can help developers and end-users alike.

Don't think because your job title says XYZ that you can't help in other ways! All our work combined forms the complete User Experience.

Thanks for reading!

This post was partially inspired by the Vox/99% Invisible video "Its not you. Bad doors are everywhere." which talks about bad design in real life. Check out that video for more details about user-centered design.