If what we are testing is a User Interface, then the most important consideration is the User. If that is true, then we must start with an understanding of the user and why she is using this interface. This seems so obvious, but there is much more to it than the obvious.
All users are not the same. Here are some variations:
- There is the developer’s conception of the user. If his conception is not correct then even if he does his job right, it might not work for the user for many reasons.
- A first time user may not even know what the outcome should be. The UI should lead a first time user to discover the ‘first time’ things that should be done. A simple example of this is the button or link on an application labeled ‘Login‘ or ‘Create an account.’ She may not realize that she does not have an account and just try ‘Login’ first (we have all done this). So the Login screen must make it clear that if they don’t have a username that works, they need help figuring out if they don’t have an account or that they have simply forgotten the password. If this is confusing the UI has already failed.
- A first time user may not understand the first steps in the journey, so the UI should have obvious landmarks like tabs to indicate the way. Naturally most users would start exploring the tabs from left to right assuming that the leftmost tab is the starting point. There are many other ways to guide the user.
- On the other hand an experienced user needs navigational clues to lead them to the appropriate UI for their current intended use. He should not have to read or navigate very far to find the right path to the appropriate page.
- A confused user may have tried a number of things before finding the path, but those wanderings may have unexpected consequences that now block success. This user may have a very negative experience and abandon the attempt.
- An experienced user may follow his usual path for a repeat of some previous experience. However, sometimes changes in the UI might add or remove steps or present them differently. If the navigation or on screen guidance has changed to reflect that change, then this user will be confused.
- Terms and labels that are unfamiliar to a user. The use of small decorations that have tooltips or a small dialog or lead to an explanatory page, will allow the user to an understanding that could avoid errors or unexpected outcomes. A tester should try those and see if they make sense.
- There are very many issues like these that are variations on a user’s experience that were not anticipated by an engineer who “knows what the user should do”. The developer naturally asks “why would they do that?”. Users do silly things sometimes.
- You may have other ideas for this list based on your user experiences. If so drop a comment below.
As I wrote above “All users are not the same. ” One of the primary jobs of a tester is to learn about the user and anticipate these differences.
For every part of the UI there is not one unified experience. Your job is to use your knowledge of the various users to guide you to a variety of variations for each use case. And sometimes that means doing silly things.
Next Page -> Eat your own dog food
As for me, this is a significant article. It helped me as a tester, focusing on real-life scenarios to give attention to unexpected behaviors. After development, we have a testing process, which might be required, because the input result might not necessarily be the same.
Here are some other possible ways:
– The user may reuse the same username with different passwords. It might be because he wanted to get two accounts with the same username. On the other hand, the end-user might insert the right username, but they leave the password field empty and try to log in.
– In this list, I would add the point that wrong details may be provided, such as an email that doesn’t exist or a wrong phone number. Otherwise, he may try typing spring values when required for a phone number, which might not be part of the developer’s expectations. If the input has numbered requirements, simple feedback might help fix those errors.
– Some other users may use digits for both fields, which might confuse the data tracking when it comes to the backend, and identifying the user might seem to be a challenge.
In your first paragraph you mentioned testing after development.
That is a common way developers think, but in reality the testing should be started very early in development. We will learn about Test-driven development later, but for reference see:
https://en.wikipedia.org/wiki/Test-driven_development
I really like the distinction between the novice user, who needs guidance, and the experienced user, who seeks efficiency. The tester must juggle these two profiles to ensure the interface is neither too complex for one nor too verbose for the other. This is where testing becomes a true exercise in empathy.
The article clearly shows that UI testing shouldn’t be an afterthought but should influence the design itself. If we start by understanding the user’s potential obstacles, we build naturally more intuitive interfaces. This aligns with the idea that testing begins long before the first line of code.
The success of an interface depends on the simultaneous satisfaction of two opposing profiles:
the novice and the expert user. The tester’s crucial role is to anticipate these diverging needs long before the actual testing phase begins.
They must deliberately adopt a multidimensional perspective, ensuring that every interaction is calculated to be both educational for the beginner and efficient for the expert. Ultimately, the tester does not just judge product compliance; they architect the mental ergonomics through proactive anticipation
Excellent! “multidimensional perspective” is a great way of visualizing what is needed.
Now, you and your team need to connect that insight to visible tangible artifacts in the project.
Some file or picture that is the common starting point for various paths.
Keep going and it should become obvious to you.
When you find it, your mind will naturally connect that artifact with this abstract perspective.
When you or someone else makes the connection, please post a comment here with that insight so that others can learn from you.
I understood that in interface testing, the user is the priority. We must check if the application is easy to use for all types of users (beginners or experienced ones), without confusion or blocking issues. The goal is to ensure that everyone can use the interface correctly and without difficulty.
Very interesting !
All those little tooltips, question marks, pop-pups i can notice while surfing on internet, are now making sense to me from this perspective.
A great reminder that testing a UI isn’t just about functionality but it’s about understanding real users and their different behaviors. What stood out to me is how easily assumptions can fail, especially when users don’t follow the expected path. Good testing means thinking like different users, even the first-time ones to ensure the experience is clear and intuitive for everyone.
This article highlights how important it is to truly understand users when designing a UI. It’s not enough to assume how people will use an interface, because different users have different needs, behaviors, and levels of experience. Some may be using it for the first time and need clear guidance, while others expect fast and easy navigation. It also shows that users can get confused or make unexpected choices, so the interface should be designed to handle that smoothly. Overall, it made me realize that good UI design and testing should always focus on real user behavior, not just technical logic.
I am not building for myself, but for confused, impatient, distracted people who won’t read instructions. This is so relevant as I continue to learn more about testing. My worldview as a developer is different from users’; they only see buttons, labels, or outcomes, therefore, it is my responsibility to guide and rescue them. One big insight from this reading is that testing is all about simulating different types of humans, not just clicking buttons, checking functionality. I will aim to know if anyone uses my work without confusion. This article is very inspiring.
I’ll admit, I used to think like a developer. I thought testing was just about success vs. failure messages. This really opened my eyes to the fact that users aren’t predictable. They skip steps, get confused, and take ‘silly’ paths we don’t expect. As a tester, I’m realizing I need to be the person who predicts those mistakes before they happen.
Focusing on the user’s perspective is a vital reminder that technical correctness doesn’t always equal a successful product. I really liked the point about the “developer’s conception” of the user; it’s so easy to build based on how we think someone should navigate an app, rather than how they actually do.
The distinction between a first-time user and an experienced one is particularly sharp. A first-timer needs obvious landmarks and guidance to avoid “abandoning the attempt,” while an experienced user needs efficiency and clear indicators when a workflow has changed. If we don’t account for both, we risk building something that is either too hand-holdy for experts or too cryptic for newcomers, neither of which is ideal.
I also appreciate the mention of tooltips and clear labeling for unfamiliar terms. These small touches are often an afterthought in development, but they act as a safety net that prevents a confused user from making errors. Bringing this mindset into our testing phase will definitely help us catch those “unexpected consequences” that arise when a user takes a non-linear path through the interface.
I found it interesting that users don’t all think or behave the same way. It shows that testing an interface is not just about checking if it works, but also thinking about different user types and how they might react.