How to describe and document 'complexity' in UX design

Question

There are various ways to analyze software complexity when it comes to the actual code behind the system, but I have often struggled to be able to discuss with people about software complexity when it comes to the UX design.

People often talk about simplifying design and reducing the complexity in workflow, but in my experience I haven't found many good ways of explaining how this is done, other than things such as reducing the number of clicks to get to a page or making the navigation easier.

From what I can see, there are several elements that make the design of a software system or application complex, and this can apply to any aspects of the design including information architecture, user interface design, interaction design, workflow, etc.

Density - this refers to the amount of content presented to the user within a given context/view. So a dense IA, UI with lots of elements or a lot of steps in a process all contributes to complexity by density.

Diversity - this refers to the amount of variation or variety that exists within the design, whether it is the use of words or language, types of user interface elements to represent similar content, or types of user that it caters for, etc. Having to design for more naturally adds to the complexity involved in making everything consistent and coherent.

Design language/system - this refers to the principles and processes used to create the logic and structure upon which all the design elements are put together to create the software. So a system that is simple and clear to understand, easy to maintain/update and highly modular/extensible reduces a lot of the inherent complexity of the software that is developed.

I have come up with my own way of analysing UX design complexity in terms of theses three aspects, but I am wondering if there are some standards out there that also allows designers to review and reduce the complexity in their designs?

Answer 1

Are you in danger of choosing "complex" when it really is about "confusing"? I have used very complex software yet it is very easy to use, while I have used very confusing software which just sucked (was unusable). Perhaps you are looking at this in the wrong way?

I talk to stakeholder in terms of UX Debt (it is a borrowing from something developers talk about in Agile - Technical Debt)

• Things that are confusing, add to UX Debt.
• Things that simplify reduce UX Debt.

Ideally you want to minimise UX Debt.

You can choose all sorts of UX metrics and human Psychology and Psychological things (like Cognitive Load and Choice Paralysis mentioned by @Andrew Martin, or Fitts' Law) which will impact UX Debt positively or negatively.

UXPA wrote an article about UX Debt: http://uxpamagazine.org/ux-debt-in-the-enterprise/

The term “technical debt” was coined by Ward Cunningham as a metaphor used to describe the increased cost of maintaining technology due to shortcuts taken during the development process. Joshua Kerievsky later extended the metaphor to user experience design using the term “User Experience (UX) Debt.” Kerievsky explained that, like technical debt, UX debt will eventually come due, usually in the form of less customer satisfaction and possible customer defects.

The UXPA article includes a UX Debt Calculator, which you might find useful.

UXPin also wrote about UX Debt too: https://www.uxpin.com/studio/blog/3-step-guide-erasing-ux-debt/

If your product suffers from inconsistent behavior or performance, you’ve probably made long-term sacrifices for short-term gains. You’ve accumulated UX debt.

For example, it’s not uncommon for a company to release a “critical mass” of features to gain market share. The team worries first about quick user acquisition, scheduling the cleanup work for later sprints.

When it comes to UX debt, you won’t know all the answers immediately. And you probably won’t fix it all by the next release. But that doesn’t mean you should give up. If you can create a plan that doesn’t give product management a heart attack, you will eventually eliminate your debt.

UXPin quoted a talk about UX Debt at the IA Summit 2014 in San Diego given by Andrew Write. Here is his slides http://www.slideshare.net/andr3wjwright/ias14-uxdebt

He buckets UX Debt into two categories.

Intentional UX Debt

There will be times when your project just doesn’t have the time, money, or resources to do it right. Something will have to be sacrificed, and there’s a good chance your users will notice. Whenever you willingly cut corners that will impact the user experience, you’re bound to be in the hole with your users.

Unintentional UX Debt

But not all debt is intentional. One of the most important rules of good UX is to remember that you’re not your user. But your users aren’t always themselves either. By that I mean that users will change—constantly. What works for them today may not in a few months or a year. You can also unintentionally get yourself in the red with users if you’re not diligent about understanding them before you build your product. For example, if you throw a wide net and create a general persona , you risk missing out on specific traits your audience possesses. For example, just because a big chunk of the general population seems pretty stoked about the newest Star Wars film, that doesn’t mean your audience is as well. And making that assumption will only make them feel like you don’t really know them at all.

Answer 2

I personally think the the task of documenting complexity in UX is straightforward, if tedious. From my perspective it is as simple as making an honest accounting of "size" or bloat of very common dimensions:

Pattern Complexity - Distinction conveys meaning. Elements which share the same function but have a different visual treatment only add cognitive overhead.

Conceptual Complexity - Consider the stepwise process of generating a some kind of analytics report. Pick your your dimension, pick 1 or more metrics, a date range, and go. That's 4 actions total, including the final step. A UI design which demands even 5 steps is already bloated.

Complexity of System Text - This should always be considered relative to the representative audience. The terms and labels and language should match the expectations and vernacular of the user. Maker-centric jargon requires translation and on-boarding.

Visual Complexity - How many visual styles are at work? Type treatments, AKA unique combinations of typeface, weight, treatment, color? How many different graphic aesthetic approaches (flat vs. raised, for example.)

Just start counting these things. You don't need users to perform a quick assessment of the complexity of a design, you just need a good night's sleep and maybe some coffee.

Answer 3

Dimensionality

It very much depends who you are talking to. I find the best way is to find a similar metaphor from their experience.

In my particular case, most of the people I work with have some kind of engineering or mathematical knowledge, and I find that the metaphor of a problem space helps... and once you can work with that, the dimensionality of the problem space is a useful metric to work with when discussing complexity.

Warning: Impending Complex Explanation!

It's not the easiest metaphor to start with, but when you start to get it, it's a great way to explain complexity, how it grows and the impact it has.

Think of every single thing the user has to think about or decide when looking at what you are designing as a dimension in a matrix or graph. Those dimensions then define orthogonal axes in a volume - call it the problem space. Every possible option that the user could choose or want to choose is in that problem space. As in, axes that are at right angles to each other. Up to 3 axes, this is easy enough to visualize, but after that it gets hard.

If you've only got one variable or choice, your problem space is a line Linear choices are easy. They're either A or B or a point on the line from A to B.

If you've got two variables or choices the problem space is a 2d shape They're usually easy enough. You're either looking at the corners of a square or all of the cells in a grid.

If you've got three variables or choices, it's a 3d problem space.
Most people do okay when dealing with specific examples of this that they already understand, but adding an extra dimension like this increases the number of combinations available to the user (the volume of the problem space) exponentially rather than linearly. It's also harder to represent on a 2d screen.

If you've got more dimensions than that, life gets complicated.

What to do about high-dimensionality

When I'm working with a design and trying to identify & reduce complexity, I start by working out how many dimensions exist in my problem-space. I work out all the choices the user has to make, and all the variables required to represent those choices. That tells me how many dimensions there are in the problem-space. As a general rule, the answer to "how many dimensions?" is "too many" at first.

I then look for strong correlations between values on those dimensions. Stuff like:

• "If X is high then Y is always also high, if X is low then Y is also low"
• "If X is high then Y is always low, if X is low then Y is always high"
• "These values for X only exist when Y is 1, and those values for X only exist when Y is 0"
• "Only one of X, Y or Z can be true at a time"
• "These settings only have a value at all if that setting is TRUE"

Where those kinds of strong correlation exist in a way that can be conveyed to the user, you don't need to present the user with each of those dimensions anymore. You can instead present the user with a single combined dimension instead of those two - if the values must be directly related or opposed then it's effectively just one decision for the user and is best presented as such.

What if it's still too complex?

Once I've done that round of reduction and dividing, I start looking at slightly less strong correlations. If there's a pretty strong correlation between two possible choices, but one or two users or use cases don't fit that correlation, the questions become "why don't they fit?" and "is this the right tool/feature/product for them?". It usually means we're a bad user/product fit for them, that they're doing something misguided or that we've just missed something and need to add another dimension again to cover it.

All of these are good things to know, and investigating that will usually lead to a conclusion that, whilst it might not make everyone happy, will achieve the most happiness overall.

A strong metric

It may not be quite what you're after, but working out the dimensionality of any given area of a product can be a handy metric for complexity. If the dimensionality gets too high, it tells you that you might need to rethink in some way, or it might provide context for why users are struggling.

This approach might not solve every problem, or help you find pre-existing problems in a product that's already out in the world... but it might well help you put a problem you're already aware of into context and help you move forward. It's also something that you can build into a design review / critique process as a metric to compare against metrics from stats & user testing.

You'll also notice that I don't particularly talk about choices about which UI components to use... because that's not the level where the complexity usually hits. It's about the choices a user needs to make and the information they need to have in their head to make them. Choosing the controls the user uses to express a decision is important, but minimizing the number of decisions to be made is considerably more so!

Hopefully that helps. If it's not very clear, I have some of the ideas from this in a (quite possibly even less clear) blog post over here.

Impact on UI Design

(added by request of the question author) When it comes to applying this to UI design, I've generally found that the UI design questions become a lot simpler and less numerous when you've first worked to reduce the dimensionality of the problem space.

With a reduced number of decisions to be made, the UI design process immediately becomes simpler.

Also, if you identify that groups of those settings do not influence each other at all (changes to them are completely separated from each other in the problem space)... then that suggests they should be separate controls or groups of controls - further reducing the complexity.

Using your definitions above, reducing the dimensionality immediately reduces the density of controls. With less controls, you have more room to move in the design of the UI.

By reducing the density of controls, you're also making diversity of controls less of an issue - with fewer controls, it's a lot easier to focus down on building a set of common UI components to allow the user to interact with them, lowering the barriers to getting a good design language / system.

To sum up, reducing the dimensionality also removes a lot of the barriers to producing a strong UI design. It won't do the design work for you, but it will reduce the amount and complexity of what you need to do, and the process of doing it will often suggest UI approaches that you might not otherwise have considered.