Different system states in design
A user’s needs for a given product changes with time and space. Eg: A user’s needs for a given product in the morning at home may be different than in the afternoon at the office.
When designing UI, most of the time we are more interested in the effect rather than the cause. Eg: Cliona is a returning user for an e-commerce app The cause may be that she wants to check on out of stock items or she is checking to see if the price has dropped etc.
Sometimes when designing, we embrace static methods of planning and executing the ideas. But, instead of thinking about screens, we must think about different states the system can be in and the context behind it can help us in better defining these states.
What do we mean by “state”?
A state means the particular condition that someone or something is in at a specific time.
Eg: It is raining outside, that’s a weather state and the value is raining. There is heavy traffic, there is less traffic, there is no traffic. These are different states of traffic.
Eg: In UI, the user can be logged in or may not be logged-in. These are 2 different states and both will have a different experience. Eg: In E-commerce, you will show more personalized information for a logged-in user.
There are 3 states in which a system can occur:
- User states
- Data states
- Product states (which include UI states)
User states
These are different states in which a user can be in. Some of them are:
- Users are logged-in vs not logged-in
- New user vs returning user
- Paying member vs Non-paying member
- Different roles & permission (admin/guest, can edit/only view)
When designing, we need to decide how we will differentiate these users. What features will we show them? How will we encourage them to change to different users — (from non paying member to paying member)
If our application has different roles and permission, we need to account for those. How the permission will affect the views(what the user sees) and how the view will differ for each role. What’s it going to look like for somebody in all of those different positions.
For all these different user states, there may be different content, UI components, features. They shouldn’t be wildly different, there should be a transition. Every time a person comes back to the product. They shouldn’t see something entirely different.
Data states
We are sampling a lot of data and different types of data. There is this whole data hierarchy of what gets shown and abundance needs to be managed because there might be way too much, so how do we cut off enough so that we don’t get this information and choice overload and at the same time account for less information.
When we are working with data, there are different states in which the data can be.
Eg: search or filtering — we searched/filtered and it returns no data, returns few data, returns 100 of data. Our UI must account for these data states.
If there was no result found on searching, we would want to show the user what happened and the option to search again. Maybe it was because they misspelled something, so you might want to show them that there are data for similar other words. If there are 100 data which returns on searching or filtering, you should consider pagination (or maybe infinite scroll or not)
We must also look in data presentation — will it be alphabetical, reverse chronological(date, last updated)? How are we categorizing and tagging them?
Data may depend upon the location. Eg: You have one 1 restaurant nearby(because you live in the countryside) vs you have 100 restaurants nearby(in the city). How do you show these 2 different types of data? You cannot show 100 data on a home screen, so how do you morph it, tag it and prioritize it(alphabetical, popular) to be shown.
Another Eg: half-filled surveys, half booked flights. The application where there are multiple steps to reach a goal(complete a survey, book flight), how do we take care of the leftover data. We surely don’t want the user to fill the forms from the start or a person to book to enter the destination, date of traveling from the start(and in some cases, we may want that).
Another eg: Length or variants of data. Long data, what is going to happen when we have a long name — how long the form fields should be to accommodate the length of the name. When do you truncate content?
Another eg: Timestamp i.e. Date and time, when do you show just 15 July 2018 or July 15, 2018, or 15 July or 14:00 or 2 PM or what to show and where(is it location dependent like US or UK)
Product states
Error states are good examples of product states. A product can be in an error state.
One part of the product state is a different UI state. But we still need to know under what conditions would this button be disabled? When do we show loading state and when do we not? How long does that have to take?
Nice Transition b/w different states
We need to have a nice transition between different states so that the experience remains the same. Eg: In e-commerce, when users are not logged in and they are searching for an item and add that to the basket. Now when they log-in, they still should be able to see all the items in the basket, without having to add again to the basket.
How to keep track of all these states
1. State table — you can create a state table to keep track of all the possible permutations. However, it can get complicated when the number of dimensions increases.
2. We can create a task flow or and mindmap that can help you better visualize the whole journey.
Conclusion
When designing UI things, don’t design just the screen but design a system and think about all the possible states the system might exist in.
Credits
- What is wrong with UX podcast — user states
- How to design systems, not screens by Robert Sens
