Functional States for experience design!
While Designing, i have often faced issues with documenting and perfecting states. We designers often end-up missing states which results in re-work.
From error to error, one discovers the truth
This article aims at providing a simple method, to help designers and product managers everywhere, Map states for the experiences they are building. By states, i am thinking beyond — the error, success, default states etc often quoted.
In my article — before you move the needle, i have mentioned about types of re-work. Evolutionary, Corrective, and retrospective. Missing states falls bang in corrective type of rework. When you need to correct something you have delivered, you face consequences, the team trusts you little, you don’t like doing it again and again, and possibly a deficient product makes it out of the door.
You might even call this as a changes, and talk about better change management, for me it would be — the point where you are starting was not well constructed.
Start with understanding states
combination is the soul of chess
What are states, states are combination of multiple variables that come together, putting together an experience for the end user.
The multiple variables could be who the user is — the kind of role they are playing, it could be about authentication — if they are logged-in or not, it could be about about the system — Error, blank, default etc. Or it could be many more.
Document the state types, and states within them
Start with mapping out the states, and adding things to the list.
For an SAAS app i am developing for the D2C market. I came with following headers for state types. This is where a QR Tag scanned by the user is validation. To learn more about the product Atakian click here.
State type: QR Tag validation
Imagine you scanned a QR Code to authenticate the authenticity of a product. It could have states like valid, and invalid.
State type: Registration
Registration status of the QR Tag— Registered, not registered.
State type: Authentication
Logged-in vs. not logged-in users.
Starte type: Conventional
Consider Error, success, blank, default, etc states
Do this for your own project. Let me know if you face any difficulties, through comment or Linkedin Ping, and i would be happy to help.
Combine the states
You could encounter many more states based on your app context compared to the ones mentioned above. For example if a user can have different roles, or what happens if they are from a different geography.
Let’s start with the ones above, so we have Registration, Authentication, and conventional states. Now merge them to generate, different combinations.
- Registration (1) — QR Tag Registered, Authentication (1) — Logged-in, Conventional (1) Error
- Registration (2) — QR Tag not Registered, Authentication (1) — Logged-in, Conventional (1) Error.
You would end-up with large list now. All you need to do is look at your mocks and check if the states are adhered to or not.
Build mocks, document and more
Beyond this it is about looking at this list, adding more to it, and checking if you have a mock for the essential ones.
So what are the benefits of doing these,
- You have a truly holistic look at design
- When changes happen you can integrate rather than depend on your memory
- You product, and users will benefit more
- It will become second nature to you after some time with a little perseverance
It was fun writing this article. I hope the readers find it useful, please do comment and let know your thoughts.
