Designing a better browser navigation
A UX case study to improve reading experience on mobile phones
Ever experienced a sore thumb because of incessant scrolling while reading on mobile screens? I most certainly have and wondered why no one bothered to make reading on mobile phones a better experience. After all the world is going mobile and more users than ever consume content on their smartphones. This is my attempt at fixing this problem.
Design a better way to navigate through content on mobile browsers.
Sketch — for prototyping
InVision — for interactions
What better way to do user research than scratching my own itch. I listed down the time I spent reading articles on different devices — laptop(home and office), mobile phone and Kindle.
I am not a big fan of squinting my eyes to read on small screens and relegated most of the reading to bigger screens. Being a book worm, I do make it a point to spend 20–30 minutes each day catching up on a book before hitting the bed. I wondered why I never complained about reading on the Kindle; despite it being a bigger device than my phone. The key was the navigation. While I held a Kindle in one hand, I just tapped to move to the next page. It was so fluid and easy I barely lift my thumb. So why not re-create a similar experience on mobile as well?
I opened a long form article on Safari browser in my phone and took screen shots of a couple of ‘pages’. I transferred them to Sketch to whip up a quick prototype. Since it was a simple application with just one screen, I decided to skip sketching on paper.
I wanted to mimic the experience of reading on a ebook reader like Kindle for content on Safari. I partitioned the screen into two halves and added navigation links to proceed to the next page on clicking the right half and previous page on clicking the left half in InVision.
I made a small tweak to the earlier design and came up with another navigation. Tap anywhere on the screen to move to next page and swipe from right to left to move to previous page; akin to flipping a physical magazine.
Once I had the prototypes ready I messaged the links to some of my friends and asked them for feedback. First I asked them to open the link of the article I was referring in their browser and read for few minutes. Then try both the prototypes and rate their experience along with their comments.
The results were mostly in favour of prototype 1. While the margin was less, a lot of people mentioned they experience less fatigue with Prototype 1. Also it built on the mental model of an ebook app.
One valuable feedback I received was while the default pace of navigation is better, the current design does not address the scenario where the user would like to scroll faster to a certain section of the page to refer something. Tapping repeatedly is no elegant that scrolling maniacally. I myself have done this on some occasions and was surprised how it slipped my mind. All the more reason to do user testing earlier in the process. Armed with the data and feedback, the next iteration began.
The first idea is always easy, it is the second and the third that is tough. While trying to come up with an idea I fiddled with the music on my phone. That is when the rewind/fast-forward buttons popped right out of the screen. Building on the earlier idea of tapping to move forward/backward, it was time to introduce another gesture — tap and hold to scroll through pages faster. Just the way we do with the rewind/fast-forward buttons. Since I could not replicate this gesture on InVision, I decided to create a animation depicting the same. I sent it to same test group and sought their feedback. Lot of them had not thought about this scenario and found this design intuitive.
Skipping the paper prototype did not give enough time to think about different possible scenarios. So never skip paper prototyping.
Conducting user testing over phone does not give the chance to observe user’s reactions. Also having to explain what the prototype did could have primed the user’s perception preventing them to also consider other possible scenarios. Do user testing face to face as much as possible.
While the prototype 2 offers a better option than the default navigation, it can be tricky to implement if the website is not formatted for mobile viewing. A solution for this problem is to make it optional like the ‘Reader view’ in Safari browser — tapping on a button strips all images and displays just the text. Providing an option to view the website ‘as is’ would give a fallback option to users if the content is not properly formatted.
It was a fun exercise to come up with a solution for a problem that a lot of mobile users face. Hope the design folks at Apple and Google are listening!
If you liked this article, do “Recommend” it. Thanks!
You may also like