Small thing matters, but it’s not easy
We all heard about many design stories that a small thing can have huge impact. However, it doesn’t mean we can prevent ourselves from missing those important details. It’s a bit like the famous psychology experiment - Invisible gorilla. (Link) When you see it, it can’t be more obvious; if you don’t see it, you just don’t see it. I’d like to share two of my own recent experiences and also my learning from them.
Above is a feature we made for user to answer phone calls from connected mobile device in a VR device. Due to some technical limitation in current, we will inform user the caller info in the VR scene and ask them to answer/reject the call in the Menu UI if they want. We got users’ feedback that they think the Answer call UI is hard to find. This generates several discussions on the UI re-position or just making everything of the Answer call UI larger and more colorful. Two difficulties we are facing, to change the Menu layout is a big effort on the engineering side but the Call UI will only show up when there is a call. The other difficulty is on the UI design, we don’t want to make too many exceptions from our UI style board. It will be a terrible disaster on the UI if we just enlarge things when they are complained.
We don’t do any of the improvements mentioned above, we re-position the Caller info bubble to be align with the position of the Answer call UI. This way, when user see the Caller info UI and open Menu to answer, the answer call UI is just at where they are looking at. The experience is then extremely improved. The solution may seems to be very obvious to some people who read this article. I won’t say it’s inevitable, but the truth is there were about 10 people discussing on the improvements and no one find this simple solution for more than 1 month long. What make us so blind?
The animation above is the first version we made to solve one of the design challenges on an All-In-One VR device. It’s a dilemma of choosing language and pairing controller. Controller needs to be paired to select language but text guidance is important for the controller pairing too. We chose to make an animation without text to guide user to “long press Home button to pair the controller.” Yap, again, we got users’ feedback that they didn’t get quite well of what this animation is trying to express. I ran a quick survey with 4 users who haven’t used the AIO device before, the result shows all of them don’t get what they need to do at least for a certain period of time.They know they need to press the Home button but not sure about the “long press” and the meaning of the shaking. BTW, shaking is to represent the vibration feedback after the controller is connected.
Above is the updated animation, only two things modified - controller shaking animation is replaced by a laser beam showing up, and the blue dot on the Home button is removed when the circle is progressing. I ran a survey with 4 new users again, their feedback are positive as expected but what they feedback is no as I expected at all. When people reported this issue was talking about the confusion of the shaking animation, some people even think they should shake the controller themselves as shown. I was thinking showing laser beam is less ambiguous and it’s adding things up to show the state of connected. Out of my expectation, it’s actually the removing of the blue dot play the key role of the improvement and the leaser beam only helps to be less eye-catching thus less confusing. When the blue dot removed, people can see the circle progress more clear and they know they are asked to long press the Home button and it’s the only thing user needs to do. What makes my guess so wrong?
IMHO, there are at least two things fool me and maybe many others - precondition/assumption and self-blindness. In my first case, caller info bubble position, I didn’t ask myself where should it be placed as the pop-out message is defined to be placed at the upper-center of the view-field in our design system. Our UI designer didn’t have too many choices for the answer call UI too as the system Menu has occupied the upper-center part of the view. It seems to be very obvious we should place one thing there in certain precondition, but what if the precondition is not universally true? In my second case, controller pairing animation, there are so many examples of the self-blindness. How can a user know a vibration is a hint of the connected state, how can a user know what they should do is just long press the Home button and the vibration and the leaser beam are just system feedback? We have run all these steps in our brain hundreds of times, this is why we think it’s understandable but end user doesn’t. We are polluted users but we are not always aware of we are. To examine every precondition is unrealistic and I also doubt design principles can prevent us from missing those details. (It will help on making better design after we are aware of the issue I am sure) What I learned from these cases are quick testing enlighten you more than anything else and don’t only discuss with insiders. I believe my two learning are well included in any design guidebook, but it’s still very nice to learn from your own misses. Hope my stories are so real for you to learn without missing by your own.
