Under construction

Ask any charter network how they share data, and inevitably you'll hear tales of Excel spreadsheets passed around over email. On a good day, the recipient of this data will understand what is presented to them, and will be able to engage with the data meaningfully. That is unfortunately not always the case. Sharing data often means that the recipient of that report or data tracker needs to have a lot of context about how to use that information, whether "use" means how they draw conclusions from it, or more literally, what fields they should click, and what the expected outcome of those clicks should be.

Creating a design language for all of the information sharing at a charter school network was not something I initially set out to do. At first, all I was focused on was developing reports and tools that were intuitive and fun to use. Over time, it became abundantly apparent that there should be some unifying vision for how reports and data tools should look when our team was rapidly developing and releasing them to school staff.

One of the first aspects of the design language came from the iconography that was created for the first version of the organization's intranet. Grouping that content together thematically meant that strong, iconographic visuals would be necessary to the intuitive nature of the site. I created an icon set using Google's icon set from back in 2013 (pre-Material Design) as inspiration. The set currently has more than 300 icons, which were core to the app-launcher inspired interface for the intranet. These icons would go on to live in presentations, reports, official documents, and would eventually evolve into the iconography and color palette that drove the layout for all internally developed data tools.

Many of the reports that I designed at first were one-off reports that may need to be updated on a monthly or quarterly basis, but over time, I began to focus more and more of my time on developing tools that schools could use to complete operational tasks on a day to day basis. As I did this, my team began to grow. As each new team member came on board, the number of internally developed tools proliferated, and it became abundantly apparent that we needed some common style guide from which to pull the basic layout of each of these files. While the scope and lead developer of each tool was different, the ultimate goal was the same: produce a series of files that achieve some task across more than 20 school teams. Common layouts would increase data integrity, help to clarify what tools were and why they were necessary, and ideally, would increase the user's ability to analyze and act on data without any additional lift.

The end result of this was the creation of several style guides that outlined not only basics like typographic hierarchy and color formatting, but also how these files should work, including when and how to validate data on forms, how to lay out dashboards, which fields should be editable and which shouldn't, and more. This effectively became a standardized method of building miniature web apps using Google Sheets as an interface.

While spreadsheets are certainly not an enterprise level way to write software, they do make an incredibly powerful, low-cost way to build an interface that a user can interact with quickly and without too much orientation. By standardizing the way that users would import, enter, manipulate, and review data, we dramatically improved the entire network's ability to use data to drive decisionmaking on a day to day basis without incurring the costs of a ton of custom application development from expensive development staff.

This design language would eventually go on to be a fundamental part of the way the network designed more than 40 custom-built tools that spanned a variety of pieces of software, from spreadsheets to data visualizations to full-blown web applications.