Here's How to Get Started Designing With Data
You might think the first thing data scientists do on a project is grab a bucket of data and run with it. And for good reason—that’s how many data scientists write about projects after the fact. But in practice, when we’re making something genuinely new, we often don’t have data to begin with, nor do we even know what kind of data we will need. We’re staring at a blank canvas, so the only way to dive in is to listen, observe, and sketch.
On my first project at IDEO (and one of the first projects at IDEO where data science played a central role), my team and I had the ambitious goal of creating a personalized service to help people manage a chronic health problem by connecting them with experts on their condition. Our team came up with a nearly infinite number of ideas for how data could be used to personalize the service and offer better support to patients and experts. As a data scientist on the team, my goal was to make these ideas real so that we could quickly figure out whether we’re on the right track.
Making ideas real didn’t just mean collecting biometrics about patients and displaying the data in a smart way. It was much more important to use data to help experts and patients build and maintain a relationship, track progress, adjust course, and figure out next steps. These elements are all an integral part of how the service operates. And in the process, I came away with a few principles for data scientists to keep in mind when using data as a medium for design.
1. Be part of research
We needed to know what experts ask their patients to help support them in their journey to self-management, and what is reasonable to ask patients for. Is it fair to ask somebody who mainly eats at restaurants to accurately track the micronutrients of everything they eat? Probably not.
It’s critical to understand people’s real needs in their context to understand what data is meaningful and feasible to collect. Qualitative field research is key in the process of developing empathy for those we design for and for getting a feel for what life challenges might get into the way of data collection. Understanding when we can collect data—and when we can’t—provides valuable information.
2. Sketch by hand and share
Informed by research and armed with crayons, we created a variety of data visuals aimed at tracking patient progress in various aspects of their day-to-day lives—basically, sketches of the features that might be helpful. Drawing is much faster than writing code. We made the visuals a prominent part of the project room to serve as a catalyst for brainstorming and discussion with other members of the team who aren’t data scientists. We explored trends of activity and sleep over time, and played around with visual ways to track mood and to inform people of healthier food options without asking them to count calories and micronutrients.
This approach allowed us to make significant progress in two ways. One, showing our sketches to experts allowed us to narrow down which metrics were useful, and to start tracking down potential data sources. Sketching in crayon versus writing in code also helps us fail faster and narrow in on the right questions to ask.
And two, sharing our sketches with the broader team, which included designers from a broad spectrum of disciplines (communication, interaction, research, software, business), made our work more transparent and helped us establish a common language. It also sparked conversations, inspiring us and helping us to gather further feedback.
3. Gather up and agree on all your data
Once we identified useful visuals, algorithms, and interfaces, we began hunting for the data that could fill them in and move us to higher fidelity prototypes. In our case, data included the client’s historical data, simulated data, and team data. We simulated data about meals and snacks and plugged it into publicly available nutritional APIs. This exercise allowed us to identify the types of data that might be suitable as input for these APIs.
We also bought a bunch of trackers for the team to explore ways we might keep tabs on activity, which showed us where a tracker might go wrong (moving your arm in a circle might count as a step, when in actuality you’re not taking a step at all) and narrowed down the types of data that are meaningful to collect (for example, movement vs. steps). By diving in with our own data, we were able to fill our communcation, interaction, and software designers in on how we would approach collecting patient info.
4. Look to the future
As we were exploring data solutions for the various components of this service, we had to keep in mind that design and development take time and resources. For example, tracking micronutrients via nutritional APIs relies heavily on the assumption that patients are willing—or will even remember—to share their meals. In reality, we didn’t know what patients were willing to share about the foods they eat, nor did we know what food-related information experts need to track a patient's progress.
Redirecting the team’s effort to a lower-fidelity solution to track these behaviors (say, allowing patients to share a food journal) can save a lot of time and effort while still informing the future development of the service.
As a data scientist, starting with people and crayons rather than data and a keyboard felt uncomfortable at first, but it made the process of identifying what’s important and doable much more efficient. Making data science a visual part of the project space also helped the data scientists on the team become co-designers from the very beginning—meaning that we could contribute a lot more to the project. Hopefully, the tips above will empower you to do the same.
A big thank you to Mike Stringer for his help shaping this piece.
Get in touch
