5 UX basic principles for
software developers
With my background as a product designer (for physical & tangible products), I’m very keen on breaking the boundaries of User Experience design that focuses only on a digital application itself.
03-2020
Just like Donald Norman (inventor of the term “User Experience”, Cognitive Scientist & User Experience Architect) defines User Experience:
User experience encompasses all aspects of the end-user’s interaction with the company, its services, and its products.
In this article, I will shed a light on some basic UX principles for those without a UX design background. It does not matter which language or technology you use to develop, you can use these principles during your day to day decision making while working on the projects. By doing so, the chance of your projects being successful will be improved.
1. Client ≠ User
A common mistake made by software developers is that they think of the client as the user. As a result, it’s very easy to mix the business goals with the true user needs. Ultimately, this could degrade the success of the product/service.
Now, let’s take a look at the definitions of client and user:
Client
A client is the organisation/person who we are developing a product/service for. They provide the requirements that have to be met.
User
A user is the one that will directly interact with the product/service.
To clarify: Clients determine what business goals they want to achieve with the product/service, but only users can determine what would truly work for them. We need to trust the users to be the expert of their domains, they know what they want.
2. Users want to focus on their goals, not on the application
Of course, it is always great to build flashy animations, create absolutely marvelous user interfaces or apply state of the art techniques in the application. But do they add value to the application? And more importantly, are they valuable to the users? The simple truth is that users want to focus on achieving their goals, not on the application.
Take an instance where you are hanging a painting on the wall with a hammer and a nail. If both, the hammer and the nails are high quality, you can hang your painting in 5 seconds. But if your hammerhead is loose, the nail bends unexpectedly, then you become more aware of the tool itself and even frustrated with it.
The take-aways here are:
- The more transparent the tool, the better.
- Consider the application as a tool that can support the users’ working process to achieve their goals, not as an application full of different functions.
3. Just because it has become easier and faster to build, you do not have to build Rome in one day
Low-code application platforms like Mendix provide numerous possibilities for business thinkers to realise their vision at a fast pace.
However, as a software developer, you don’t have the knowledge that the clients have. They are familiar with their industry, markets, competitors, etc. You are also not the user who will use this service in their context.
There is still a lot of thinking to do. Just because we can work faster, speed should not be only the goal. Even though you now have the modern tools to build Rome in a day, a solid foundation and plan are always needed.
Do the holistic thinking first, then start building.
4. This works for Apple, Google, etc. but it may not work for everyone
In my first year as a UX designer, a senior developer who has actually worked for Apple, said to me: ‘It works for Apple, let’s do it too’.
In my day to day work, I hear this a lot, maybe you do too, or maybe you are the one thinking and saying these kinds of things as well. I wish you were right, but unfortunately, you are NOT.
At that time, my designer instinct kicked in and, I replied to my colleague:
Right, it works for Apple. But we are not making this application for the same user group nor supporting the same work flow. Apple’s solution is not the guaranteed working formula.
It is not rocket science, it is just a rational way of thinking. Without a good understanding of the user, the context of using and the problem you are trying to solve, simply copying the same solution will only make your service/product look like a new patch has been added. This patch may not fit with the rest of the service/product nor solve the real problem.
5. Start the UX way of thinking from the beginning of the project
Please stop thinking that a UX designer is there to make things look pretty. The following questions are what drive a UX designer at the start of a new project:
- what is the real problem
- who am I building this solution for
- where & when will it be used
- what could the solution be
- how to realise it
It is a fundamental step to consider these questions at the beginning of each project. The result of the analysis might influence the scope of the project, but it is more cost-effective to make these changes early in the process. As Roger Pressman mentioned in his book Software Engineering, A practitioner’s approach:
Correcting the same error during the coding phase would cost twice as much time to correct during the design phase, fifteen times as much in the system testing phase, and a shocking thirty times as much in the maintenance phase.
Conclusion
In case you don’t have a UX designer in the team, then at least stick to these 5 UX principles:
1. Client ≠ User
2. Users want to focus on their goals, not on the application
3. Just because it has become easier and faster to build, you do not have to build Rome in one day
4. This works for Google, Apple, etc, but it may not work for everyone
5. Start the UX way of thinking from the beginning of the project
This article was originally posted on Medium.
