Too complex

Recently I was asked to evaluate a big data analysis system. The system is truly amazing. You can do tons of calculations with it, determining dozens of parallel hypotheses and testing them out. But there is a problem. The system is seriously intimidating to its users. It is so intimidating that some of them rather go back to cumbersome excel calculations than suffer through learning and using this tool.

As I was delivering the news to the start-up, you can imagine how unhappy they were. Yet they had a really hard time accepting the fact that their beloved product is just too much for their customers.

Complexity in the solutions we are having delivered these days is immense. I am not only talking about the big data analysis systems. I am talking about Facebook, LinkedIn, you name it. We tend to get so high seeing the possibilities current technologies give us that we stop thinking whether we are not overwhelming the people who are supposed to use them.

Back in the eighties (I seem to be coming back there a lot:) the UIs weren’t easy to use either. But the reason for their complexity was exactly opposite to what we experience today. Back then the computational power was so scarce that complexity was a way to present the user with any options. You either had your options in their bare ugly way or you had them not at all.

Now we have the ultimate (for our present needs) computing power available. There is a possibility to present the users with as many options as we can possibly imagine. So, we imagine them and put them onto the UIs. The main problem is, however, that our users aren’t us. They do not spend their entire days trying to figure out how to be more social or how to increase the usage of mobile phones. They go on with their, often pretty complex on their own different levels, lives and would like to be offered options they could master without too much ado.

Informed abstraction

Back in 2000 I once had a very inspirational class with Bill Buxton, the author of “Sketching User Experiences”. He was (already then) talking about this exact problem. He was aware that the situation with data overflow, we have today, will sooner or later happen, and he tried to warn us at the young adepts of the interaction design profession that we should be aware of that and design solution with informed abstraction in mind. He was telling us that we should define the right level of abstraction that is still simple enough and yet offers the conglomerate of options and build our solutions around it.

Designing for informed abstraction

There is probably more than one way to go about this challenge. Something that I try to practice is designing networked solutions. It is tempting to build your system as one chunk of software (or hardware). Make it into an interconnected machine where everything depends on everything else and then deliver it to the users without an option to switch some things on and off. A networked solution is a solution where you build interdependent interactive elements and combine them into useful sets according to the needs of a particular user group.

Let’s take an example of a big data analysis software. Your client may very much like to use the basic functionality of your solution like calculating the different pricing schemes depending on how the market behaves but he may not be as keen to connect it to his logistics data (just yet). So, instead of giving him a fully blown solution with all options on, you just deliver the blocks that he needs. Once he asks for more you have the other options ready one switch away.

You may think that this is terribly obvious. So many systems (for example ERP systems) work in that way. But do they, really? Sure, there are solutions with on and off options but they are more often than not built as separate systems not as interconnected solutions. At least not on the interaction and UI level. Look at banks: this is the ultimate area for interconnectedness. But typically (due to the technological dept, I am aware of that) they are either one immense black technological block or a few systems merged together so that they barely work.

Thinking it terms of informed abstraction

Getting the informed abstraction right requires stopping to see the users as one homogenous group with limited variations. It requires defining alternative scenarios for different user groups and implementing those scenarios into your system. It requires to think of a system as a network from the very beginning. A cool way to visualize it is to use real building blocks and write on them the functionality you want to develop. Before you start drawing the screens. And just after you finalize the conceptual phase.

_______________________________________________________________

Aga Szóstek, PhD is an experience designer with over 19 years of practice in both academic and business world. She is an author of “The Umami Strategy: stand out by mixing business with experience design”, a creator of tools supporting designers in the ideation process: Seed Cards and the co-host in the Catching The Next Wave podcast.