Page Section Navigator2018

Overview

The request from our core architecture team was to design a component product teams could use to assist their users to quickly navigate long scrolling pages and traverse nested summary tabs. The original inspiration of the component was the .pdf viewer zoom menu on the right side of the document viewport. Its display and use was to be “on demand” by the user, not persisted. The targeted page for this initial implementation was one of the more complex dense data entry forms but not that long of an overall page.

Design Concepts

Here is a set of inital design concepts and interactions.

Prototype Videos

Keynote and Sketch were used to create the following prototypes.

Design 2 Keynote prototype recording

Design 4 Sketch prototype recording

Design Realizations

From the beginning of the Page Section Navigator project, I had reservations around the basic premise of the component since this was the wrong use case to showcase, the risk was that the initial impression when testing might be skewed. The Create Invoice page had limited content, so it seemed like more work for the user to interact with the component, compared to the ease of scrolling on a supermouse (biased about the supermouse) or just using the browser scrollbar. The ask was for something that could potentially pose discoverability issues for casual or infrequent consumer users, but on the right page it would be a feature power users or professional users that spend day in and day out in the product would benefit from. This component did have its place in our application suite given the number of other flows with extremely long scrolling pages. In addition, our overall product goal was to shorten page lengths and limit the amount of content contained within pages targeting consumer users, so this eliminated my concern about those users. The close proximity to the scrollbar location would raise discoverabilty since users would repeatedly go back and forth across the page. The next realization came as I began to find out more about the intended users of the new Create Invoice page; they were professional data entry employees, paid based on the quantity of invoices manually entered. These people would want to continue to use their keyboards as their primary method of navigation to remain productive. This created a new opportunity to define keyboard shortcut options for professional users.

Another issue that presented early in the design phase was the fact that it was not a requirement for page content sections to include a title. This component would require strings for each section and subsection to somehow be provided in the background to populate the component. A quick call to our product accessibility manager resolved that open question, they were supporting an Aria Region Landmarks and Headings properties in the markup for accessibility purposes. A conversation with the technical architecture team confirmed they would be able to capture that information from the underlying page’s metadata to render the component correctly.

While researching keyboard navigation, I found an accessibility article regarding Facebook’s support of keyboard shortcuts. Using shortcuts made it easier for their browser based customers to use the site with their keyboard, using a mouse actually takes a lot of dexterity and can be challenging for disabled users. This seemed like the appropriate approach for our power users that favor keyboard navigation. They wouldn't be required to open the component, they simply would be able to have a set of shortcut keystrokes to navigate up and down sections. In addition, adding a keystroke to launch the component would allow the users to navigate the component using tab and arrow keys if seeing a visual representation of the page content was useful. Above are several screen captures from the final component specification section that covered keyboard shortcut recommendations. Unfortunately, I was unable to assign specific keystroke recommendations as these were passed on to the product accessibility team.

Final Design

What started as a simple component design, evolved into additional user experience enhancements delivered in the form of a recommended list of keyboard shortcuts that would be a competitive differentiating feature in the market place. This keyboard shortcut system is planned to become a common feature across the entire cloud application suite. As for the component, design 2 was the final direction our Senior Management decided upon due to its unique and 'novel' interaction. The component elements were converted into Sketch wireframing symbols and checked into our common Design System Symbol library. The component specification was reviewed by the PM and delivered to development for implementation. It is scheduled for formal usability testing later this summer once a better use case is available.

My Involvement

Research
Concept Development
UX Design
Visual & Interaction Design
Rapid Prototyping
Motion Guidelines

Project Timeframe and Tools

March-April 2018. Design work and prototyping was done using Sketch.