Why Designing Obvious Interactions Matter
A story of how designing a small interaction made my team realize that we shouldn’t ship a feature
It was just another day at the office and I was designing the ‘Team View’ within Hiver. What is a View? A View in shared mailboxes lets you quickly access conversations in the shared mailbox that meet a certain set of conditions. For example, a View can give you single-click access to all emails in a shared mailbox currently not assigned to any user and are in the open state. The Team View is a section in the mailbox where you can see emails assigned to each member who is part of the shared mailbox.
What were we trying to build?
The goal was to design a ‘sort’ for this list. Why? Because in the above view, there was no way to easily see the users who had emails assigned to them vs those who didn’t.
Now there were two major things to consider:
1. As new emails come in under each user, the count changes on the fly.
2. There are two orders of sorting here — Alphabetical order of names, the order of email count.
We decided that the sorting would be based on the decreasing order of the count only — This shows the distribution of the team’s workload and is relevant to this view.
The mystery of the obvious interaction
Everything was cool until I had to present my design to the developers. They asked a question — “What if I’ve sorted the list and a few minutes later, a member gets a new email?”
I had a quick answer — “Oh, it’ll automatically sort the list, just like in a leaderboard — where scores are changing on the fly.” Then a truckload of questions hit:
- What happens to the selected user? Does their position in the list move too? How will that UX be?
- What if the member is somewhere down below in the list, outside the user’s viewport?
The discussions took me back to the drawing board. I built the (seemingly obvious) interaction, and it revealed a shocking truth — the user experience was supremely confusing:
- Case 1: When the list is in the sorted state but the email counts of the members change. i.e., someone gets a new email(s) assigned to them.
- Case 2: When email count changes for the selected member and as a result, they move out of the viewport to maintain the decreasing order of the sorted list.
Rationalizing
Clearly, these interactions show that the Sort functionality had many constraints than previously anticipated (and the UX was very unintuitive). There were two primary reasons why this wasn’t working out:
- The team view list is not like other conventional lists — this list is also a navigation area. Clicking into each member of the list will show the emails assigned to him/her.
- The counts are dynamically changing. This makes live sorting all the more unintuitive and unusable.
Edge cases may lead to building better features
This incident got the team thinking and eventually paved the way for a better feature. Workload visualization:
As a user, while consuming ‘Views’, I should be able to see the workload distribution under each View so that I can see if the work among the team members is optimally distributed and if it requires re-distribution.
Simply put, instead of sorting the Team View list, now the user can go into any View and see how these conversations are divided among their team. If the workload distribution is not optimal, they can re-distribute conversations to their team members.
Conclusion
As a designer, the onus is on us to provide the user with a simple and seamless experience. When interactions in your design seem obvious, always ask yourself three questions:
1. Have I considered all the constraints involved in this system?
2. Can I envision this interaction end-to-end?
3. Do I have references to validate my idea?
I’ll leave you with a quote by Paul Rand (he was an American graphic designer best known for famous corporate logo designs like IBM and ABC) that describes this episode the best:
❤️ The Design team at Hiver.
