Look at the “state” of your design
Any Scottish readers may read the title of this article as a degrading statement towards their designs. This may be the case — I’ll let you decide. What I am actually referring to is the different UI states that exist within your designs.
Often when we create designs we are blinded by the beauty in perfectly proportioned layouts presented on ideal screen sizes with adequate whitespace, an array of delightful images and the perfect amount of engaging content to consume. Switching back to reality, we often see that this is not the case. Granted the example below is a little out of date, but is a great example of a no-data state (we’ll just skip over the myriad of other issues with this screenshot).
As designers we are problem solvers by nature. We like to take an issue and through experimentation and iteration arrive at the most effective and delightful design. Oftentimes though we see the problem as creating or redesigning a particular UI or feature. Whilst this is part of the problem, we can go further and break this down more. For every element, screen, flow and interaction that you create, always consider “is this the only way”?
Why, why, why…
Before we begin problem solving, we should be utilising “the 5 why’s”. This way we develop a deeper understanding of the problem and the purpose that our designs can serve in this given situation. On understanding the problem, we need to begin breaking down the constituent parts exploring the edge-cases and anomalies for each.
Working in a design capacity across various sectors (IT, Big Data, Financial and Travel) for almost 10 years I have developed a rich understanding of interfaces and systems which are far removed from the first brochureware website that I created. Through working in various teams on various problems and products, I have learned to consider some of the following when approaching UI designs:
- Translations (string length, word order, special characters)
- Localisation (phrasing, puns, culturally-specific references, interpretations of colour, imagery, symbols)
- Information overload — navigating large volumes of data/content (structure, content architecture, taxonomies, search, sort and filter)
- No data (the opposite of above)
- Device disparity — appreciating that not everyone has the same handset or laptop as you and as such will have a very different experience with your product (network connections, colour profiles, hardware performance)
- Edge cases (users with unique needs, unforeseen usage of a feature)
- System dependencies — (3rd party tools, content creators, feeds, APIs)
Being mindful of these factors as you explore design concepts really opens up your thinking and causes you to see the product and the design from different angles which at first may seem unnatural but getting this right you can create truly delightful products which have taken into account all of these factors.
Taking an example further
Each of the points above could be an article in themselves, so let’s just take one and look at that as an example. In the case of data no-show, we first need to understand the “why’s” and then look at ways of addressing the problem. Is there work that can be done before the interface level that can fix the data-issue? Is it out-with our control? Understanding why there is no data in the first place may allow us to get to that root cause such that this state becomes a very rare case.
Is the data from a 3rd party provider? If party A fails to provide data can we fall back to party B? Can we retrieve cached data and serve that in the interim? The effort which you would go to in diving deeper and deeper would entire largely on the impact of this missing data in the first place. Will the disappearance of data in these contexts affect the core flows and use cases of your product? Is the display and interaction with this data intrinsically linked with revenue? Asking these sorts of questions should help you to prioritise the areas which you should focus on most.
Given the complexity of modern day products, it is highly likely that there will be failures along the way through issues arising from internal or external parts of the system. Knowing that this can (and will) happen, the best thing you can do is gather as much information as you can about the missing data and design for it. Is it a network issue? Is it an issue with the users query? Can we ascertain what the user is looking for and propose an alternative?
Asking these questions should help to define what messages and flows you will need to create, and most importantly will help you consider how to get your users out of this state — no one using your product is likely to be looking for this no-data state!
This article was inspired by Scott Hurff’s more in-depth look at the states of your UI. I’d recommend giving that a read too. In short though, the one thing which I done of the back of reading his post was to write on a bright orange post-it the following 5 bullets, with the heading “Remember your states”:
The not-so-subtle reminder which is stuck to the side of my monitor reminds me to consider at all times the impact of the different states, because you can guarantee that users will be seeing all of these states. The question is whether or not you have designed for them or not, or whether your users are blankly staring at blank screens waiting in anticipation of something happening. Just as a heads up — They won’t wait around long!
As a recurring theme to this article, the best thing to do is ask lots of questions, lots of the time.