About: Anne Gibson

Website
Profile
Anne Gibson is an information architect and general troublemaker for a big/small technical company outside of Philadelphia, Pennsylvania. She's an editor and writer at The Interconnected. She is also published at A List Apart and The Pastry Box, and has a few pieces of short fiction being published in anthologies in 2016.

Posts by Anne Gibson:

Black is the New Black: Navigating in black and white

If you search for the latest in web design trends in 2017, you’ll see a lot of pretty reasonable sounding articles all putting together roughly the same list:

  • Animation is starting to be used correctly and tastefully
  • Mobile-first design is becoming more of a norm
  • Hero images still haven’t gone away and are getting “trendier”
  • Single-page (i.e. “embrace the scroll”) design
  • Grid-based layouts
  • Personalization (though no one could agree what it meant)

Surprisingly, they all missed one, and it’s a big one. In fact, I’d argue that it’s almost as big as Hollywood’s obsession with orange and teal. I call it “Black is the New Black” and it’s the proliferation of dark grey or black text on a white or light grey background as navigational elements.

Let’s take a look at the global header and global navigation for some of the top websites in the United States as reported by Alexa:

1. Google

Google's website header as of March 19, 2017. It is black text except Google logo, and the selected item in the global navigation menu, which is blue. The selected item also has a blue underline.

2. Youtube

The Youtube global header as of March 19 2017. Except for the red in the company logo and the user's profile, all elements of the header are black or grey.

4. Amazon

Amazon's global header as of March 19, 2017. Below a row of images representing products, the brand channel is a very dark blue with white text for the global navigation. The sub navigation directly below is black on white text. Very few elements contain color.

9. eBay

Ebay's global header as of 19 March 2017. After a bright green advertising bar at the top, the global header is fully black on white text with the exception of the eBay logo and the calls to action to sign in or register (which unusually, are on the left side of the screen).

10. Netflix

Netflix's global header as of 19 March 2017. With the exception of the Netflix logo and the chose menu, all elements are white on a dark grey background. We know it's dark grey because when the menu's open, it's an even darker shade of grey. Chosen elements are red on black, which I'm sure makes a certain colorblind subset of the population thrilled since they can't see it.

All of these brand and navigational experiences have a few things in common:

  • They use almost no color in the global navigational elements
  • The chosen element’s state of being chosen is illustrated through a change in font weight or border
  • The navigation bar is almost indistinguishable from the brand channel (where the brand tells you who they are, and often where the search elements hang out) or the utility bar (where top-level utilities like “messages” or “log in / log out” are located.

It’s not surprising that designers would want to understate their global navigation; I think we can all agree that we don’t want the global navigation to have a stronger visual hierarchy than the content of the page. Picking a limited but accessible color palette such as a white background with dark grey text or a dark grey background with white text accomplishes these goals.

And in the era of “flat design” it’s not too much of a surprise that the navigation menu looks neither like a row of file folder tabs nor like a row of gradient-decorated buttons. There’s something very sleek (or maybe naked?) about a row of links floating in space.

But there are also problems.

It’s breeding like bunnies

(Incidentally, I raised rabbits as a kid and it’s harder to get them to do that than you’d think, but I’m going with the metaphor anyway.)

The examples above concentrate on strictly the global navigation, but that’s not the only place Black is the New Black is showing up.

Youtube, Facebook, and Amazon are all using black heavily in their local (left-nav) navigation bars:

Youtube's left navigation column as of 19 March 2017. The choices are black on a white background, the hover state is white on a black background, and the selected item is white on a red background. The subheadings are red on a white background, though.

Facebook's left navigation bar as of 19 March 2017. It is black text on a light blue background, with black headers. The selected item has an even lighter blue background with black text.

Amazon's left navigation bar as of 19 March 2017 (on my account, anyway). Technically this is more of a filter because it allows the user to view the breadcrumb of categories that brought them to the current page then manipulate a bunch of checkboxes to change the result set. Still, the headings are light grey and larger than the subheadings, which are the same color choices as the itnteractive elements except the subheadings are bold. Only brand elements like the Amazon Prime or Amazon Fresh logo are in color.

 

 

 

 

 

 

Wix is using black on their Most Popular list as well as their global navigation.

A screenshot of Wix as of 19 March 2017. The global navigation uses black text on white for active items and blue text on white for the selected item. The list of "most popular" articles is also written in the same black text as the header and the body copy.

Alexa is using white-on-dark-blue for their global navigation and black-on-white for their in-page navigation.

The header of the Alexa website, which ranks the popularity of other websites (among other things) as of 19 March 2017. The header is a dark blue with white text, and the in-page sub navigation tabset, which in this case allows the user to toggle between "world", "country", and "by category" is black on white with a blue bottom border and bold text for the selected item.

And then there’s the New York Times:

The homepage of the New York Times as of 19 March 2017. There is no text on this page whether global navigation, in-page navigation, or body copy, that isn't black on white.

 

There is nothing on this page written in text, clickable or not clickable, that isn’t black on white.

Okay, okay, so maybe she’s called the Grey Lady for a reason and it’s a purposeful decision to cast away usability just to look like the newspaper. But CNN was never a newspaper, and they followed suit:

A screenshot of CNN's homepage taken 19 March 2017. Following the trend, nothing on CNN's website is in color except the CNN logo and the timestamp on one news article that occurred less than an hour ago. (But only the timestamp, not the title.)

 

If we had only been seeing this trend in the global navigation, we could’ve argued that people know global navigation is interactive because almost all websites place their global navigation in the same place, and it’s a learned behavior.  As the trend spreads from global navigation to local navigation to in-page navigation to plain old links, the amount of cognitive load the user needs to use to determine what’s interactive goes up significantly.

It’s difficult to tell the state of an element

For most of these examples, the primary global navigation is a tabset metaphor: you’re looking at one set of data under a specific category. If you didn’t come in the front door (thank you Google) or you have forgotten how you got to where you are, the global tabs provide you with a sense of environment and direction: here’s where you are, here’s where you can go.

So if the navigational elements don’t look like they have a specific state set, it can be confusing for the user to orient themselves. Amazon’s design  is probably the most difficult to use. Neither the global navigation nor the subnavigation change regardless of which category you’re viewing. Where are you on Amazon’s site? Who knows? Just search again and hope you get somewhere useful.

There’s also the question of number of states. For global navigation on externally-facing websites we generally only see two states: active (which means you could select it) and selected (which means you already did). On internally-facing websites or applications, though, we frequently have a third choice for disabled tabs.

Why would you display a navigational element a user couldn’t access? One reason may be because you’re in tech support and you can see other people’s accounts but not modify them — you may still need to tell Mr. Smith where the Private Data tab is located even if you can’t view it.

Internal employees providing wayfinding for other users, whether they’re internal or external users, is the most frequent use of disabled navigation elements, but I’ve seen others in the wild. Sometimes to gain access to secure content, the user has to take other steps first, which could even include plugging in a dongle or drive. Sometimes authentication is required. Sometimes it’s a vendor product and it’s just what you got stuck with.

At any rate, if the user needs to know the tab exists but can’t use it, it has to have a disabled state. And therein lies a problem: if the selected state is grey and the active state is a different grey, what color is the disabled state (which is traditionally grey)? One could argue to introduce a third lighter grey, but then one has to be careful to make the disabled grey different enough from the active grey to look disabled while also not making it so light that it no longer fails color contrast testing for accessibility.

(Incidentally, I did have someone argue once that disabled items don’t need to be readable. Hogwash. Either you need to know what’s disabled, in which case they need to be readable, or you don’t need to see them at all.)

Let’s say that we find a suitable grey or font weight or something that differentiates disabled from active or selected. Great! Now we just need to solve the problem two more times, for the hover state and the focus state.

There is only so far that we can stretch font weights and underlines and borders if we limit ourselves to a greyscale navigation system.

It matches the body copy

In almost all of the cases cited above, the body copy for the site was the same color or nearly the same color as the navigational elements. If everything’s the same color and weight and nearly the same size, what’s clickable and what isn’t?

I’ve heard many a designer over the years claim that a user will explore a page and click on things to see if they do anything, but my experience in usability testing points otherwise. People don’t click things that don’t look clickable. As Jakob Nielsen says, “Life is too short to click on things you don’t understand.”

“Just click it to find out” on an iPad using a cellular connection on a train is not exactly the speediest way to explore a website.

I’ve hear designers and developers also justify decisions like this by “the cursor will change when they hover over it”, which may be true if the user is using a mouse, but fails miserably for my iPad. Hover states are not guaranteed and can’t be used as a primary affordance.

Finally, I’ve heard the case that users are smart enough to understand that something is an article title or breadcrumb or link just by what it says and will click because they understand what they’re looking at. That works fine for experienced web users, but for young people, those with cognitive disabilities or reading difficulties, or people who are reading in a foreign language, the affordance of a change of color or other indicator that something is a link may be the same affordance that helps them understand the words are an article title.

Affordances are important

Clean simple designs are important to ensuring that our users put the bulk of their thinking on the content we’re presenting and not the navigational framework around it.

At the same time, there are critical reasons to make interactive elements stand out from their non-interactive brethren: mostly that we want our users to interact with them.

We want the choice to click on something to always be successful. We want the user to trust the interface. We want to communicate state, not only by the context clues of the surrounding content, but by the visual and structural display of the content itself.

To that end, not everyone’s global header has to be black text on a white background (or vice versa). It’s not only okay to be different, but when designed well, it will give us a more effective design than those following Black is the New Black will be able to boast.

Navigation elements should always clearly communicate their state.

Links should look different from body copy, even if the link is to the side of the page or above or below the body copy.

Text should have significant enough contrast from its background and its neighbors to both read it and understand the affordances it carries.

Most importantly, there’s more than three colors in the world, and we should not be afraid to use them, especially when it results in a product that’s easier for our users to understand.

 

Desk time

In 2016, my average day looked like this:

  • Standup (15-30 minutes, YES I KNOW)
  • Requirements / story writing (1 hour) for next sprint of main project
  • Discuss detailed design issues from current sprint (30 mins to 1 hour) for main project
  • Visioning/discovery for next release (2 hours 3x week) for main project
  • Meeting for secondary/tertiary/quaternary project (1 hour per project)
  • Office hours for Developers’ questions and technical issues (1 hour)
  • Meeting with Scrum Master for planning and scheduling future releases, setting agendas, etc. (30 mins)
  • Team meeting / staff meeting / whatevs (1 hour 1-2x a week)

On any given day, I lost about 5 hours a day to meetings. The leftover 3 hours were almost never a single block. I worked from home one day a week (“no meeting day”), which was the only truly productive day I had. The rest of the week I got my work done after dinner, at home – frequently until as late as 2am. I wasn’t alone. The Project Managers, Business Analysts, Product Owners… all of them did their real work after hours, to prep for the next day’s meetings.

Project scheduling is a cultural issue that we like to blame on the people doing the work.

The schedule-setting management team, and indeed the majority of the organization, assumed that if I was 100% assigned to a project I was doing work during 80% of those hours, not gathering data or discussing results. Nobody asked if this was true. They built the assumptions into the budgeting and schedule.

The same people who made those assumptions insisted that everyone needed to be kept abreast of all changes, and that project teams needed to be large, every stakeholder involved, etc. Because nobody could do their work in the office, the only way to communicate changes or decisions was at meetings (or in giant email changes that ended with “set up a meeting…).

And those same folks insisted that people with up to 15 projects(!) who couldn’t get their work done in the office were not managing their time properly. It wasn’t the fault of the schedulers, clearly, because quality people gave their hearts to the project.

Even staff assessments and promotions reflected a baseline assumption that the next pay grade up worked longer hours and accomplished more work. Junior staff were told, “If you want to prove you deserve a promotion, you need to step up and do the work that level requires. Once you’re doing it, you’ll get promoted. We want to encourage you to prove yourself.”  That didn’t mean “get smarter”, it meant “work independently, work harder, run your own meetings, take on more projects”. In addition to scheduled work, we were expected to hit “stretch objectives”, projects that we took on with our own time, to prove that we were ready for the next level.

The result was not a finely-tuned development machine. It was an organization that got lots of work for free, and an office full of people who believed they had to hustle harder than the guy next to them or they’d never move up. Changing the culture was out of the reach of the front-line employees, who had little to no authority over the schedules or expectations of the project teams.

But if you had asked me in June of last year, I would have told you that of course this is how it works, how could it be any different?

 

In 2017, I changed organizations. I work in a place where the elevation schedule isn’t set a year in advance by people who don’t even know what the requirements are. Here, I average 1-2 meetings a day(!) and spend the rest of the time at my desk thinking through those meetings and producing quality designs. I don’t have to work late anymore. IT’S AMAZING. I’m not spending all my energy talking to people, so I have so much more energy to get my work done. I look forward to work in the morning. My designs are more cohesive and stronger because they’re designed in one to two sittings instead of sixteen 30-minute slices. My quality’s up, my speed’s up, my happiness is up. I don’t know how long it will last, but I hope it’s the way this culture maintains itself.

The average UX Designer I’ve met is an introvert. The average UX Designer got into design not because they like to facilitate meetings and discussions but because they like to diagram things and analyze data and draw systems and think really hard. Yet, the average UX Designer I know spends more time facilitating and talking and keeping people up to speed and planning than they do building and creating and designing. It’s exhausting to live meeting-to-meeting. It doesn’t have to be this way.

If this describes your organization, know that it can only be changed at the level of the folks who set the schedules — as a front-line worker, it’s not your fault. I’ll say that again for the folks in the back because I barely believed it myself — it’s not your fault!

If you are one of those folks who set the schedules, bad news: it is your fault. You’re responsible for the culture you set. You’re responsible for how that culture impacts your employees and you’re responsible for what you do about it when you discover the problem. Yes, velocity is a critical part of an organization’s success, and delivering faster and better is an admirable goal, but not if it comes the expense of quality, efficiency, and people’s health.

Design Managers, please, look at your staff’s workload. No one’s calendar should be more than half-full of meetings; if it is, the staff is exhausted and not getting their work done at work. They’re burning out. Even the extroverts are burning out. Then look at your own calendar, and repeat the analysis. You are so much more effective when you’re not fried by your workload and your staff work with you you better when you’re not exhausted.

Is it time to staff up? Cut workload? Shift schedules? Push back on a toxic culture to the best of your ability? The solutions are not easy, and let’s face it, you’re probably trying to find them while you’re exhausted, but they’re worth the effort.

Managed complexity and knowing your audience

A while ago I did a post about documenting the core of our design heuristics. Not long after, I wrote about learnability and common sense. Today we’re going to talk about managing complexity.

For me, managing complexity comes down to four things:

  • Providing the appropriate level of complexity for the user
  • Disclosing elements and choices as they are needed
  • Making search forms and results helpful
  • Preserving context.

It’s notable that a lot of managing complexity overlaps learnability. If your user only has a little domain knowledge, they are going to feel like the system is more complex than someone who has lots of domain knowledge, because the knowledgable user knows what they can ignore and the n00b thinks everything might be important.

Conversely, if the user has a lot of domain knowledge, they may want to see all the moving parts at one time. They are, after all, experts.

Knowing your user is critical

Do you have experts? How expert are they? Do you have novices? How novice are they? What are they experts and novices in?

These seem like simplistic persona questions, but they drive a lot of decisions later. Let’s take a financial example:

Susie, a 25-year-old manager at a retail store, was just offered the opportunity to sign up for her company’s 401k. This being her first full-time job with quality benefits, Susie has no experience with retirement plans, or really savings in general and to her 401k sounds like a really long distance to run. Having been raised in the Information Age, however, Susie has no difficulty using the web.

For Susie, the key to managing complexity is breaking complex topics and information down into manageable and learnable bits, so that she doesn’t get overwhelmed.

Rob, a 55-year-old Certified Financial Planner, has both changed jobs and changed investments on a regular basis throughout his career. He has more than enough experience in retirement planning both as the advisor and as the client to handle his own accounts. When Rob views his 401k information, he wants to see everything at once – his balance, his performance, his contributions, distributions, the whole bit. He not only can handle it, he also knows how one metric affects the others and prefers the whole picture.

For Rob, the key to managing complexity is to recognize the same relationships between data that Rob recognizes, so that the right data sets can be displayed simultaneously and maintain their meaning. (These same charts, by the way, would cause Susie’s brain to explode.)

On the other hand, Rob predates the Information Age, and while he’s savvier than most people his age with computers, he can still get tripped up by interactions that don’t have strong affordances.

An expert in one aspect of your application may not be an expert in another.

Show the most caution when adding new personas

The best gift an Information Architect can get is a greenfield project where the users and their personas are well-known in advance. It’s also as rare as a winning lottery ticket.

Most frequently, especially in the “minimum viable product” world, we design a product around a specific audience with known skills and knowledge. We know whether our user (and sometimes it really one persona’s worth of “user”) is an expert or a novice in the field, an expert or a novice at using the hardware and software, etc.

When our audience grows, and we realize that we are catering to more than just the experts or more than just the millennials, or more than just the 36-45 year-old pre-retiree with our product, we need to be careful not to just “bolt on” what the new audiences need. We must take the time to reassess what the new experience means for all of our users, so that we don’t confuse them even further by stuffing them down a website side-alley so they don’t see the complex solution or forcing them to view  content they don’t need.

Don’t show unnecessary detail – but don’t invite mistakes either

Progressive Disclosure is one of our most powerful tools for managing complexity. This design technique calls for displaying only the minimum information needed to complete the current task, and providing more detail at the user’s request.

A standard example of progressive disclosure is the products page of any online retailer. It shows you just enough information to decide which products to explore further and/or add to your cart.

A screenshot of Amazon.com's Interesting Finds section, featuring some bioluminescent plankton, a notebook, an umbrella, a Totoro, five funny teeshirts, a hedgehog-shaped pencil holder, a few notebooks, a coffee mug that says "oh for [picture of a fox] sake" and a Totoro wall scroll.
Just enough info in this case is a picture of the product, the price, and how many other goobers like me were nerdy enough to “heart” it.
But there are a lot more examples of progressive disclosure on the checkout screen:

The Amazon Checkout screen including shipping address, payment method, items being shipped, billing address, shipping options and cost, and total cost of the transaction
Almost everything on this page can be modified if the user chooses.

Some websites ask the user to choose an address and payment method every time they enter the site, but Amazon has chosen to progressively disclose the option to change the default address and payment method if the user chooses. Similarly, they offer progressive disclosure of content such as their privacy notice and conditions of use.

Amazon does a fantastic job of choosing what to progressively disclose and what not to. Part of the secret of their success is that while they use progressive disclosure to display needed information, they don’t do it to the point that the user gets confused or can make an error.

On the other hand, there are many sites (and I wish I had a picture of one) that ask the user to register for access with a “enter password” field, and choose not to disclose what the password requirements are until after the user has entered a password and been told by the field validator that their password doesn’t meet the required criteria.

The same is true of things like search engines or other forms: if providing a tool to allow users to find important information, it needs to work for both the novice and the expert, even if the expert’s choices are accessible through progressive disclosure.

There’s no magic bullet for managing complexity

Complexity is, by definition, complex. We can discuss progressive enhancement, writing to the level of our users, etc. until we turn blue, and someone will still show up with a three-axis matrix of data they want to compare to a different two-axis matrix of data and have a perfectly valid business requirement to do so.

Often the goal we seek isn’t so much to manage complexity as to manage clarity: this data is complex, but can I make it clear enough to understand regardless?

Unless we’re designing for ourselves, we probably won’t be able to tell when we’ve hit that line. Fortunately, we have usability testing and research that we can use to test out our hypotheses.

For these problems, we need to seek out the domain experts who know enough to explain how they think through a problem without knowing so much that they’ve internalized their knowledge. We need people who have what Jared Spool calls Conscious Competence. These are the folks who not only remember what it was like not to understand something, but also know enough not to make the rookie mistakes. They can not only spot when something is too complex (or not complex enough) but also describe why a change needs to be made.

In conclusion

Complexity is in the eye of the beholder, and the beholder is, in this case, one or more of your personas. Strong, well-researched personas can make it easier for us to serve up complex data. User research both before and after the design of a complex data set or complex process can ensure that we do all of our users justice, and serve up what they need, when they need it, and no more.