Data Driven Design: A Simple Primer

by on 15th April 2013 with No Comments


Web apps are becoming ever-more prevalent on the internet. Some may argue that they are simply more complicated websites. Regardless of their definition; what happens when you are designing for large amounts of constantly fluctuating data?

There are a few examples of data driven interfaces and they all have to handle a lot of varied data that is constantly changing. The most common are admin areas and analytic dashboards. The data can take many forms; graphs, charts, tables or text. Each can be displayed in a variety of different ways depending on the context and meaning you are trying to convey with the data. One thing to remember is that you can rarely be sure of the length or amount of data you need to cater for; so think simple to start…

Consistency and Predictability

One of the most important aspects of designing heavily data-driven interfaces is to make them consistent. Consistency allows users to familiarise themselves with one area of an interface and be able to use any other area simply by the schemas created with the previous area. This is how you make an interface predictable; play on existing mental models and learned behaviour.

In order to make areas consistent, you need to understand the broader context of the interface and see how well your initial interface ideas can hold up to the scrutiny of varied data.

For example: a table may not need to be filtered or sorted in one view — but what happens when you are presented with another table in a different area? Can you use the same interface you have just created if the second table needs to be filtered and has highlights that require a key or legend?

Consistency is about allowing the design to retrospectively adapt, based on your increasing knowledge of the complexity. This is why it’s best to start with lo-fi prototypes and test your ideas with edge cases (things that won’t occur very often but that might break the design).

Will the table pattern be used in any other areas that may have extra functions? If most tables need to be sorted, then design with that in mind. The aim is not to have to ‘bolt on’ anything to an existing component so that it feels out of place. It is easier to remove a button from a toolbar than it is to figure out how to incorporate it without a toolbar.

Resuable Patterns, States and Components

In order to make consistency a reality, you need to build smart. If not designing for each individual view, you can instead produce a set of rules that can be applied to any view. A paint-by-numbers if you will. This enables your client or other designers to quickly assemble new pages or layouts with minimum fuss.


A pattern is a small set of elements that go together. This could be a section of a toolbar, or maybe a set of rating buttons, and are usually a way of organising connected information. A label and an input would also be a pattern within a form.

Below are some groups of patterns from Google products:

  • Sort dropdown
  • Left and right navigation
  • Date range selector
  • Checkbox Dropdown

The patterns are from different products but are consistent and so are predictable to users. Together they form the toolbar component.


Patterns may have various different visual looks depending on a specific set of circumstances. Maybe there is an error, a button is disabled or a graph has no data. Each need to be considered. Generally they fall into the following categories (some you will recognise from different CSS pseudo selectors):

  • Default
  • Hover
  • Active
  • Focus
  • Error
  • Disabled
  • Empty


A component is larger and can contain multiple patterns or even multiple components. When designing for heavily data driven sites, the aim is to provide a set of flexible components made up of reusable patterns. Below is one for on small screens:


Working From an Existing Product

If you are working from an existing product and are limited by the existing user flows (and in some cases the layout) then you need to conduct a ‘template audit’. List out some key userflows and take a screenshot for each step.

  • On a Mac just press Command-Shift-3 to save the current screen to the desktop.
  • On PC you can use something called Problem Steps Recorder to record your steps into an .mht file. You can then save the images out of that file. There is an excellent tutorial here.

Once you have completed a userflow; add the screenshots to a folder that describes the userflow such as ‘add new record’. Then print them. All. There is something to be said for having every screen involved in a userflow in front of you. You can easily spot similarities and differences.

The idea of a template audit is to understand how many templates there are, how many patterns there are on each template (and what state they are in). The best way to do this is to pin them on the wall in a grid and assign a letter for the columns and a number for the rows (or whatever you are comfortable with). This acts as a reference when you write down each component.

For example you may have:

  • Table Header (A2)
  • Table Body (A2)
  • Table Footer (A2)
  • Side Menu – Closed (A1)
  • Side Menu – Open (B1)
  • Calendar (C3)
  • Calendar – Disabled (C4)

This allows you to list out all the patterns that exist, but also reference them so you can quickly see what they look like. A way to test if you have listed all the patterns and components is to pick a template and see if you can recreate it from the list of patterns and components you have just made. If you come across something that is not on the list; add it.

Working From Scratch

When working from scratch you have the freedom to create any patterns you like but  it can also be a lot harder as you have nothing to go on at the start. As previously stated; when designing reusable components you should start lo-fi with sketches. They don’t have to be amazing but they are quick and allow you to easily explore different options without getting caught up in detail that so often happens in Illustrator or Photoshop.

  1. Create a flow for a task that needs to be completed and list down the content that may be included on the page.
  2. Sketch out some different directions and ideas. The more the better. Then you can start to see if there are any overlaps with the content and how it may be possible to lay it out.
  3. Refine them into wireframes and assess if there are any areas which have similar functions but dissimilar solutions. Consider how they can be combined to make a more consistent interface. What are the patterns that you are using?
  4. Break it. Deliberately play devil’s advocate and see what you have to do to break your interface. Decide whether the breaking action is likely to happen and whether it’s worth addressing.


Iconography is a way of understanding the meaning of content by the use of an image. There are cases where text is better than an icon; usually when the concept is abstract and has a low affordance. Not every action needs an icon.

If you are concerned that users won’t be able to understand an icon. You are probably right. A quick way to test it is to isolate the icon and ask people what they think it does. If they have several guesses and none of them are remotely close then you may have an issue. Sit the icon in context and repeat the process. If the affordance of the context reinforces the correct use of the icon (i.e. people can guess what it does from its position on the interface) then it’s probably ok. If people still can’t guess then consider changing the icon or adding some accompanying text or microcopy.

Progressive Reduction

There is an interesting concept called progressive reduction that can be applied in circumstances where you want to train users that an unusual icon relates to a specific action. By starting with an icon accompanied by text (to make it obvious on first use) and gradually simplifying the interface the more it is used, users begin to associate the icon with an action that would be impossible to guess by just using the icon alone.


Now that you have created some refined wireframes expressing key userflows, encompassing a mass of reusable patterns and components; what do you show the client?

There are a number of caveats that can affect what you deliver, such as if you are doing the HTML / CSS / JS yourself, or whether that is being handled by a third party. In either case, to ensure the longevity of the design and more importantly the consistency as more features are rolled out, you need some sort of reference or guide that anyone can look and (and even update) that is the basis for all future decisions about the interface.

The Kitchen Sink

The Kitchen Sink is HTML / CSS and sometimes JS that shows all the different components and patterns on a single page ensuring that nothing breaks (design or code wise) when they are put in various orders. In it’s simplest form it is just native HTML elements ensuring that the basics are covered.

UI Kits

User Interface Kits are usually static PSDs and contain stylised versions of fundamental html elements. They usually include buttons, inputs, select boxes as well as sliders and datepickers. Some can be very comprehensive and are usually delivered when the build process will be undertaken by a third party. They prevent you from having to produce a mockup of every screen in every state.

Visual Style Guide

Visual style guides go much further than just visual references to a design. They are instructional and often include guidelines for when and where patterns and components should be displayed and in what state. They are best produced in code and can be updated as time goes on.

The key to consistency and keeping that consistency in an expanding, heavily data driven product is having a basis from which all design decisions stem. Having a ‘master copy’ and a set of easy to follow rules means anyone can build (nearly) anything and have it fit in with the existing design.

When you come across something that isn’t included in the style guide, you can create a solution to your problem and add additional elements, patterns or whole components to it with some instructions making it available to everyone.

Style guides are evolutionary and are never finished. Then do need to be maintained though. If not then gradually people will stop using it as it becomes out of date and that is when products begin to diverge.

Remember that you set your clients’ expectations. If you say you are going to deliver pixel perfect mockups then that is what they are going to expect.


Users are task focused and are often on the ‘shortest path to completion’ meaning you need to design for them to complete their task in the best way possible with minimum fuss. Resuable patterns speed this process up by allowing users to use what that have learned from one aspect of your interface and apply it to another. They become fast at completing new tasks because they are more confident of their actions.

A word of caution lest you get swept up in the look of the interface rather than the function; the way something looks is the last thing users care about. So before you rush off into Photoshop remember that first and foremost; users care about whether something works. Consistency and predictability have a huge part to play in this.

Additional Reading



Comments & Discussion

About the Author