About: Anne Gibson

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:

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.

A little (more) levity

Well, aren’t we all glad that’s over? Goodbye 2016, hello 2017, let’s start with something a little on the light side huh?

Remember a long time ago back in September when I moved 11 tons of bricks? Remember how one of the primary goals was to keep the terriers from climbing things?

A four foot tall pile of bricks to keep my dog from climbing the wood pile, with my dog standing on top of it.
Yeah, that worked out.

Next up, some form failures:

There are so many things wrong here…

Cuisinart blade recall form. It says "Does your model begin with FP? End in Y? Is model DLC-6?" and then provides 3 options: "yes", "no" and "do you live in canada?"
From now on when someone asks me a yes/no question and the answer is “maybe” I’m answering “Do you live in Canada?”


There are some good ways to pick a state for an address, and many bad ones, and then there’s using an autocomplete search…

This state picker for a shipping address uses an autocomplete form field so when one enters P for Pennsylvania the first choice is Mississippi because that state has a P in it first.
My state starts with P, of course I meant Mississippi!


There are no data forms so good that a data entry person with a text entry field can’t mess them up.

A line in a listing of medical lab locations. The "Days" column lists Monday through Sunday from 10:00 a.m. to 5:00 p.m, but the "hours" column list Monday through Friday 7:00 am through 6:00 pm and 7:00 am through 12:00 pm. I give up.
This is how you invite your users to call for your hours.

How about some marketing content?

Sometimes we words out if we shop wine.

A-frame sign at a Wegman's supermarket that reads" New! Enjoy the convenience of shopping wine at our store".
I hope this means we’re “shopping with wine” not “shopping for wine”, because that’s my kind of convenience.


We live in a miraculous time.

 A four GB router on Amazon's site is listed as claiming it is a "socially-conscious skin cleanser serum that cleans without disturbing the skin's natural barrier." Now that's a firewall!
Technology’s come a long way if my router can cure acne.


That’s Mister Hydra to you.

A plastic hydra at a toy store. The product is listed as "MR HYDRA" on the tag. Mister Hydra?
Unfortunately, Mrs Hydra did not appear to be available.


Tasty chips here! No really!

Kellogg Special K Sea Salt Cracker Chips are labeled "Now tastier than ever!" which, honestly, makes me suspicious.
Because someone shot down “No longer tastes like the bag!”

Finally, some false parallels.

Because you can never have too many of those.

The Keureg coffeemaker wants to know whether you want "english", "french", or "hot water".
Where do they speak “Hot water” exactly?

May your new year be happy, healthy, and full of reasons to laugh.

Learning from the ladies’ room

The new office building’s decorators had chosen fancy floor-to-ceiling stall doors in the restrooms. The heavy wooden louvered doors looked posh, they were incredibly private, and they matched other decor elements in the building.

There’s only one problem: the building’s women couldn’t tell when the stalls were occupied.

Now here’s a thing that y’all might not know, especially if y’all use the men’s room: at least here in the Mid-Atlantic region of the United States, women do not like to knock on the stall doors. If one knocks on a stall door, a couple of things might happen:

  • The door may swing open, embarrassing everyone. Stall door latches are known to be less than reliable the same way that tissue paper is known to be less than load-bearing.
  • The person in the stall (if there is one) may think the knock is on a different stall and not answer. Conversely, someone in a different stall may answer. This leaves everyone confused.
  • Even if the right person answers, they may be identifying themselves as the source of that post-tacos-and-beer-binge smell to their co-workers and nobody wants that, so there’s a better chance that nobody answers at all.

See, one of the big secrets of womens’ bathroom etiquette is that it’s ok to talk to your friends if you went in together, and it’s even ok to say “can someone hand some toilet paper under the door?” in a public setting, but it’s not ok to strike up a random conversation with the other members of the bathroom unless you can also make eye contact with them. (And when I mean “not ok”, I mean it in the same sense that it’s not OK to decide to use the urinal directly next to the only other guy in the men’s room, look down, and say, “So, how’s it hanging?”)

Women’s restroom culture requires the gap under the door so we can do a foot check / purse check and choose a stall without interacting with its potential inhabitants.

For whatever reason, the designers of this bathroom were unaware of the culture of the users, and made a design mistake.

The staff of this particular office building made enough of a ruckus that the facilities team decided to make a change. They swapped out all the doorknobs for knobs with “vacancy” notifiers on them.

A lever-style doorknob with a sliding section that displays "Vacant" in white letters on a green background or "Occupied" in white letters on a red background depending on the position of the lock.
A lever-style doorknob with a sliding section that displays “VACANT” in white letters on a green background or “IN USE” in white letters on a red background depending on the position of the lock.

An issue was missed in the design, it was identified after rollout, and corrected in production. One would think this would be the end of the story. One would be wrong.

In order for a production issue to pass test, one needs to ensure that not only is the original issue gone, but no new issues have cropped up in their place. New issues like door locks that are difficult to lock.

A lever-style doorknob with a turn-button lock, wherein the tiny slippery button must be turned to lock the door and change the vacancy indicator.
A lever-style doorknob with a turn-button lock, wherein the tiny slippery button must be turned to lock the door and change the vacancy indicator.

Those little turn-button locks don’t work particularly well for everyone. It can be difficult to lock or unlock the door, especially since one has to put some extra pressure at the end of the turn to ensure the vacancy indicator actually changes. It’s especially difficult if a) the user has motor issues, b) the user has their hands full with bags, jackets, phones, etc. or c) the restroom is heavily-trafficked and the door locks wear out easily.

When the door locks didn’t turn correctly, two results occurred: doors showed as vacant when they were really occupied (embarrassing) and doors locked when they slapped closed, even though the stalls were vacant (requiring someone to come unlock them, because crawling under the stall door to fix it was not an option).

Rather than ask Facilities for assistance a second time, the users did what users do: they created their own solution to the problem in the form of their own signs.

A laminated "restroom in use" sign with a footnote that said "Please flip over this sign when restroom not in use. Thank you." (On the other side, it says the restroom is not in use, with a similar footnote.)
A laminated “restroom in use” sign with a footnote that said “Please flip over this sign when restroom not in use. Thank you.” (On the other side, it says the restroom is not in use, with a similar footnote.)

Like many of our users’ hacks, be they physical or software, this sign worked pretty well. But like many more of our users’ hacks, it didn’t work as well as if it had been designed into the system. On most stalls the signs fixed the usability problems, but some stalls were  under an air vent, which led to situations like this:

This door has both a laminated sign reading "restroom in use" and a doorknob indicator that says "vacant". No confusion there!
This door has both a laminated sign reading “restroom in use” and a doorknob indicator that says “vacant”. No confusion there!

After more than a year of stall door hijinks, the problem was solved by a second upgrade. This time, every stall door kept its (accessible) lever handle, and gained a (more accessible) bolt lock, which would not show “in use” unless fully thrown, or “vacant” unless fully unlocked. As a bonus, they couldn’t accidentally lock themselves when the door slammed shut.

The outside and inside of a Schlage brand deadbolt with “in use” indicator.

As designers, we can take away some lessons from our bathroom adventures:

  1. It’s not good enough to assume we know the culture and behavior of our users. We have to validate our assumptions, preferably before we finish building a monolithic building.
  2. If we don’t meet our users’ needs, they will jury-rig our designs until it’s better than what we produced, even if that means that it’s still not as good as it should be.
  3. Even if we think we’ve corrected a problem, we owe it to our users to start small and test before rolling a solution out to a large audience. This is especially important if accessibility issues, privacy issues, or potential embarrassment are in play.

Design is everywhere, even especially the women’s restroom. Doorknobs (like buttons or menus) can lull us into thinking they’re easy to design because they’re everywhere. But it’s precisely because they’re a ubiquitous interface that they owe our close attention: when we get them wrong, everyone knows it immediately.