Doing Without Thinking
Testing the expectation of users, with Pocket as a case study
I’ve been a Pocket user for a while now (RIL anyone?). Many people have different uses for it, which is what makes it great. I’m the person who adds to Pocket “stuff I want to read later when I get time”. Recently I’ve been into tagging my stuff whilst exploring some IFTT recipes. For the first time I tagged an article on the Pocket app for iPhone. I found it difficult. I was intrigued at why it was difficult, and this is what I’m going to try to answer along with my solution too.
Couple of months back I read an interesting blog post by Max Weiner of Pocket on Android user expectations. Max explained that in an older version of the Android Pocket app, they decided to replace the Up button with an Archive button when reading your article. Through some user testing they soon discovered that users were tapping on Archive without thinking, expecting to go back. The actual outcome is that the article would be dismissed (and archived) displaying their reading list with the article gone:
“wtf just happened”
That was the response from users. This got me intrigued, so I asked myself just how important is meeting users expectation and following conventions?
After the finding, Pocket changed the interaction and saw an increase in continued usage. In mobile, it is especially essential to give your users a good first impression. Anything confusing or unintuitive is cognitive drain, and in the case above conventions should be respected especially when users are already familiar with them.
This brings me to my experience using Pocket on iPhone. Specifically, tagging an item.
The above is the current flow for tagging item. After choosing to tag an article from my reading list I am presented with a modal view. I ran some short random user testing around the office asking colleagues to tag an item ‘design’. After figuring out how to select the ‘design’ tag, most people often stumbled on the second step. Subconsciously, they were reaching for the top right ‘New’ button. When they realised what it was, they made a quick turn to the left for ‘Save’. It got even more confusing when asking users to tag another item instead.
“save or new…where’s cancel?!”
iOS Interface Guidelines states that “Always provide an obvious and safe way to exit a modal task”. When designing for mobile, remember that you are designing for interruption and partial attention. The ability to lock your phone for 30 seconds and coming back to it without ever feeling lost in the app is crucial. There are many mobile UX constraints and one of them is varied environments. People use their mobile phones everywhere and usually won’t have the time or the mental effort to figure out the interface you’ve given them. What they can do is use something they are already familiar with — something that is intuitive.
When using products people are expected to use their initial knowledge of any given function.
- Pushing a shopping trolley, I expect it to go forward.
- In iOS modal views, I expect Cancel to be on the top left.
There are conventions that should be learned and respected. Breaking out of the convention involves really understanding them first, and the impact when implementing a different solution. When going against conventions, we should be aware of potential confusions, have a deep understanding of its purpose — from that we can innovate.
With everything that I have mentioned above in mind, this is my proposed solution. I have tweaked the modal task of tagging an item in Pocket for iOS.
I’ve taken the primary goal of this screen and attempted to make it clearer whilst following the conventions of iOS. The introduction of checkmarks provides the obvious affordance that you can select or unselect multiple tags. Displaying tags as small labels provides anticipation and better expectation as the same label style is used in the List view.
The result, I believe, is a much clearer and easier to complete task. I’d love to hear what you think. If anyone is interested I’ve put together both the original and my solution for comparison, into a Flinto prototype https://www.flinto.com/p/b98c74b7
