What is a Contextual Element?
A contextual element is a dynamic component of a webpage that appears or functions according to user needs. (It’s not to be confused with a contextual inquiry, which is an unrelated UX research methodology.) There are several common patterns you may already be so familiar with that you have come to expect them as a user. The hamburger menu, for example, has become so widespread that its absence can be a pain point for mobile users in some situations. A horizontal navigation menu that shrinks down into a small icon on your phone is adapting to the Screen Size context.
The Value of Context
Designing for context is the cornerstone of UX design. It means considering not just your user, but your user’s whole experience. It takes time (and budget) to understand not only where context matters, but how it can be addressed effectively. Building stakeholder buy-in for these considerations is a valuable skill for any designer. Knowing your KPIs and staying aligned with your value proposition helps, but you also need to know how to persuasively emphasize the importance of the user needs behind the problem you’re trying to solve.
User Flow Context
The UX of the search bar takes helps lead users to action by showing available search methods according to that stage of the user flow.
In the context of the homepage, many users are at the beginning of their journey and thus may be unsure of where to begin in their quest for overnight accommodations. Instead of hiding the most common filters behind an icon, they’re readily available as hints – like Navi guiding Link to the next objective. 🧚
On the Search Results page, the search bar is shown with the current query in place. Not only does it retain the information already provided by the user, but it also eliminates the need for an ugly text header in the body that obnoxiously reminds them what they searched for – you know, in case they forget.
By the time the user is viewing a Single Location page, their Search bar has been simplified. As a user progresses, their discoveries can change how they prefer to interact with the product. Since their next search may be more granular or purposeful, the extra labelling isn’t quite necessary now.
Screen Size Context
User behavior may change depending on what device they’re using, but I hesitate framing this context by device. Truly responsive websites will adapt to the size of the user’s screen size, not the device it’s being viewed on.
For this example, we’ll be looking at the sidebar on the right, which contains the CTA. They apparently named this the “Book It Bar” (which I absolutely love).
On large screens, a typical shopping pattern includes having several tabs open simultaneously with different options to compare. Keeping key information in the same place on all pages is helpful in this scenario. Preferably above the fold, and in the same vertical position, so it can be located quickly when tabbing through windows.
Airbnb’s Book It Bar on Desktop does a great job of keeping that key info (pricing details and travel dates) close to the CTA. It also beautifully utilizes the real estate of large screens: We can see additional details, such as a breakdown of fees and number of travelers. They’ve also included two forms of reassurance: Reviews (even though we can find them elsewhere on the page), and payment information. The reviews remind the user of the value of the product they’re considering. Next, the payment information informs users that by clicking the CTA, they won’t be immediately charged, which can help make them more comfortable with proceeding.
Not only is there less space to work with on mobile, but shopping patterns are different. The sidebar used on desktop would fill up most of the viewport, so an entirely different experience is needed.
Our Book It Bar is now in the form of a bottom-docked sticky bar, with only those three key pieces of information: pricing info, travel dates, and CTA. Instead of the traditional calendar date picker seen on larger screens, we now have an entire drawer that allows us to use the entire screen to view and select dates without navigating away from single listing. For an extra treat, the CTA button becomes a Save button to guide the user along their path to booking.
Anecdotally, it’s not quite as easy to shop from multiple tabs on a mobile device. (I’d actually love to know if they did any comparative usability testing on this, but I digress). So how do users track multiple options as they make their decision?
- Add to Favorites
- Export the link
User Role Context
Designing for a specific user-role can be far more complex than the examples discussed so far. It makes sense; If you’re designing a product for a user experience, a different goal will change how they interact with most aspects of the product.
I’ve been lucky enough to be involved in projects both admin- and customer-facing. While many common components can be used on both sides with some contextual tweaks, sometimes the goal is too different for that approach to make sense. I’ve seen stakeholders try to “retrofit” entire pages, even entire products, to fit a different User Role Context. It’s usually done as a way to cut budget, but unfortunately it usually results in higher cost with unexpected delays. The following example from Airbnb can show you why planning for all user role contexts from the beginning can save the project time and money.
Logging into Airbnb as a guest (customer), the first screen you are directed to is the Dashboard. Center stage is, of course, the properties. In visual importance, search and sorting features take 2nd and 3rd places. The grid layout works well to organize the imagery. The search bar we discussed earlier is emphasized with whitespace. All these layout decisions came together to support the goal of the guest, and only the guest.
If you log in a host, your experience of Airbnb’s dashboard will be dramatically different. That’s because the goal is different; The host isn’t searching for properties, they’re managing them. Almost no element is the same, there are new elements, and others don’t exist here. Using the guest dashboard as a starting point would have certainly been a short-sighted budget disaster, if not an impossible ask.
Buy-In for Context Considerations
Being curious about potential contextual differences in the initial stages of a design is easy. As designers, we want to explore, test, and iterate to feel like we’ve done our job to our best ability. An experienced designer will know that investing the time to consider context can save so much more time in subsequent phases. The hard part, of course, is staying in budget.
If you can show a scenario in which an element doesn’t work in one of the three main contexts mentioned above – user flow, screen size, and user role – it should be fair to expect the budget to accommodate a solution. If you’re having trouble getting that buy in, there’s a few questions you can ask to move forward:
- Have I looked for another solution that can intrinsically address all contexts?
- Is my communication of the missing context confident and understandable to those without design knowledge?
- Have I described a clear solution to the context I'm trying to address?
If you answered “yes” to all three questions and you’re still not getting the greenlight, you may have at least uncovered the reasoning that’s restricting your ability to proceed. This reasoning is important – not just to understand why you can’t get the buy-in in this situation, but to reframe future design decisions within those boundaries. In the beginning of my career, those conversations just left me frustrated, but now I see the value in understanding those limitations so I can adapt my process. Just like your elements and features, the design process itself should be contextual to the needs of both users and stakeholders!