In user experience, we usually talk about how people perceive and use tools so they can shape how these tools are designed and built.
Some of these ideas and recommendations may seem obvious, but they are important because when we are building a tool there are many goals, and sometimes conflicting ones.
For example, buttons need to be big enough to be comfortable to interact with. At the same time, screen space should be used wisely, to place an advertisement so we can generate revenue, or to be able to show part of the content on the next screen, which is also part of the user experience.
User experience requires a deliberate effort, and if we skip this step we can end up with awful user experience on the tools we build.
Today I will focus on three ways in which developers can contribute to a bad user experience, with real examples.
Case 1: The interface of the tool replicates the data structure in the database.
In a website with complex configurable products, there was the need to add price variations, to make discounts and adjusting prices for inflation easier.
As it should be able to handle discounts and price increments using percentages or fixed amounts, each was saved in the database using three fields:
- Value (integer) for the amount as a number
- Type (boolean) for either percentage or fixed
- Effect (boolean) for either adding or subtracting from the price
For example, for a 15% discount, we will have the following price variation:
{
value: 15
type: percentage
effect: subtract
}Which makes perfect sense.
However, if you asked someone to give you a price variation, he probably wouldn’t break it down like this. It is hard to understand this is equal to a 15% discount.
For an interface, it makes no sense.
Case 2: The interface reflects the logic of its code.
It seems intuitive that an interface should follow the same logic as its code, but it is not usually the right choice because a user doesn’t necessarily know how the tool works, only what they want to achieve.
I created a custom block showing the last post for the homepage of this blog. You can choose which post type or category you want to display the last post of.
In order to show a list of available options, when you choose if you will use post type or category, the second field is updated to reflect that choice.
I translated this poorly to an interface with two fields. The first is called query type, which is confusing for some people. And then the second changes its name according to the content it’s displaying: either post types or categories.
It would be easier to understand a single select field with all the available options displayed in groups.
Case 3: The interface focuses on tool functions and not user goals.
For example, we are going to add an option to use dark mode on our tool.
We could be too obvious and add a toggle that says “Activate dark mode: this activates the dark mode in this app”. Which is not very helpful.
We could be more informative by changing it to “Activate dark mode: this changes the app look to use light text over dark background colours”. This looks better but doesn’t accomplish much either.
Because we add an explanation for users who don’t know what a dark mode is, but if someone doesn’t know what a dark mode is, they will not care about it in the first place.
Let’s go a step further using “Activate dark mode: this changes the app look to save energy”. Now we are going somewhere because we are adding the context of what the user goal would be. And we can go all the way there by using this final version “Save energy: this changes the app look to a dark mode”.
Developers are usually advanced users and may find this conflicting. Why would adding a dark mode be labelled anything other than dark mode?
And the answer is simple: for most users of any tool, the context is their everyday life and not the tool itself. Even for advanced users, their context would be a larger system, like their job, their device, or the operating system, and not the tool on its own.
Meeting people where they are is always the best choice to create a satisfactory user experience.
Conclusion
All of these are examples of very basic user experience recommendations but from the perspective of a developer — or any member of a development team — for two reasons.
First, developers can easily identify these, so being involved in making decisions about the user experience will have an impact.
And second, being aware of how their role influences their point of view and how it needs to be addressed gives developers more tools to be strategic and have responsible discussions about it. Which provides great value to the team and to the developer’s career development.