Using Real Data To Get Real Results

Designing without a good representation of real data is like solving a complex puzzle without a clue. One would spend more time finding the clues than they would piecing them together to solve the puzzle. When I say "real data", what exactly do I mean? In my time designing interfaces I have encountered three types of data (1) fake data, (2) real-fake data and (3) real data. What I want to offer are three reasons why real data, option 3, will help get to better design solutions faster.

Defining the terms

Fake data is essentially lorem ipsum. It's greeking. Designer hooey. It may have letters, spaces, pauses and the somewhat natural flow of language, but it has no context and does not set a real mental model. However, it can be suitable for fast and loose sketching to get an idea across.

Real-fake data takes fake data to the next level by giving it shape and is hard-coded but can be easily served by the backend and replaced with real data when ready. This data is at best an assumption but is modeled after what is believed to be the real shape of the data. This type of data can start to make the interface look more realistic because it has some context. For example, if this is health data then it may have last name first and first name last. However, it still leaves out those fine details that aren't important enough to attack in the beginning but are big problems as soon as it's launched as a real instance.

Real data is beautiful. It's backed by an API and is flowing and updating as if it was in a production environment. It has missing information. It has empty states. It has positive data and negative data. It has a shape that isn't mocked up by those creating the software. It is the total package and throws curve balls at all of the designers and engineers as it rears its multifaceted head.

The way real data will help create better design solutions faster

Content should drive design, not the other way around

1. The challenge here is that content is hard to wrangle in the early phases of the project. Will the content length always be one word? Does this title require a description? How many places after the decimal do we need? With that said, we are usually left with building out the design pieces even before we have an accurate look at the data which will be presented.
   
2. As a solution, we can start to minimize this by having a content strategy earlier on in the process. Like design sprints, or Sprint 0, a content pass would be well received here. This is where an individual would be shaking down the stakeholders and the database gatekeepers to uncover real data. Even if you aren't able to have that flow through a pipeline to the interface, at least you start to build models of real data to design from.
   
3. The outcome of the content strategy really is a better understanding of the shape of data and any outlier data that will need to be addressed in the future. This content strategy pass will also help the design team feel more confident in the layouts and interface structures that they put forth. The earlier we are reducing risk, the better.

Building appropriate mental models requires the appropriate information

1. The challenge here is defining the mental model. But once that has been done through a content strategy and other efforts you can start to promote that mental model throughout the lifecycle of the product.
   
2. The solution to building the mental model is truly an exercise in taxonomy. You know, relationships, classifications and organization. When pieces of content can be thought of as groups then one can start to organize those groups in meaningful ways. When information is grouped, organizing it in the user interface is much easier and should result in a more usable experience.
   
3. The outcome of a defined mental model is the ability to cover as much ground on the product interface as possible with intuitive and repeatable patterns.

Cover edge cases that can immobilize a user

1. The challenge here is that we spend most of our time on the meat of the application which of course makes sense. Depending on your products needs however, this could give 80% of your users a mediocre experience and the other 20% a completely non-existent set of functionality.
   
2. The solution here is to lean on your repeatable patterns which are based on real data. Then to cover edge cases which you know exist from the content strategy portion of the show.
   
3. The outcome of having solid repeatable patterns is that you can now focus earlier on some edge cases that don't seem critical at the first point in time but become real show stoppers once sent off to a production environment.

One test of design mastery isn't how much you can add to affect a product but how little you can do to positively impact an experience in a big way. Working with your team early to gather the realest representation of data is the first clue to solving that complex puzzle and to getting better solutions faster.