EXPEDIA GROUP TECHNOLOGY — DATA
Rethinking Data Visualization
Lessons learned from product development
At the end of last year, I had the opportunity to present at Data Viz Live and the CDAO Europe conferences, where I shared some thoughts on using lessons from Design Thinking and applying them to data visualization. I believe that by making use of Design Thinking methods we can improve the way we build visualisation products. This blog aims to cover the content of those talks.
The problem of today
The monetization of analytics has been around for a long time with companies built around providing key insights to allow their customers to make better decisions. However, in a traditional setting data visualization is rarely looked at as a product. Data visualization is often looked at as reporting. Reports get created month after month, or sometimes a dashboard gets created and shared with users only to have it be replaced by something else soon after. Over the years, I have seen a common pattern that looks like the image below.
A new report gets created, and after an initial engagement a new feature or a change request results in the creation of yet another new report, leading to a lack of engagement with the first report created. This pattern gets repeated for months and years, leaving users confused by the apparent duplication of reports that are strikingly similar with only a few differences. Leading to the predictable results of confusion and distrust in the data being presented. Invariably, decision-making becomes slower and inaccurate. In addition, the reporting platform becomes cluttered with old and unused reports which will cost you time and money.
I believe there’s a better way!
Design Thinking
Data visualization has at times siloed itself and there are few examples of looking across industries to improve the efficiency of data visualization. There’s no denying that research exists, in areas that focus on colour perception and pre-attentive attributes for instance, but we don’t often look across for patterns that can be used in our field. Within the data visualisation team at Expedia Group, we have started to look at product development practices in order to build better data visualization products. I believe that by learning from other disciplines we can improve the way we create data visualization products that last and are continuously updated to meet our user's needs.
“Build less, build better”
Starting by defining Design Thinking, Wikipedia tells us that:
“Design thinking refers to the cognitive, strategic, and practical processes by which design concepts (proposals for products, buildings, machines, communications, etc.) are developed. Many of the key concepts and aspects of design thinking have been identified through studies, across different design domains, of design cognition and design activity in both laboratory and natural contexts.”
Design thinking is focused on the user, always. It is an iterative process that relies on trial and error. In opposition to business thinking that relies on what users say, it relies on what users do, their actual experience, through direct observation and usability testing. Business thinking often relies on innovation by relying on market analysis and aggregate consumer behaviour, whereas design thinking continues to rely on direct observation. In design thinking a product is never finished; it is continuously improved based on feedback gathered from user patterns.
The method
Stanford University has defined the various stages of design thinking as follows and we will use them to guide our process of developing a data visualisation product.
At the same time, part of a successful product is to define your vision and strategy for your product. How are vision and strategy related to each other? Vision is the why of the product. “Why do we want to create a new product?” Strategy on the other hand is the how. “How will we get to our why, and achieve our vision?” Expedia Group for instance has a very simple vision. “Our purpose is to bring the world within reach.” We do that by providing our customers with the tools to book their dream vacations, from booking their hotel or vacation rental, to hiring a car or booking an aeroplane seat. This same process applies to all products that we build, big or small. Spending time on vision creation is a worthwhile pursuit because this phase sets the stage for the success of a product.
Empathise
Empathise is the first stage of the Design Thinking process, its goal is to gain an understanding of the problem ahead. An understanding of our audience. Often this will involve collaboration with the users, researching through observation, experiences, and their motivations. When possible immersing ourselves in the problem often leads to a better understanding of the issues faced. Building a data visualization product always starts with a list of questions from the people that will be using it. If someone is actively exploring and analyzing data, they will have a question in mind that they want to answer. Our job as data designers is to anticipate these questions and provide intuitive, user-friendly ways to find the answers in a dataset.
A common way to do that may be to use the 5 why’s technique. This technique pioneered by Sakichi Toyoda in the 1930s aims to find the root of the problem by asking why 5 times. Its purpose is to go beyond what we think may be the root cause but dig deep into the problem. I have used below an illustration of this technique to what may be a relatable question. Imagine if someone says “I want to work from home.”, to better understand the person's motivations we would ask why 5 times.
As you can see from the above example, the initial responses are certainly valid, but they don’t address the root cause. By continuously probing we get to the root cause.
Another important tool that we may use to better understand our audience is a theory of consumer action called Jobs to be Done (JTBD). It essentially describes the way consumers adopt a new product or innovation. The theory states that markets grow, evolve, and renew whenever customers have a Job to be Done, and then buy a product to complete it (get the Job Done). This makes a Job to be Done a process: it starts, it runs, and it ends. A Job to be Done is the process a consumer goes through whenever they aim to change their existing life-situation into a preferred one, but cannot because there are constraints that stop them. With JTBD, you can think of data as something that helps people accomplish tasks or take action.
Finally, one of the typical mistakes that designers make when working on data visualizations is focusing too much on creating beautiful visuals, instead of concentrating on communicating the message. Data visualization is a lot more than beautiful visuals; it’s about a thorough understanding of the target audience and their needs and finding the best way to communicate valuable information to them.
Define
During this phase, we analyze all the information gathered during our Empathise phase. We aim to pinpoint exactly what is the problem that our users face.
“Always design a thing by considering it in its next larger context. A chair in a room, a room in a house, a house in an environment, an environment in a city plan.” — Eliel Saarinen
Ideate
It is during the ideate phase that the team collaborates on numerous ideas to address the goals of the project. Beyond the opportunity to be creative and bring up loads of ideas, it is important to confirm that key design assumptions are valid. When it comes to ideation a number of techniques can be used — sketching, to help us visualise what aspects of the design will look like, or storyboarding, helping us understand the main interactions of the users with our product.
A good user experience includes prototyping during the design process. A prototype is an experimental model of an idea that enables us to test it before building the full solution. A prototype often starts small, with the team designing a few core areas of the product and grows in breadth and depth over multiple iterations as other areas are developed. When it comes to prototyping, efficiency is vital. One of the most efficient prototyping processes is rapid prototyping. The process of rapid prototyping can be presented as a cycle with three stages:
Prototyping
Creating a solution that can be reviewed and tested.
Reviewing
Giving our prototype to users and stakeholders and gathering feedback that helps us understand what’s working well and what isn’t.
Refining
Based on feedback, identify areas that need to be refined or clarified. The list of refinements will form the scope of work for our next iteration.
While we work on prototypes this question is likely to come up. Does form follow function, or does function follow form? Of course, it’s a never-ending discussion, just like what came first, the chicken or the egg? What we know is that both elements must be effective for the product to be effective. There is a need for data visualisation practitioners to understand both areas of the balance and know how much is too much when it comes to stretching the limits.
Review
As we create our prototypes, they may be shared and tested with the team and the core set of stakeholders that have helped during the empathise phase. The goal here is to identify the best possible solution for each of the problems identified during the earlier phases. After reviewing, we should have a better idea of the issues and problems with our product, but also have a better understanding of how real users will interact with the product. The way to conduct these reviews may involve a feedback session, where we invite users to use the product and provide candid feedback. Giving and receiving feedback is hard, particularly for the developers who may have spent days and weeks working on the product.
Below are some suggestions to consider when running feedback sessions:
- Everyone is equal — Regardless of hierarchy, every opinion gets consideration.
- Be visual — When trying to convey an idea, use a whiteboard, drawings, and other visual explanations.
- Be mindful — Respecting the efforts of others is important. Developers are likely to have spent a long time working on a product.
- Be specific — Avoid vague statements. Provide details so that developers can make informed changes to the product.
- Build on feedback — Build upon the ideas circulating in the room. Collaboration breeds innovation.
- Don’t take it personally — A tip for developers: it’s easy to take it personally when someone provides a critique of our work. Aim to be objective, and take time to evaluate the user's point of view.
Test
As our product gets developed we enter the testing phase. This phase helps our product team ensure the design concept works as we expect it. According to the Nielsen Norman Group, if you want to select just one type of user research for your project, it should be qualitative usability testing. The basic idea behind a usability test is to check whether the design of a product works well with the target users. The primary goal of this user experience testing method is to identify usability problems, collect qualitative data, and determine the participants’ overall satisfaction with the product. Gathering and analyzing verbal and non-verbal feedback from the user helps a product team create a better user experience.
A typical way to gather this feedback is through a pilot that may last from a few days to a few weeks depending on your needs. Inviting a subset of users to test the product but being careful to gather the context around the usage of the product. This may be done by asking a series of questions such as:
- What browser were you using?
- What tasks did you hope to achieve?
- Did something frustrate you or did not work?
Remember:
Even negative feedback is extremely valuable.
Issues can be found with browsers, fonts, and a myriad of other issues that impact negatively the user experience.
Implement
Just because a product officially launches doesn’t mean product design is over. In fact, product design is an ongoing process that continues for as long as a product’s in use. We will learn and continue to improve the product. Often times I have seen teams releasing a product and not working through a release cycle that includes sharing with others that our product is now ready.
It’s as if our new product was a restaurant…we dream of busy tables and the noise of customers and tills ringing. However…..
our restaurant is empty and silent because no one knows it exists.
We forget to engage with your communications team or internal marketing and forget to tell others that the product that they wanted is available. Don’t neglect this step, it’s easy to think that without promoting… ”they will come”. We are all busy, miss emails and announcements. Engaging with internal marketing will be key to your success, engage early to allow them the time to create a solid communications plan. They can help us to create a definite idea of what channels and tools we are going to use to promote it to the users. Some things that are useful to think about are newsletters, key areas on your own internal communication tool, a showcase in key divisional meetings, and other suitable forums.
Analytics on analytics
Much like any other online product we keep an eye on our usage patterns for the products we build. Taking into account, the time spent on the product, how many pages, and where possible the device used to better understand our real audience. Most visualisation tools these days allow a degree of analysis on usage patterns and they can be quite valuable.
Feedback From Users
The best way to avoid having to rework a product is to inject feedback into the process. Regular user feedback (in the form of online surveys or analysis of customer support tickets) should be at the heart of the product design process. This information will drive product refinement.
Don’t hide the “Leave feedback” option. Make it easy and, if possible, rewarding for users to share their feelings and ideas about your product. All our recent products have a feedback button that is available at any point within the product, it allows users to provide immediate feedback and our team the ability to address any issues that may occur.
Testing changes in design
An A/B test is an appropriate testing method when designers are struggling to choose between two competing elements. This testing method consists of showing one of two versions randomly to an equal number of users and then analyzing the data to see which version accomplished the specific goal more efficiently.
Knowing that all of your changes will be A/B tested gives us a tremendous amount of freedom to try new (and potentially risky) things. We won’t have to worry that some change we implement may break the whole product.
As you’ve seen, creating engaging long-lasting visualisation products is much more than pretty charts or even just focused on the analysis. It requires constant collaboration with other teams, the users, the developers, stakeholders, testers, communications, with the ultimate goal to help users get answers to their questions and hopefully foster new ones that lead to the business decisions of tomorrow.
Good product design, starts with your audience
Sources:
- Interaction Design Foundation
- Career Foundry
- Harvard Business School
- Adobe XD
- DMI
- All imagery sourced from Adobe Stock under License
