Guiding users to their next task
Lead Designer at WellnessFX
Taking Stock of Cluttered Configurations
WellnessFX offers a handful of integrated, but distinct services, that have been combined and configured in a variety of ways for different types of users.
When people sign in to the app, they are doing so for any number of different reasons, based on different prompts and goals, and often with differing services available to them. In order to help orient each person to their next task, I looked for ways to address each person with concise and noticeable prompts that wouldn’t be otherwise distracting.
Customization Calls for More Flexibility
Initially, the services WellnessFX provided had almost no variation and almost everyone that signed up for the service went through a very similar experience. As the company expanded to offer a wider variety of services and partnered with different organizations with distinct needs, the product experience became much more customized. As such, it became more complex to present different experiences to a diversifying set of users. After considering some different venues, I narrowed in on rethinking the main navigation and simplifying in-app messaging.
The web app was originally designed with a horizontal top navigation—a fine choice for earlier needs—but the incremental addition of new sections eventually turned the nav into a messy and sometimes confusing experience. We also relied on a checklist-style component (on a single page of the app) to tell members what they needed to do next. This solution became increasingly unscalable and brittle as new conditions and contexts were added, so I looked for ways to clean up the experience and rethink functionality.
Mapping Key Areas and Functionality
In order to clean up the navigation hierarchy, I mapped all key areas and flows of the application and explored different configurations and groupings.
I initiated discussions with different team members first to make sure I was focussing on the right things, and then began sketching concepts to address ways to inform users about what actions they needed to take from anywhere within the app.
Validating Concepts and Exploring Solutions
My solutions didn’t all hinge on integrating messaging into the navigation bar, but after reviewing and critiquing various options with other team members, I zeroed in on integrating messaging for “what’s next” into a restructured vertical navigation bar. This direction allowed for:
- regrouping primary and secondary navigation items into more intuitive groups, to both orient users to our wider suite of services, and provide a subtle hierarchy based on the relative significance of different sections
- more clearly structuring navigation variations for different types of users, some of whom have the ability to view navigation items for or ‘as’ other users(!)
- providing actionable context for any signed-in user about what they need to (or can) do next from anywhere in the app
In parallel, I began to:
- outline the primary messaging for each key flow or step that members should be prompted with
- explore regrouping and restructuring elements in the main navigation
- consider how to nest and contextualize various options for user types, particularly when certain users have the ability to view options for other users, or have options associated with different roles
Jumping quickly to mid-fidelity explorations
Because of the complexity of information, I found that outlining structures with lists and spreadsheets, and then assembling rough layouts in Sketch, was much faster than starting with pencil and paper. Jumping quickly to a ‘medium fidelity’ stage of design allowed me to experiment with visual components with more polish than barebones wireframes, without having to invest in the full detail of high fidelity comps. Below are a various containers and formats I explored to convey users about important next steps.
Shaping Up Solutions
Once I explored a variety of ideas and compared strengths and weaknesses with different cases, I settled on a vertical navigation bar that could include a simple module with prompts for users across the site.
By switching to a vertical navigation design, we could better support different user types (some of which have more complex navigation structures than the standard user), and still allowed us to maintain a consistent navigation hierarchy.
Dynamic prompts within the Nav bar
When users sign in, they are typically interested in accomplishing a specific set of tasks and that’s it. While there is room for exploration, this is not Facebook. I identified all of the primary actions associated with our main services, and mapped them into concise messages with simple calls to action. Required actions stay visible until a user completes the task, while other suggestions can be dismissed.
Sorting Actions By Importance and User Type
The primary focus of the navigation is to serve the needs of members who have accounts with personal health data, but there are also various user types with administrative privileges that needed consideration. I went through all use cases for each user type and organized configurations for each type’s navigation accordingly. I continued mapping out variations and structures until I had identified not just all of the primary cases, but the troublesome edge cases as well.
A standard member’s configuration (left) shows all primary services and supporting sections. Practitioners, who provide health consultations to members, can see certain sections of members’ accounts (middle), and Admins have a whole host of sections available to them (right).
Coding for Details and Interaction
Optimizing for tablet-sized screens is a priority I embraced as an important design consideration, and part of the reason I opted for a vertical navigation (that could scale and be hidden off-canvas when necessary). In order to explore and establish appropriate responsive behavior, I created an interactive prototype to continue design work. With layouts, configurations and styles established, moving to code allowed me to experiment with interactive elements, account for behavior at different sizes, and finesse details with some production-friendly code. It also allowed me to identify a couple inconsistencies that would have been difficult to catch without designing in the browser. While the code for my prototype was not built to be a final version, crafting markup and CSS to the same conventions and quality it ultimately needs to adhere to helps to streamline the implementation process and reduce redundant work.
I prototyped interactive behavior for collapsing and revealing the navigation panel, mapped out layout behaviors for existing sub-navigation areas, and designed a set of custom icons for the main navigation items.
This prototype was used to illustrate styling specifications as well as demo responsive behavior and select interactions
Testing in Production
Gathering user feedback and testing designs is usually something that’s helpful to do early on in the design process, but for this project, we chose to build first and gather feedback from users by rolling the new designs out incrementally. Postponing gathering feedback can sometimes be risky, but due to the integral nature of a navigation system and the relatively low risk of user rejection, we felt this was an appropriate decision. The things we wanted to validate—like seeing how well users could identify and complete tasks they needed to—would have been much more difficult and less authentic with design mockups than their own user accounts with real tasks at hand.