data science and design: finding solutions that work

(by Eric)

In my last post, I described my working environment at Johnson & Johnson and touched on some of my work. This time, I'll reflect on some lessons I have learned over the summer. Along the way, you'll hear about the types of projects you might tackle and the kinds of challenges you might encounter.

Understanding the needs of the user

One thing that surprised me is that Data Science projects don't just rely on ideas from Computer Science, Statistics, or Machine Learning. There are really important human-centered considerations that often go under-appreciated and under-explored. For example, in my projects, I would perform the initial data exploration, run the algorithms to extract useful patterns from the data, and arrive on a viable solution for the problem at hand.

I needed, first and foremost, to focus on empathizing with the people for whom I was solving the problem

All well and good – in total, this would take at least 1-2 weeks to get right. However, my work didn't end there. It then became my responsibility to present the results. I can imagine what you might be thinking now – spin up a PowerPoint slide deck, drop in some nice graphs from Excel, and let it rip, right? Wrong. Turns out, it wasn't enough to be a confident and clear speaker. It wasn't even enough to be skilled at constructing pretty PowerPoint slide decks and Excel charts. What I needed to focus on above all was to get into the heads of the people for whom I was solving the problem.

That way, I could understand what they wanted, which meant I could tell a compelling story (using PPT and Excel) of how the proposed solution worked and how it would positively affect the business, the clients, and the end users. That's what mattered and what the work needed to address.

On the Data Science side, while it was somewhat important to spend time looking for the best possible machine learning architecture, for ex. tuning the set of learning hyper-parameters, and eking out as high as possible a test dataset accuracy rate, these efforts were all wasted in the end if I couldn't get the people I was presenting to to appreciate the usefulness of my work or sell them on the idea of using my proposed solution.

While it is important to look for the best possible technical solution, the efforts are wasted if you cannot convince people on the usefulness of your work

That nearly happened on one of my projects; I spent 3 weeks with another intern building a usable prototype for automatic customer complaint labeling, only to find out at the end of the project, when we demonstrated our final proposal for the business users, that what we presented didn't address the exact problem they thought we were going to solve. It turned out this error was caused by some fuzzy definitions in the project requirements, as well as some unintended miscommunication between our Data Science group and the business users who commissioned the work. Luckily, our project leaders were able to smooth things over and we satisfied the business users by spending additional time adjusting our solution to their expectations. That experience taught me valuable lessons in project management that I definitely won't forget in the future when I get to be the one leading.


Data Science isn't just for mathematicians

On that same topic of Human-centered considerations, you might be surprised to know that there is a place in Data Science for those interested in Design and Human-Computer Interaction. Another intern in the Data Science group was majoring in that field at Carnegie Mellon. One of her projects involved working with two other Data Science interns to design an “intelligent” (in the Artificial Intelligence sense) app for use by certain J&J customers. For that project, she choose to work at two J&J-owned locations; on some days, she would be located with the Data Science group in NJ, while on other days, she would commute to a J&J Design studio in NYC. During that time, she acted as the unofficial liaison between the Data Science group and the Design group, coordinating efforts and making sure nothing was lost in translation in the flurry of work emails. Her work on that project included mocking up color schemes and data visualizations and designing the user experience for that app. Pretty interesting and thought-intensive work, from what I could see, and quite a contrast from what I was doing.

As for the other interns on that same project, one was studying Epidemiology and another Finance. Not the backgrounds you might expect from a Data Science team, but they were doing impressive work as well. To give you a taste, their work involved designing and building the behind-the-scenes structure of the app previously mentioned – setting up a database scheme to store data gathered from app users; customizing a publicly available AI engine for the needs of the app; and writing the overarching logic that would combine the user interface, AI engine, and storage database into a seamless user experience. By the end of the project, they had not only built the framework of the app, but also created a completely functioning prototype that you could download and try out on your own phone. Isn't that something?


Learning never ends

I'm going to finish up this post by briefly mentioning my other summer projects and highlighting the most salient lessons from these experiences.

The first project I completed during my internship was purely statistical in nature. It involved finding patterns in medical device sensor data that would forewarn of impending device failure and shutdown, events that if left unchecked would require maintenance calls costing millions of dollars in total. For that project, I processed data and fit statistical models in R and visualized results in Tableau. Ultimately, I showed that anomalous measurements from very specific sensors would predict failure at least a day in advance. During the project, I first learned how to use Tableau to visualize data and create easy to understand dashboards for presentations.

The third project (the automatic customer complaint labeling project was my second), which is still ongoing, involved designing a general framework for analyzing and visualizing the behavior of product quality metrics across US for the J&J enterprise. Once completed, this framework would be used to predict and prevent future product quality problems, recalls, shortages, and costly government sanctions. If anything, this project's lessons built on the previous one's.

It is important to start somewhere, anywhere, so that one wouldn’t get stuck in the weeds of over-analyzing solutions

One of our working group's major challenges was figuring out what exactly the requirements and expectations of the business users were so that we could translate them into a solution design. For a problem with such a broad scope, it turned out to be very difficult! Various business users affected by the project, each had their own vision of what kind of analysis we should do and what the final product should look like. Finally, for the sake of simplicity, we decided to build a prototype that would incorporate specific convenient features and definitions and then modify it in the future according to user feedback. For me, that was a lesson in the importance of starting somewhere, anywhere, even if it wasn't the perfect place, so that one wouldn't get stuck in the weeds of analyzing and over-analyzing every possible solution.

Well, that's all I have for now. Hope you enjoyed! For my last post of the summer, I'll concentrate on life at J&J besides work and mention some things you might look forward to if you get to work here. Stay tuned!