Month: January 2017

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.

But there are a lot more examples of progressive disclosure on the checkout screen:

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.

“For some reason, the parts I play, like Boromir or Ned Stark, have a life online long afterwards. I keep seeing, what do you call them – memes? […] They’ll probably be my unintended legacy.” — Sean Bean

I recently completed the biggest project of my career. As you might expect from something that significant, it had a number of wacky delays. Especially at the onset, these were from issues outside of my control.

So I often found myself talking about what cool things we’d be able to do after “The Drupaling”, without being able to say when that would even be.

Last spring one of my colleagues confided to me that she started thinking about it like “Winter is coming” in Game of Thrones. (“I don’t know anything about Game of Thrones, either,” she admitted.)

Not quite the Boy Who Cried Wolf, but somewhere in that neighborhood. Something important is going to happen. Eventually. And nobody has any idea what it means for them.

Her confession could have been demoralizing — and there was certainly enough to be depressed and frustrated about in the process. But at the same time, I felt strong in my conviction: the change was absolutely coming, and it was absolutely going to change everything. So instead I owned it.

So when we launched, this is what I sent her:

 

People should be paid for their work. Starting in 2017, The Interconnected is paying our contributors. 

Writing is work. Writing is hard work, honestly. You’re taking a nebulous mix of ideas and feelings that live in the grey matter inside your skull,  and using a mix of education, cultural information, and creativity, forging it into a form that means other people get a similar mix of ideas and feelings in their own grey matter.

Writers are often paid little, or not at all. A professional rate in the science fiction short story market, for example, is six cents per word. A five-thousand word piece nets $300, and may have taken many hours to write. A professional rate in the nonfiction market can be higher or lower, but is often a fixed rate – $100 for an article, or $200, or $50, or nothing at all.

We’re paying writers.

At The Interconnected in 2016 we paid our writers with thanks.  But we want to do more, because our writers deserve more.

We started by paying our 2016 writers: Trace Meek, Justin McDowell, Talisha Payton, and Alicia Raciti, and extend our thanks to them once again.

We’re now extending the offer to the greater UX, content strategy, development, design, and “web maker” world. We’re paying $25 per article; currently we can accept about 2 or 3 articles per month. Submit to us or pitch an article.

Help us fund quality writing.

We’ve currently got enough funding to support our writers at this measly rate through 2017, but we think we can do better, and you can help.

• Support us on Patreon. We’re still working on goals and levels of support, but even a tiny pledge will help fund better writing about the human side of technology.
• We are also looking at advertising options. Contact us through the submissions form if you’d like to advertise on our site.

The Interconnected brings a diversity of new and experienced voices to the web. We hope you’ll continue to support us, whether it’s financially, by reading and sharing what you read, or by working to make the web a better place through whatever means you have available.