Do We Need Human-Centered Design in Data Products?
mins to read
Almost every “serious” product is using data in some way, big, not-so-big, or even smart data. So is it correct to single out some of them as “data products”? Of course, there is no right or wrong answer, but in the context of this article, such division makes sense. Here is how Simon O’Regan, data and design professional, defines them:
Data products are those whose primary objective is to use data to facilitate an end goal.
This definition marks the difference between products that use data and those that are data-focused. Do data design principles apply to the former as well? They are likely to do so, but there are also many nuances to it.
Simon O’Regan states that for data products UX, standard human-centered design principles do not apply. How is that possible? Well, it doesn’t mean that data products live by some completely opposite design rules.
Is human-centered design applicable to data products?
As a design agency, we support human-centered values, but also highly support the tailoring of design to the needs of a specific niche or target audience. There is a common conflict with human-centered design. Designers try hard to make products as easy to use as possible. Clients should be happy, right? But it’s not always the case. Take a look at this design:
There is so much going on: three graphs, numerous indicators, and just many, many numbers. Based on the principles of human-centered design, this dashboard would be considered cluttered and confusing. If it was a dashboard of a fitness tracker app, for instance, showing so much data would be a disaster for usability. Even if a fitness tracker uses lots of data, it wouldn’t show it all on the same screen.
This screen is an oil & gas drilling dashboard. It is used by professionals who need to see all these graphs and numbers to do their job. If a designer hides it behind a drop-down menu (a classic method of human-centered design), users would be annoyed and it would actually worsen user experience. That's why, as a wiseman once said:
There are products that just need complexity, and we have to understand that.
Ihor Bilyi, UI/UX designer at Eleken
At Eleken, we still think that human-centered design goes first, but it should not be used blindly. Both complex and simple designs need to respond to specific user's needs. Here are some examples of each data products’ group (we use the classification by Simon O’Regan).
This one is the most basic treatment of data: it is presented as it is, with almost no processing, prioritization, analysis, or special visualization. To work with this kind of product, a user is expected to have knowledge of working with data.
Raw data needs input from the user, it doesn’t present any ready solutions. Since our persona here has probably worked with massive amounts of data before, the interface can follow the best practices of “raw data” products instead of trying to be intuitively understandable for everybody.
In our practice, we’ve had a case of working with a raw data product. Reform by Slamdata is a “simple” but highly efficient software that processes data from different sources to transform it into different formats, and makes it ready to be processed at the next level: for example, by analysis software.
For this design, we placed many cards on one screen and added a preview of the table below. If it was software for users with different levels of user capacities, so having so much information on one screen might not be the best solution. However, with data products, it works perfectly. The design is still less cluttered than most of the professional software that people are used to.
This type of data product presents data with some added information. An example can be a classic CRM software: a user can see data as they are, or sort them by additional parameters, produced by the software (hot/cold client, e.g.).
The task of the design here is to find the opportunities for the use of this derived data, and show it in a way that is more clear and visually appealing. It is likely that people who would be using this software are not professional data users and therefore need some more intuitive solutions.
This is a screen from our design for Enroly, a student engagement app. It has more functionality than just “derived data”, but the general principles are the same. We try to add some details to the table to improve user experience and make it more convenient than Excel.
At this stage, we can say that the product is even more algorithm-focused than data-focused. At each step further from raw data products, we shift from users’ data manipulation to automatic data processing. Following the same direction, design becomes more user-friendly (broadening the circle of potential users) and visually understandable.
Shazam is an example of an algorithm product where the data and processing are hidden: we give input and receive the result. Yet, algorithm products can look way more complex.
Let’s take a look at an example of an algorithm from Gamaya, an agricultural data analysis platform. Pictures from drones are processed to find the numberof planting gaps. In our design, we visualized gaps right on the map, separated territory into squares, and showed all the data about the selected square: percentage of gaps, sizes.
Gamaya is not solely an algorithm product. It has many functions, data sets, and options for usage. Its job is to collect data from open sources, process it, analyze it, and present it to the user in a way that helps optimize its business. And here we come to the next type.
These products show data, analyze it, and present their analytics. Yet, the decision is to be taken by the user. We have worked with some products of this kind. In the design of decision support products, we focused mainly on the presentation of sets of data to the user, visualizing it in a way that is most comfortable to read, understand, and make those decisions.
Here is a dashboard of Tromzo, a code security app. It gathers data about all the vulnerabilities found in code and shows the situation in each repository, team, and project. We used a big font to make an accent on key numbers, such as new vulnerabilities, and percentage of repositories coverage. Green and red numbers show dynamics compared with the previous week, and the graph shows a general trend.
Like many other products, Tromzo collects data and offers a way to manage it, in this case, set workflows that fix vulnerabilities in code automatically. This is a common thing for many products: they work with data while presenting a solution to a specific problem.
These products require minimum input from the user. You can receive results without having to make any decisions. This is how all the recommendations work on YouTube Music, Netflix, and so on. Users have no impact on suggestions of films or music.
Automated drones also work on the basis of automatically processed data. The range of products can be very different, and so is their design. Compared to raw data products described above, this category would be much easier to use for people of different levels of tech capabilities.
Looking back at our case studies, it seems that as soon as you start analyzing data elements of software, most products appear to be data products. That is why data products are not solely meant for the use of data scientists.
Design solutions presented in this article can be used in different products that use data, as well as in others. Whether we use human-centered principles or not, the most important is to adapt our UX design services for the needs of the product. Contact us to talk about the solution that fits your product best.