Representing Data on the Harbr platform

Martin Yong
5 min readJun 23, 2020

--

There are lots of people doing wonderful things with infographics today. There is both an abundance of compelling data, and designers that are taking an active interest in the space between data and design.

Decisions that are ‘driven by the data’ are felt to be more trustworthy and accurate as data is (supposedly) objective, they contain a kind of ‘truth’. However, neither data, nor its representation is truly objective. The representation of data influences what is communicated and how it is consumed.

Knowing the potential pitfalls of representing data, we at Harbr found ourselves with an interesting and challenging requirement.

The Challenge

Data products

The data platforms we implement for our customers allow the packaging and monetization of data as a product. For organizations within the platform to effectively market their products, we allow data publishers to provide their own icons for data products. However, not all data vendors have this capacity or capability. We wanted to offer publishers a standardized visual representation for their data products. These would be seen on the store and throughout the various features within the platform.

The marketing of data is a fairly new discipline and so we found ourselves with some scope to create our own language. At its very simplest, we could have suggested a purely text-driven interface but this would have been a missed opportunity. By defining for ourselves and for a nascent industry the idea that data can be marketed with beauty and meaning, we can build value for everyone involved.

Here are the specifications we set ourselves:

1. Data driven and automated, so it requires no manual input.

2. Individuality, so no two data product icons can be the same.

3. Flexibility, so can work across all customer ecosystems.

4. Harmony, so can work amongst other client supplied data product icons. Even though they were to be generated for users, we wanted them to be delighted with what we made for them!

5. Variety, so data product icons were distinctive and could easily be navigated. This would need to work with many thousands of products.

6. Scalable, so it worked both large and small.

7. Designed to be replaced. This feature was intended to remove the pressure of adding an icon during the workflow of creating a data product. However if a user wanted to upload an image of their own, we wanted them to feel no hesitation on doing so.

Representation

We also wanted to understand the role of illustration vs. abstraction. Could we create a language where the data could be ‘recognised’ from the icon? Could its subject, scale and quality be understood just by looking at the icon? And would this help users or not? Early on, we experimented with different categories of data being represented by different colours and forms.

Overlapping shapes driven by data, category driven colour gradients, metadata driven position — All too much. Beautiful but complex, and not great UX.

Why this didn’t work.

For a while we were (over)excited about the idea of creating an icon that was imbued with multi dimensions of data, that would help users understand the data better. Testing this notion proved us wrong very quickly. We tried a range of design iterations, but were unsatisfied with all of the outcomes.

Moving visual elements based on the metadata of a product, or choosing colours based on the subject of the data was interesting to us but meant very little to our users.

Also, each customer platform carried data on similar themes so that using the subject of the data to drive representation provided insufficient variety. Many of the icons ended up looking too similar and was not the direction we wanted to go as this

Driven by data, but not illustrating the data.

After a number of design iterations, we found that the most effective approach was to decouple the content of the data from the representation of the data. This seems counter-intuitive in a world where infographics are giving data more visual meaning, however, with our specific UX led case this was the only way to help users navigate quickly to different products. We decoupled the link between data and representation, but did not completely detach the two ideas.

At our heart, Harbr is a data driven company and so we did not want to totally separate the data from its representation.

Every data product has associated metadata (the data about the data). This is not the content of the data itself, but are dimensions of the data like its name, size, type etc.

By using a limited amount of associated metadata from a data product to generate its visual representation we implemented a way of differentiating the icons while still having them driven by the data. Here UX took precedence over ‘illustrating the data’.

We drew from some of a data product’s metadata to create a simple movement of colour. This represents the data on the platform, until the publisher of the data wishes to replace it.

Data products and how they appear on the Store
The metadata of the data product is used to determine the colours and the ‘bias’ of the position — A simplified and elegant representation

Not reinventing the wheel

Our final design can be seen above. It uses the metadata of a data product to define colours and bias of position. It is a simple solution to a very complex problem.

We did need to help users of the platform find the data they needed quickly and easily, but now without using the data product icon. We did this by adding more functionality around the categorization of data. Each platform that we deploy for our customers has the ability to fully customize the categorization and description of the data, as one global set of categories would not fit all applications.

What we learned

  1. The more ‘useful information’ that we the used within the visual representation, the more confusing it got. Once we had decoupled the link between the content of the data and its representation, we were free to concentrate on the UX.
  2. Representation and navigation needed to be separated. We were not designing infographics.
  3. Like good UX, simplicity was the key idea to drive development. Over-complex concepts only obscured what we were trying to achieve.
  4. Only when design and data work together can aesthetic and UX operate in harmony. This task was not purely data driven, nor design driven.

Many thanks to Jonathan Sunderland for the passion, coding, conversations and experiments that helped bring this to life.

--

--