February 12, 2020

How design can help you understand the quality of your data

Emily Blandford

Data is a huge part of everyday life and governs a large amount of our decision-making ability, particularly within financial services which are, essentially, data businesses. But to do this effectively we must trust that the data we’re basing these decisions on is accurate and up to date. Improving data quality is, as you can imagine, no small feat. To prioritise ways to tackle it and where to start, we first need a good view of the problem – so we set out to visualise data quality.

You may already have a strong use case for starting the journey of improving data quality. For example, wanting to ‘spring clean’ your data before migrating to a new system or as a result of landscape-changing regulation changes, such as the widespread adjustments that have been required post-GDPR.

Through incorporating design as an integral element in your data journey, it can actually be used as a tool to improve data quality. 

 

What’s design got to do, got to do with it? 

The product of design is (usually) something visual – a wireframe for a dashboard for example – but the process of design goes much deeper than this. It’s this depth that enables a visualisation to be functional and useful. Design is observing and listening to stakeholders and users to understand what they need. It’s ignoring some of the things they say they want and explaining why those things are distractions. It’s sketching out ideas and discussing them widely to make sure you’ve understood the unique situation of that client before you spend ages in development. It’s harnessing principles of perception, being aware of the effect of users’ predictable irrationality, and understanding the limitations posed by technology and time. It is not really about aesthetics. 

Following this process enables us to understand your motivations for wanting to view the quality of your data and have an idea of who will be involved in decision-making or taking action. With this we know which metrics to draw focus to, and the level of information required by the proposed primary users. We’ll have a better view of your context and how you’re accustomed to accessing information about your data, and can more easily fit within your existing workflow. 

 

Design process and principles 

 

Talking to stakeholders and users

Others in the project team will be doing this already – as consultants, that’s our job – but it’s important for designers to get as much first-hand information as possible before jumping to conclusions on what makes a good visualisation. 

Maybe you already have an established way of visualising your data quality and this project is to provide a new angle or focus on a specific issue. Or maybe you’ve never visualised data quality in this way before and are not certain of the best way to get the information you need. Perhaps you’re setting up a new way of working within your team and are bringing together people with different skill sets for the first time. This is all useful information for us. 

For us to be able to design well, we need to know who needs access to the information and why – what they will do once they have the information. How often they need to access the information. What circumstances they’ll need it in – to discuss within a meeting or review individually in their own time. How they currently work. And many other questions that may be unique to your context.

 

Ignoring (some of) what stakeholders want

You might have a really clear idea of what you want to see and simply lack the time or technology to implement it yourself. Of course, you are the subject matter expert and know a lot more about what you’re asking for than we do. But if we only listen to what you tell us and don’t dig deeper then we’re both missing an opportunity to uncover something you might not have considered, and as a designer, we have our hands tied in what we can work with. So expect us to ask you why you want to see it that way (we’ll do this a lot). 

We also need to be conscious not to design for just a small number of individuals. We all have our preferences for chart types and colours, but to make a visualisation that will last beyond changes in taste and personnel we need to remain neutral and stick to widely accepted standards. A particular fondness or dislike for a certain colour can hamper a visualisation’s ability to communicate information effectively. Acquiescing to someone’s desire to see everything at once on one screen can make it hard for other users to know where to start and they may abandon their search for information before they’ve begun. In these situations, a designer will explain why that may not be the best option, and offer alternatives for discussion.

Information design principles such as use of white space, reducing information overload and balancing graphic and text elements are all used to ensure that data is presented in the clearest way possible. 

 

Sketching out ideas

Putting pen to paper is a great way to start linking ideas together. Underlying any visualisation is the desire to link one concept to another in a meaningful way and to show it in a manner that requires the least explanation. Here we want to fail fast. So we’ll sketch out some ideas and show them to someone who understands the context to judge their response. We’ll ditch the ones that didn’t work and try again – at Mudano, our iterative principles of ‘start now and prototype’ run through everything that we do.

We also take a highly collaborative approach and work with subject matter experts to get it right. Eventually, we have a concept that we think works well enough, and we’ll show you a rough digital sketch (unfortunately not all designers are blessed with great artistry). We want you to poke holes in this. Be brutal. If it doesn’t work it’s absolutely fine for us to start again. The important thing is that we are heading in the right direction to ultimately be able to help you find the information you need.

 

Understanding the situation

 

Fortunately, for data quality projects, the options are usually fairly simple. 

Data quality information has two main metrics: data fields, and rules that decide whether or not those fields are filled acceptably. There may be thousands of rules and millions of fields but the premise for displaying information about quality is either neutral (i.e. no data quality issues) or some degree of bad. Within this, there are numerous ways to break down the data, which will largely depend on your priorities and the ways you intend to use the data. For example, in response to a regulation, you may wish to focus on certain fields and ignore others, for a migration you may want to centre on the data held within only one system at a time, in a study of form completion a rule such as “is blank” may be very important in one context but irrelevant in another and so on.

You might have a good understanding of your current situation but want to see progress as changes happen so that you can quickly understand what mitigation works well and what doesn’t. Perhaps you have a regular meeting about data quality and the visualisation needs to support a specific decision-making process. You may even want to use it to check the quality of the rules you’ve created. Though we would design for the primary purpose initially, we would endeavour to create a visualisation that is flexible enough to allow you to focus on any one of these or other potential contexts at any time. 

 

Harnessing principles of perception

There are several ways to draw attention to yourself: shout loudest, be different, stand apart from the crowd, take a prominent position. Design is no different. Once we’ve worked out what the most important piece of information is, we draw attention to it through, among other things, size and colour, limiting variety to create a visual hierarchy, using spacing and grouping wisely, and positioning items intentionally on a screen. 

 

The bit of information you want to draw attention to will be bigger, brighter or darker than the rest – save your most eye-catching colour for the areas with most DQ issues, in Western contexts this would usually be red. We allow other things to recede by keeping them neutral in colour – this contrast draws the main points out more clearly. We group things to imply similarity and separate them if they should be considered individually. We put the charts showing the main information in the centre, or top left, and position supporting information to the right and bottom of the screen, following norms of how people approach fresh information from eye-tracking on websites to established book layout principles. 

 

It can be easy to overload a screen with information and it’s our job as designers to help you consciously separate content to create a meaningful hierarchy of information. We plan to let users make choices to define what they want to see using filters and drill-down functionality, to allow them to view any degree of detail from overview statistics to the results of a specific rule in a single field in one dataset. Giving the user control over what they see is one of the ways that we can help them to feel at ease with the visualisation and the data. 

 

Working within limitations

If we only follow the process to this point we might end up with the most well-thought-out set of wireframes in the world. It’s pure theory until we’re able to plug your data into a system that can produce a visualisation to the design we’ve been working on. 

Enter: the team.

To be honest they’ve always been here, guiding the design process and working on the data. They’ve been researching your system and know their software inside out. They’ll tell us when a sunburst chart is nice but not quite feasible in the short weeks they have to build and test it (though we might push them a bit, to keep them on their toes). Just as they take our lead on design, we take theirs on implementation, so even though we may have picked up a good understanding of generally what’s possible, we always check with the pros. 

The system does not work unless it is a collaborative one and our ‘champion one another’ value definitely comes to the forefront when multi-functional teams are involved. Our design work isn’t done yet though. There will often be additional information that comes up as the project develops, or unforeseen barriers to creating the visualisation as planned, so we stay close with the team to react appropriately to these while keeping true to the reasons behind the design choices we made. Our role changes to a more advisory one until the dashboard is handed over to you.

 

Data quality and design 

By the end of the project, you’ll have a tool that visualises your data quality in a way that best suits your needs. One that allows you to take appropriate action to resolve existing issues, change processes to avoid similar quality issues in future, and consider how your systems and technology can be improved to support these efforts. 

Design runs through many of the projects that we deliver and is an integral part of what makes us different.

 

This site uses cookies and by using this site you are consenting to this. Find out why we use cookies and manage your settings here.