How Adopting a Design Mindset Made Me a Better Data Scientist

I passionately believe that everyone is an expert in something. Some develop technical expertise through a graduate program, others gain know-how from participating in an obscure hobby, and some gain intuition from years of on-the-job work experience — and you can learn a lot by finding someone’s area of expertise and asking questions. This is part of why I loved being a Data Scientist in Capital One Labs; learning from others’ expertise was just part of the job.

There is a famous Venn diagram that most Data Scientists have seen before, illustrating data science as a mix of statistics, computer science, and domain expertise. Most Data Scientists — through their education and prior work experience — have beefed up on the circles for statistics and programming skills. But often, Data Scientists don’t start a job with a lot of domain expertise; I sure didn’t know how a financial services company works before joining Capital One.

Capital One is a big company with many parts, and even if a Data Scientist does have previous financial services experience, Capital One addresses many industry challenges in a unique way. Therefore, it’s nearly impossible to be fully prepared with domain expertise in all aspects of our business before diving in as a Data Scientist at Capital One.

Fortunately, there are many subject matter experts within the company (just as I’m sure there are at yours). It might be a Call Center Agent who stands on the front-lines assisting our customers with their banking needs. Maybe it is a business analyst who has prepared an Excel spreadsheet weighing benefits and risks of a new rewards program. Or, it could be an Investigator who works to meticulously identify fraudsters.

I view being a Data Scientist at Capital One as an opportunity to find out what someone is an expert in and learn all about it.

However, I know that while many Data Scientists are well-trained in computer science and statistics, they aren’t always well-trained in having the types of conversations necessary to tap into the domain expertise of these experts.

To truly take advantage of big data and machine learning, large data-driven companies like Capital One need a way to marry the technical skills of their Data Scientists with the subject matter expertise of the entire associate body.

Design Thinking for Data Scientists

Fortunately, there’s a whole group of Capital One associates who are already experts in listening and learning from others. They’re the Designers practicing Design Thinking. Design Thinking originally developed as a methodology to find the latent needs and desires of customers and rapidly prototype and iterate on solutions or new products to help them.

By collaborating, discussing, and training with these Designers, I realized this process has a lot in common with what I do as a Data Scientist when learning from experts. I am trying to identify the latent mental models the experts use to view a particular problem, just like our designers are trying to identify the latent needs and desires of our customers. As a part of this, I generate hypotheses about the world, and confirm or reject them with data, just like our designers prototype and test out new product features. And ultimately, I am translating these hypotheses into features in a computational model — again, just like our designers do when they develop new solutions or products incorporating their successful features.

So, I started a side project with one of our awesome Design Strategists to develop an area of practice around this within Capital One’s Data Science Teams. We called it DT4DS (Design Thinking 4 Data Scientists). First we created a single day Design Thinking training session aimed at Data Scientists. Adapted from the larger trainings our Design Thinking Team had been running, this training could be taught by Data Scientists to other Data Scientists, giving participants hands-on practice interviewing, ideating, and creating hypotheses. Eventually, this led to the development of a three-day workshop that contained some ideating, some interviewing, some unpacking, and some hacking. All of it for Data Scientists, by Data Scientists.

From all of this, we identified two main practices that Designers frequently employ, that our Data Scientists could also use: Ethnographic Research and Hypothesis Generation.

Ethnographic Research

Designers use ethnographic research — the study of people in their own environments — to learn from customers. This involves interview techniques to learn about what customers are thinking, feeling, and doing. Designers also utilize activities, such as drawing, role-playing, and card-sorts that help customers think and express themselves in ways they hadn’t previously considered.

These same techniques that help Designers discover the latent needs of customers can help a Data Scientist understand the cognitive models that a subject matter expert has. Data Scientists can go talk to the Call Center Agent or shadow the Fraud Investigator, spending time watching, learning, and observing in their shoes.

While seemingly simple sounding, there are rigorous standards and processes for all of this. Designers and Data Scientists prepare and practice for this research A LOT. Efficiently and ethically gleaning information from interviews is a skill that can be honed with experience, but can also be improved by using the tried-and-true methods listed above.

When engaging in this type of qualitative research, there are established best practices one should use. For example, Data Scientists should:

• Consciously try to build a rapport with the expert before diving into the content.
• Have a note-taker present to focus on capturing the interview without actively synthesizing the content.
• Ask for specific stories to let the expert explain in their own words what they do, without imposing too many of the Data Scientist’s assumptions.
• Use different forms of communication like asking an expert to draw a complex system or role-playing an interaction with a customer.

This is of course just the tip of the iceberg but goes to show the kinds of structured conversation and observation encouraged in this process.

Hypothesis Generation

Before I dove into Design Thinking, I had never really thought about the process of generating hypotheses. Many projects are based on a Data Scientist’s best guess about how the world functions. They confirm those hypotheses with a combination of data sources, mathematical transformations, and machine learning. But creating these hypotheses is a creative endeavor that often requires the Data Scientist to consider a business problem in a way that is has never been tackled before.

Similarly, Designers use the results of their ethnographic research to generate hypotheses about what product features customers would use before testing them with prototypes. The Designer isn’t going to walk away from a customer with instructions on what to build, but through collaboration and reflection, they can come up with some good guesses.

Similarly, a Call Center Agent may not tell a Data Scientist which data sets to look at, but by obtaining their understanding of why customers call, you can use that information as a guide when building a model.

There are also best practices and tactics employed in generating a hypothesis, such as:

• Using mind-maps -the easily recognizable hub-and-spoke diagrams- as group activities to allow the team to level-set the information they have, ask questions they don’t know the answers to, and draw connections between different parts of the domain.
• Collaboratively sharing-out interviews by recording and organizing individual pieces of information, or data points, on note paper that can be moved into clusters representing different themes and ideas.

These tactics can help Data Scientists get into a space where they are generating hypotheses about the world, and considering the data sources and mathematical transformations necessary to confirm it. This doesn’t mean every hypothesis is worth pursuing, but it can give Data Scientists a starting point for exploring the data.

Design Thinking Your Data

If you are a Data Scientist trying to jump start a new project or eke out a little more accuracy in existing models, think about who may hold valuable domain expertise relevant to your problem or topic. Don’t write them off as non-technical, or eschew their lack of data know-how. After all, you have that side of the equation covered, and their input can be just as valuable.

Instead, think like a Designer. Approach your expert with empathy and give them the space and tools to tell you their story in their own words. Take the time to carefully unpack what they’ve told you and use your own data expertise to identify confirmable hypotheses from the information they have shared.

Design Thinking is transforming the way Capital One designs products for our consumers. I hope I have provided you some ideas to apply that same transformative power to the world of data science!

DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2017 Capital One.

For more on APIs, open source, community events, and developer culture at Capital One, visit DevExchange, our one-stop developer portal.developer.capitalone.com/