Each participant was asked these four tasks in a random order. Two questions target the top level/overview item, and two questions target items in the sub nav.

 There were three main elements I wanted to test:

I’ve seen combinations of each of these navigation schemes before, and I wanted to find out which option would perform the best. With Useberry, I was able to have participants complete the study in an unmoderated way to save time and money. I could still watch the sessions later to analyze their mouse movements and clicks in detail. I recruited 50 participants for each version of the test, and my coworkers and I watched and analyzed every session.

While analyzing these sessions, I was looking out for small interactions like:

With the overview page, I was also curious if a more descriptive label made a difference in comprehension, for example repeating “Learn About Us” instead of something more generic like “Overview”, so I made a version to test this as well.

I’ll first share the overall outcome of the tests, and then dive into some juicy takeaways and their implications.

As you can see, a lot of the average total task times ended up being very close, but Version 3, the one where there is no overview page in the submenu, clearly took the greatest amount of time. After analyzing the data, it makes sense why. Version 2 did the best, which also makes sense for reasons I’ll get into soon. I saw no real difference between my two overview labels. It’s interesting to note that the three versions without a clickable top link had nearly the same total task time.

In order to get statistically significant quantitative data, I’d probably have to recruit 10x the number of participants I did. But as a UX designer, I know that quantitative data is a good way to get a sense of the big picture, whereas qualitative data can show you the why and is often where the best insights lie. Next, we’ll dive deeper into what the task recordings and individual task data revealed.

Here’s a summary of my big takeaways from diving into this data:

Watching all of the individual session recordings, I quickly recognized a pattern across all versions, no matter the task order. On the first task, participants had a slower completion time as they got their bearings and figured out the navigation. Some opened multiple menus hunting for the answer. Then, most flew through the following three tasks. They had learned the unique interface of that design. Internet users are doing this constantly. Every new website is a new puzzle, and through practice, we’ve figured out the different possibilities pretty efficiently. But why should that time be spent learning every website separately?

One often-cited rule of interface design is consistency — don’t reinvent the wheel when you don’t have to, as it will slow users down. Instead, rely on standards already set. However, for this particular issue, there really is no standard!

At a macro level, the navigations work pretty much the same – a horizontal list of links at the top of a page, some with dropdowns of more links. But the details have yet to be agreed upon, costing internet users precious time, which is why I set out to create this study in the first place.

Information foraging is a concept that describes how people find information on the web. When trying to find the location for the information users are seeking, they may open dropdown menus to peek at what is inside of them before making a decision on where to navigate. I saw this behavior across all prototype versions. 

What was interesting was the speed difference between the “click-to-open” menu and the “hover-to-open” menu when users foraged for information. It may only amount to mere milliseconds, but continuously clicking menus to hunt for information can get tiring and has a higher cost than hovering, which can add up.

Because of this, I recommend opening the navigation dropdown menus on hover as opposed to click. There are both mobile design and accessibility implications with this approach to keep in mind, which I will explain towards the end of this article.

In Version 2, where participants could access a page either via the top link or an overview link, most participants chose the overview link. This could be because the overview link was the most obvious path, and users have learned that it’s not a guarantee the top item will be clickable. 

Still, 11 out of the 50 participants did choose to use the top link. In Versions 4 and 5, where clicking the top items did not do anything, 15 participants in each version tried to click the top link. What this tells us is that even if the majority of users know to use the overview link, some may still try to click on the top link and expect an interaction.

Providing multiple ways to complete a task or find information is a useful usability principle. It is also a principle of accessibility. As long as the different methods do not contradict each other, multiple pathways can increase findability and help users with different mental models complete a task. For this reason, I recommend making the top link clickable but also providing an overview page that goes to the same information, so that both of these methods can be utilized.

There’s strong evidence for why Version 3, in which the top link was clickable but there was no overview link, did the worst in terms of average completion time. The absence of the overview link clearly caused confusion and frustration amongst some users, dramatically increasing their completion time. 

As we saw in the last takeaway, only a handful of participants thought to click the top link, so when this became the only option, it was easy to overlook. From the first takeaway we learned that users have become adept at discovering and adapting to different patterns, so most eventually did figure out how to use the top link in this version, but not until after a bit of struggling, which of course we want to avoid. 

In Version 3, I counted 11 out of 50 users who appeared confused in some way — repeatedly skipping over the right answer and clicking around everywhere, sometimes trying the same link multiple times. Three of those 11 included “rage clicking”. We never want to cause our users this kind of stress over using our product. We don’t want to hide valuable content in plain sight where it will rarely be found. 

If these participants weren’t agreeing to test our prototype and instead encountered something like this “in the wild” it’s likely they’d just end up giving up and going to a competitor’s site in hopes of getting their needs met elsewhere. 

The results of the last two Versions, whether a more descriptive label (“All Classes”) or a more generic label, (“Overview”) was a wash – they both pretty much scored the same. But I think this time I actually will rely on best practices to dictate an approach. 

More context will give users a stronger “information scent” to follow. In the same regard that we want to avoid “Learn more” links in the body of a page in favor of more descriptive link text, we should do the same in the navigation. We shouldn’t rely on the context of the top item to inform where links in the dropdown go. This is bad for accessibility and assistive technology that only reads link text, and also just generally less clear for anyone who is quickly scanning your navigation.

In addition to the data we collected of participants using our prototype versions, we also collected data on what 100 top websites across the internet with dropdown navigations are doing.

The results were pretty shocking.

As to be expected, each of the different patterns we tested (and some we didn’t) showed up on these websites, confirming our hypothesis that there is no real consensus on that best pattern to use. 

What I didn’t expect was that the majority used the pattern that tested the worst. That’s right, Version 3, where the top link is clickable and not relisted in the dropdown, the version that took the most time and caused the most frustration, is the most common pattern on the web. Why, I’m not sure. It might be because content management systems like WordPress make it the default to set up a top item in navigation as a link and repeating it in the navigation is just looked over. Whatever the case, this issue should be addressed since it could be costing these websites lost users and revenue.

Some websites use the top link as more of a landing page to get to all of the other links listed in the navigation, such as Macy’s. In this case, I understand the reasoning not to repeat the link in the dropdown. But for others, if unique content is being hidden in the top link, it absolutely must be repeated in the dropdown.

Another bad design decision we saw repeated across sites was the mismatching of styles that made it hard to tell what had a dropdown and what was clickable. In design, it’s important to make sure that interactive elements signify how they can be interacted with, and that unique interactions have unique signifiers. 

An example of this is how a navigation item with a dropdown menu often has a down arrow. Consistency again plays a factor here. If all of the top item elements have the same interaction and the same style, such as the Barnes and Noble example above, you’re good. The trouble comes when elements with different iterations still have the same style. Take Taboola, for example, which has 3 different menu interactions that all look the same:

This creates frustration from users and prevents them from being able to learn the pattern of your specific website when every link might do something different. This is why it’s important to clearly differentiate interactions, or avoid having different types of interactions when they are not necessary.

“Hover to open the dropdown” and “click the top item to go directly to the overview page” might make sense on desktop, but they quickly fall apart for mobile designs where there is limited space for navigation and hovering is not possible. In order to create an optimal mobile experience, you will need to have some mobile-only interaction rules. 

I like how Barnes and Noble does this as well. The menu starts by being contained in a hamburger menu, or the icon that is three stacked horizontal lines. This has become a standard mobile navigation indicator, but for the sake of accessibility, I do still recommend having a “Menu” label to accompany the icon. 

With the menu open, the top items appear vertically in a stack. Tapping the top item no longer goes directly to the page, but instead opens the dropdown as a submenu. Within the dropdown, a user can still select the overview link to get to the top item page. 

This is another reason why repeating the top link in the dropdown menu is necessary. In the example of International Women’s Media Foundation, tapping on a top item in their mobile menu goes directly to the page, effectively making all of the dropdown items completely inaccessible on mobile. 

On some sites, designers make it so that tapping the top item text directly goes to the page while tapping the down arrow opens the dropdown. I don’t recommend this approach, as the arrow icon may be too small a click target on mobile. Making sure the dropdown is openable and the top item is still accessible is key for mobile.

Making the web accessible for everyone is so important and often forgotten, so I wanted to make sure to spend some time talking about how to ensure the navigation pattern we are recommending is accessible. 

This means several things:

When the top item is also a link, it can’t play the role of both a link that goes to a page and a button that opens the dropdown at the same time. For this reason, I recommend that the element that triggers the opening and closing of the dropdown to be the arrow next to the top level item. Make sure that the arrow has the role button, and the aria attributes mentioned above are applied to it. 

To recap the study’s conclusion, what is the best UX pattern for a website navigation with dropdown menus? I believe the data points to the answer being Version 2; navigations with dropdown menus should make the top link clickable and then repeat that link as a descriptive link in the dropdown menu so that it is not missed by audiences with different mental models of the web. 

For mobile, when hovering is no longer an option, make the top item open the menu only and rely on the overview link in the submenu to get to the top item page. Make sure that styles are unique for different interaction types, and consider using arrows to indicate when a dropdown exists for accessibility purposes.

I hope this article provided you with some clarity. Of course, as with many things in the world of UX, the true answer is “it depends,” and some websites may call for a unique navigation different from this solution. 

If your organization could use help designing an effective navigation or running a study to find the answer to a question everyone seems to be asking, consider contacting us.

This article was originally published by ExpandTheRoom, a company acquired by Infinum in 2023.

Accessibility best practices tend to make a digital product easier to use for everyone, because the guidelines are built on creating semantic code, easy-to-understand interfaces, and plain language.

When seniors or their caregivers make the first touchpoint with your product, it’s likely they are in the early stages of research, and are feeling overwhelmed by the breadth of options out there. This is an opportunity for your brand to step in and act as a guide. 

Keep in mind that emotions might be heightened. From our past research we have learned that caregivers often wait to research services until there is an urgent need. So these users will often be stressed, in a hurry, and unable or unwilling to take the time to read and digest lengthy instructions or complex forms.

Empathize with your audience on the tough challenges ahead they may be facing, and show that in your content. Tie into the principles of plain language to avoid overwhelming them further with jargon and complexity. Clearly explain the steps necessary to get started with your services, and what they can expect to happen. Make your contact information easily available so someone with more questions can get them answered. Offer a blog filled with resources and explanations on the topics that matter to your audience (this can also be good for helping you appear in search results). If you can become a source of stability and clarity to someone facing a lot of unknowns, you have already done a lot to vouch for the trustworthiness and sincerity of your brand.

A common concern for caregivers looking for services for loved ones is trust and safety. Often a caregiver is looking for services that will help relieve them of some of their caregiving duties, but this means trusting someone else to do these often intimate and personalized acts. 

Naturally, caregivers will be worried that whoever takes over won’t be doing so with the same amount of compassion and care that they would. Think of ways that you can show compassion and transparency in your digital products or websites to ease these concerns.

Testimonials are one way to help achieve this for potential customers – the more media-rich, the better. A text-based quote is good, and including a photo and name is better, but a video testimonial showing a patient talking about their experience, perhaps including scenes of them using your product or service, creates an immersive understanding for viewers of what you are like and how people who have used your services feel.

Of course in healthcare, data security and privacy is hugely important. Make sure that your digital products are in no way compromising user data or violating HIPAA laws. Your product should implement vetted security best practices, and you should be transparent with your users exactly on how their data is used and protected. Again in the spirit of plain language, make sure that these data policies are easy to understand and accessible, not buried on a terms and conditions page somewhere.

Show transparency to your existing users by being up front about the status of their services. Digitally inform them of upcoming appointments, the status of important tasks, or treat delays or issues with grace and communication. Think of how you can keep users informed and in control of their care wherever possible. Maybe this involves a way for caregivers to have their own accounts to keep up with their loved one’s services and needs. There are many different ways to involve seniors in their own care digitally, and a commitment to this shows you are worthy of trust and partnership.

Companies are often looking for ways to get innovative in their products, but changing the way common interface components work is not the way to achieve “innovation.” As “Jakob’s Law” from Nielsen Norman Group states: people will end up spending more time on sites other than your own, and they expect your digital product to follow the same patterns they are already accustomed to. 

Breaking these norms in critical pieces of the interface such as navigation or entering information can be catastrophic, especially for users who are less accustomed to using non-standard interfaces, as older adults might be. If you must break norms, give instruction and test the interface for comprehension.

One recent example of this was a senior healthcare portal we tested that had external links open in a new tab. Without warning the users that they were being brought to a new tab outside of the interface they had been using, many became confused and unable to navigate back to the portal. They were less familiar with tabs as a concept, but were familiar with how to use the back button. Because the new windows opened in new tabs, the back button was not an option. The portal developers thought the new tabs would be convenient, but they ended up being a barrier because the design pattern did not match what the target audience expected.

During a usability test, a user accidentally opened a new tab and had difficulty getting back to where we were previously. They repeatedly click the back button expecting this to work and are unaware of how to access the separate tab.

You might be thinking that designing digital services for seniors is not worth the effort if the majority of your audience won’t have the technical know-how to access it. But you might be surprised. According to a study conducted by the Pew Research Institute, 75% of people over the age of 65 were connected to the internet in 2021. That percentage has been rising steadily and will only continue to rise as tech users age and digital technology becomes more ingrained in our lives.

Seniors want to keep autonomy over their life and health care for as long as they can, so we should include them in the process directly wherever possible. Allow for flexibility in digital products to be managed either by a caregiver or the care receiver themselves. Give users control over their appointments, tasks, and schedules. Allow them to be actively involved in their care, and don’t underestimate their ability to understand and use your product or service. 

If seniors don’t understand your interface, consider that it may be your responsibility to put in the work to make the experience more usable instead of chalking up the difficulties to an older person’s tech aversion. Try conducting user research on your product or service with your target audience to find issues and discover ways to make their experience better.

These best practices just scratch the surface of what it takes to create a successful digital healthcare product, but hopefully it will give you some important points to think about as you take the steps to make what you’re building even better. 

More than 16%, or 50 million Americans, are over the age of 65, and this percentage is growing – along with focus and spending on digital health care. Make sure your product is contributing to the growth of accessible and inclusive digital services that can help people live healthier lives. If you’re looking for help achieving that goal through design and user research, consider reaching out to us.

This article was originally published by ExpandTheRoom, a company acquired by Infinum in 2023.

Note: The following is a transcript of the video above adapted for reading. You can access a direct transcript using the captions feature in the video player.

We often help audit our client’s websites for compliance with WCAG, which is the web content accessibility guidelines. These guidelines lay out techniques for making accessible websites.  People in the web design industry should know how easy and helpful it is to audit the accessibility of the websites we make by using our keyboards and screen readers, so in this article I’ll aim to explain how you can get started.

Why use assistive technology yourself when conducting a usability audit? When I first started doing these audits, I would use tools that attempted to scan a website and point out accessibility issues. But I found the issues were abstract and hard to parse. 

A key user experience design principle is to have empathy for the users who will be using your products and to understand their experience, so I thought that a better way to audit websites for accessibility issues would be to use the websites with the same techniques a disabled user might.

Now, I audit websites by seeing if it’s possible to navigate and complete tasks using a keyboard only as someone with a different level of motor skills might, and with a screen reader, as someone who is visually impaired might. I find using these techniques combined with an understanding of all WCAG guidelines makes the audit process much easier, faster, and more intuitive. Using these techniques allows me to truly understand why the WCAG guidelines are in place instead of making updates to code that I don’t understand.

After making the updates, I can check my work to see if it’s more usable with the assistive technology. 

Building accessible websites is a goal that all web developers should strive to meet in every web project, because it makes the web more inclusive and usable. It’s always better to develop a website accessibly rather than to use an overlay widget or add on accessibility at the end, like a coat of paint. 

The Disability Community has spoken out about these tools saying they often make their experiences more difficult instead of helping. And they’re sold to companies as a quick fix to prevent them from being sued. These add-on usability plugins are probably better than nothing, but if the underlying code is not developed accessibly there’s only so much they can do. And that’s not how we should approach the goal of an accessible web.

One more note, before we get into this, using these tools and following these guidelines is not actually that hard, so don’t be intimidated. I think that companies that sell accessibility solutions try to frame accessibility as a black box that’s impossible to understand, but I believe the concepts are not that difficult if we take the time to learn them.

In the video walkthrough,  I focus on desktop usage as opposed to mobile. If you meet the WCAG guidelines on desktop, most, if not, all of them will apply to mobile as well. Just keep in mind any elements of your website that are unique to your mobile experience and make sure they’re considered as well.

So most of us have a keyboard, right? Start by using the tab key to navigate your site. You can use “SHIFT” combined with “TAB” to go backwards. Everything you can click on a site should also be navigable by keyboard. 

As you navigate, an outline called a focus ring should follow you around, letting you know what element is currently selected. You can change the style of this, but you should not try to get rid of it as it’s essential to know where the focus is as I’m navigating through this site. Keep an eye out for any custom elements that should be focused on tab, but don’t.

For example, when testing out keyboard navigation on Grubhub.com, I noticed my keyboard was skipping over the location selector, which is a key interactive element that keyboard users wouldn’t be able to access. 

For custom elements, you might have to manually add focus via the “tab index” in order for them to be focused on. For any interactive elements, make sure you can operate them via keyboard. Some HTML elements like links and buttons will have this keyboard usage built in by default while others you might have to add.

Make sure to also avoid creating keyboard traps. This happens when an element such as an overlay traps a user if they can’t use a keyboard to get out of it. I see this all the time with popups when I try to press the escape key.

An often overlooked and helpful keyboard navigation tool is a “skip to main” content button. This button is usually located at the top of the page and hidden unless focused on, making it easy for a keyboard user to access by pressing tab when they load the page. Pressing the “skip to main” content button automatically jumps past all of the typical website header content like navigation and the site logo for easy access to the body of the page.

I won’t go into every keyboard usage guideline in this article, but even just starting to use the keyboard on websites instead of your mouse will quickly show you where the gaps are next up.

Let’s talk about screen readers. Every year, webaim.org puts out a survey on screen reader usage that I encourage you to check out.

53% of users surveyed use the Jaws screen reader, followed by 30.7% using NVDA and 6.5% using Voiceover. Jaws is a screen reader that must be purchased. NVDA can be downloaded for free on Windows computers, while Voiceover is already built into Macs. I found that both parse websites in a similar way. So if you can pass guidelines with one reader, the site should also pass using another.

Using screen readers allows you to imagine the web experience for someone who is blind or visually impaired. Screen readers on desktops or laptop computers are usually operated via a keyboard, which is why testing to make sure websites are fully keyboard accessible is essential.

With a screen reader, it’s time to listen as you navigate. Look for things like “Are images accurately described via text?”, “Can I figure out what this element is for without visual cues?”

Screen readers have the option to use a menu or rotor to navigate by certain parts of the page, such as by headers, links, or regions. It is very important to make sure the headers are descriptive and in the correct order. You shouldn’t switch from an H4 to an H2 without a structural reason.

The same rule applies to buttons and links. If you read the text of a link in isolation, would you be able to figure out where it leads? An example of linked text with poor accessibility is a click here link. Without the context of the surrounding text, you have no idea where it will go.

In addition to these guidelines, there are several components to consider that use ARIA, or accessible rich internet applications. ARIA can be added as HTML attributes that make certain interactive elements accessible, such as indicating when collapsed content like a dropdown or accordion can be opened or helping to identify what element the label is associated with. I won’t go into the details now, but I will provide the links to learn more about ARIA at the end of this article.

When auditing with a screen reader, remember to always think to yourself, “Am I hearing the full context on what this page element is for and how to use it, or is something missing?” If something is missing, look into what labels or ARIA attributes can be added.

This article just scratches the surface of accessibility guidelines that need to be considered in web development, but the main takeaway I want to convey is that using a screen reader and the keyboard really helps you to understand what needs to be considered for accessibility. It’s so much less abstract than using a plugin, and so much less expensive than hiring a tool to do the thinking for you.

Please take a look at the links I’ve included below for further learning, and don’t be afraid to use assistive technology in your process going forward.

Links for further learning:

This article was originally published by ExpandTheRoom, a company acquired by Infinum in 2023.

Which quotes are most relevant will vary depending on the specific project, but at a high level, we look for quotes related to factual information, goals, pain points, ideas, requirements, and feelings (strong positive sentiments, strong negative sentiments). The quotes will ultimately be the qualitative data that supports the insights you identify.

Simply by reviewing the transcripts in order to tag quotes, we are forced to continue to get more familiar with the research and digest more of the information, which is always beneficial, but can be time-consuming. This step can happen before or after affinity mapping. If quote tagging happens after affinity mapping, the identified themes from that activity can be utilized for tagging quotes, too.

We leverage the live notes that were taken during interviews directly into Miro to do some high-level theme analysis across the stakeholders. This is intended to be a collaborative activity, and a good opportunity to get the greater internal project team engaged with the stakeholder research. This is where we identify the key insights we learned from stakeholders.

The information we learn from stakeholders usually directly informs functional, design, and content requirements for the website from the business perspective, so our role is to simply capture and document what we learned so that the project scope can be more fully understood.

Occasionally we’ll go with a written report deliverable over a deck if findings are more extensive.

There is a lot of insight to be gained from talking to stakeholders around a company who all have different perspectives and the more intangible benefits of relationship-building cannot be overstated. Don’t skip stakeholder interviews on website redesign projects — the risk is simply too high that you’ll miss important functional website requirements, not understand the overall business goals, and waste a lot of time and money designing something that doesn’t work and will need to be redone all over again in another year.

This article was originally published by ExpandTheRoom, a company acquired by Infinum in 2023.