Off-The-Beaten-Path Mindset: Using User Interactions to discover potential pitfalls in software development
Using software is like walking on a path. Every user interaction is another step forward. Rarely, there is only one direction you can go.
Sometimes missteps happen. Hopefully, these won’t cause too much trouble. In software development it is our responsibility to reduce the effect of missteps or prevent them from happening in the first place.
In software development we are creating this path. Unfortunately, we are often so focused on building our magnificent boulevard (our “happy path”) that we forget about looking in the other directions as well.
In this article I want to motivate you to also look at the “dark alleys” of our software and make them a better place or prevent people from going there.
Obvious and not so obvious interactions
Having users walking on our (metaphorical) boulevard is what we want. Ideally, a path of interactions we want the user to make is clearly laid out in front of him. These interactions are usually quite obvious. Let’s look at an example:
Here we have a simple search field and two buttons: One to clear the search term and one to trigger the search. With this elements we give the user three options to interact with the application:
- Enter text to the text field
- Press the search button to trigger the search
- Press the clear button to remove the text from the search field
Especially on smartphones there are more – not so obvious – possibilities of user interaction. Examples for these interactions are:
- A search (action) button on the virtual keyboard.
- Back navigation button / gesture
- Screen rotation
Whereas the search button on the keyboard might be something like a second lane of our boulevard, back navigation and screen rotation are steps onto a different path.
Walking the happy path: A matter of order
In our example, we expect the user to perform the three mentioned interactions in exactly that order. It does not make sense to press the search or clear button before entering a text, right?
But users don’t necessarily behave all logical all the time. What if the user presses the search button without a text being present? What happens if you click on the clear button immediately after pressing the search button? What if the user navigates back while search is still being performed?
I think questions like these should be considered when discussing a new feature. Many of the questions will have simple answers. You might even have multiple options. Especially when this is the case it makes sense to discuss and make a decision to maintain consistency within the application.
Roadblocks: Reducing complexity
In our search example we have multiple options to handle a search request being triggered with an empty search field: One possibility would be to show an error message to the user requesting to put in a search term before triggering the search.
Another way would be to disable the search button when no search term is typed into the text field. In other words, we are reducing the number of available user interactions and thus reduce the complexity of our street network. Or in our analogy: we are putting roadblocks in front of some of the dark alleys to prevent users from accessing them.
Not all user interactions can be prevented, but you should evaluate those that can be.
Often we are blinded by how a new feature is supposed to work and we forget about alternative paths that are also available. I think it can make a positive impact to software development to develop an ‘off-the-beaten-path’ mindset by keeping these points in mind:
- Discover possible user interactions
- Evaluate if some should be disabled
- Discuss possible alternative paths and their effect
- Decide how to handle alternative paths
- Handle alternative paths consistently
What about you?
Did you experience situations where you discovered different alternate paths while developing a piece of software? Did it cause bugs? How did you handle these situations?