The front-end of an application or dashboard can be difficult to design.  It takes a multi-disciplinary perspective to get right and often requires different people since it's not common to find a single person that has the skills and experience.  Getting this wrong results in applications that have cluttered and complex views, undiscoverable functionality, and require a steep learning curve.  At one point or another we've all been in the situation where we feel overwhelmed by an interface.  The interface demands that we learn about it instead of it unfolding itself as we would expect.  This cognitive overload interrupts the flow which we're currently in and may have serious implications.  The extreme example would be: imagine you're driving down the highway at 80mph and you had to determine what type of brake you needed to use before you could press the brake pedal.  That situation could be catastrophic.  Fortunately, most situations aren't as time sensitive.  However, with a growing number of applications we're using in the Cloud, these applications will need to understand that they can no longer demand large cognitive loads and steep learning curves.  If something is hard to use, people will just decide not to use it.

When we build applications or dashboards, we use the process below which mixes the disciplines of: 
  1. Product Planning or Business Analysis
  2. Visual and Interaction Design

Let's dig a little further to learn why these cycles are important.
Picture
Define the roles for the view

In order to build a view that isn't cluttered and complex, we need to understand where the user is coming from and what they would understand.  We look for vocabulary, models, and visual language in order to speak the language that the user speaks and decrease the learning curve for the user.  

Given that we're building new software it's safe to assume that the user has a problem which needs to be solved.  This problem is often in the form of creating visibility in a system.  For example, in an invoicing system a user might want to determine: "Which are the vendors which haven't invoiced their work?"  In a marketing web site an analytics questions might be, "Which users downloaded a white paper and have an expired trial product for more than 15 days?"  For a dashboard the question might be, "What is the state of the business given the target goals?"  Of course, these questions lead to other questions which is how applications are born.  For example, "Once I have the list of users for which the expired trial software, I would like to send them an coupon discount offer via email."  If you're familiar with the idea of a user story from XP/Agile, this is where you might realize that a user story encompasses the type of user, what they want to see or do, and the reason.

Data organization and analysis

Most software does something with data - store data, move data, process it to determine interesting relationships, and/or visualize the data to identify some insight.  The bad news is that data is often stored in different places and encoded in different structures or formats.  The challenge of answering specific and interesting questions about data usually requires merging and  visualizing multiple data sources.  

The question that arises next is, "If we have different data sources we'd like to join, how often do we need to make that happen?"  Some applications/dashboards require real-time updates while others might be monthly updates.  This makes a huge different when determining the technology required to enable the data management/storage.

View layout and interaction

Let's consider two contrasting situations which require two different type of attention:
Divided Attention Situation: You're driving down the highway going 45 mph and you see a billboard.  The billboard has a picture and maybe some text in huge font size.

Sustained Attention Situation: You're sitting at a coffee shop reading your favorite financial analysis magazine.  The magazine is full of three column small-font text articles which surround graphs and charts supporting the text.

These two situations point out that the users or consumers of your application have an inherent context which needs to be considered.  The speed in which they expect to consume the data/tool.  The amount of time they are willing (or able) to invest in the tool to answer whatever question they're need to answer.  The type of attention (i.e. sustained, selective, alternating, or divided) they are willing (or able) to engage.


Another important area to consider when thinking about layout is how relevant or important data is relative to each other.  For example, for a dashboard, you might place the aggregate results at the top of the page while having the detailed breakdowns as expanding sections below.  The expanding interaction helps keep the entire page clean while still serving the potentially smaller number of users/consumers which need the really fine detail.  Of course, if you determine that most of your users needed the detail, you would define the layout different and determine which of the details were most important.

The bottom line

There's more data and more questions than we, as knowledge workers, know how to deal with at once.  By understanding the context of our role, what questions are most important to our success, what data we have access to, we can determine how to build a view (or interface) which helps us find insight or become more productive.

If you have some tough questions and lot's of data, let us know by registering for a free Cloud Analysis Consultation.  We love interesting problems!
 


Comments


Your comment will be posted after it is approved.


Leave a Reply