A novel public health resourcegoogle.org
A novel public health resourcegoogle.org
A few intrepid engineers at Google.org (Jeremy Ginsberg, Matt Mohebbi, and later Vikram Sahai and Rajan Patel) took on one of the organization’s first missions: Could infectious disease outbreaks be predicted and prevented, by using novel surveillance methods, like aggregated search patterns? The result was a novel technology that produces good estimates of official flu activity indicators in dozens of countries. I was lucky enough to be the team’s designer. (P.S. Vikram shepherded a similar technology for tracking dengue activity.)
Google Flu Trends has been cited, reported on, and analyzed tens of thousands of times by researchers, public health officials, media, computer scientists, and designers around the world. The design challenge was primarily one of communicating unfamiliar data to several audiences, all of whom needed to be satisfied by a fairly universal design—a design, mind you, whose language was highly structured by the Google voice. One clever part of the design is the disease activity curve. Since flu is seasonal, what’s notable is how different the flu season is this year compared to previous years. The best view on that is to stack or layer the seasons—in this case, they recede into the past with lighter, thinner lines, like faded memories.
I was brought to the team when they had a working technology but no idea what the product might look like. I conceived of its design, helped implement it, and stayed with the team through the addition of new kinds of data, countries and regions, and (unfortunately) never-released improvements and new projects.
Like many of my projects at Google and Google.org, we produced Flu Trends on the cusp of major technological and design changes. It looks old-fashioned (it is), and I wish we could have easily included some of our planned designs—such as animation, which shows amazing geographic trends in influenza activity. Also, though I’m not afraid to be anti-Tufte, there are plenty of tradeoffs in the visualizations we chose and I would probably change some of my decicions were I to tackle this again today.
A small team at Google.org hatched an ambitious plan to organize the world’s meteorological data (and others) and develop an application-authoring environment to help organizations translate science into practice for climate change adaptation. We collaborated with climate and agriculture scientists doing incredible work to help the world undertand and deal with climate change. Our project ultimately didn’t proceed at the scale we wanted, but did demonstrate some of the power of technology and design to build software to respond to climate change.
Unfortunately I can’t show you much of what we worked on. However, I can tell you about one or two cool things. We designed sophisticated user interfaces to search and visualize vast quantities of both historic and modeled climatological data from heterogenous sources, and novel modeling interfaces—including one that allowed exploration of scenarios in a way similar to Photoshop’s Variations tool. To varying degrees of completeness, flows, frameworks, and user interfaces were created for everything from massively collaborative data collection, scientific application authoring, consumer search of weather and climate data, generalized geographic model exploration, and more.
I was the sole designer on the project, bridging the scientific, technological, and user experience dimensions of everything we worked on, in collaboration with Dr. Amy Luers and Lacy Caruthers. I facilitated workshops with climate scientists, was part of a team who conducted field research in South Africa, Malawi, Uganda, and Kenya, and passionately advocated for the project internally at Google.org.
This was a challenging project—important, requiring lots of learning, and a determination to try, even if it meant failure. In retrospect, I wish I had fostered more community both inside and outside Google.org to support our work. I also wish I had coded more at the time, and developed working sample applications or prototypes. Nothing speaks like a real prototype.