 Okay, I feel like I've already accomplished something already. Thank you for some quick Googling there and two other humans to help me. So hi, I'm Amy Cecil. I'm going to talk about why data visualization needs a style guide. This is where you can find me on the Internet with my Twitter handle. Basically I'm a graphic designer. I've worked at the Sunlight Foundation and at the Consumer Financial Protection Bureau where I currently work and I've helped create data visualization style guidelines for both of these organizations. I'll talk through the creation process of both of them. But first, what is a style guide? Design style guidelines or brand standards or an identity manual. For the most part and for the purposes of this talk, these terms can be used interchangeably. And I know some of you know what a style guide is, but for those of you who don't, I'm going to give a few examples and some background. Style guidelines educate people working with the brand on what to do or not do, which keeps the brand consistent. If things are consistent, they signal credibility and trustworthiness. And they're a commitment to produce work of the same quality. Committing to standards helps build and maintain your organization's reputation. For example, looking at Twitter's logo guidelines, they give examples of what not to do with the iconic Twitter bird. Like not to personify it by adding a hat and a bow tie. But having this written down allows them to enforce consistent use of the logo over time and staff changes and to protect their brand integrity. Most guidelines also spec out specific values of colors and typeface weight and size to use. This ensures cohesion between different parts of the organization so that web pages match mobile apps, match brochures and reports and t-shirts. So your brand is instantly recognizable between mediums and uniform. And it allows the brand to be extended into different mediums quickly and with uniformity. Mailchimp takes guidelines a step further and has a content style guide, which provides the goals and tone that all of their content should include, as well as details like specific grammar choices, like use a colon rather than an ellipsis, an m-dash, or a comma to offset a list. This helps ensure that all their products are cohesive and that they seem like they were created by the same person. They even have a voice and tone microsite, which provides specific examples of how and when to use language and it takes into consideration what the user might be feeling. This ensures that the user will have a consistent experience throughout the process and that Mailchimp is meeting their needs at every step. Even the United States Digital Service, USDS, created guidelines for how they design applications and think about products for the American people. Not only does it offer guiding design principles about how users should approach building things, but it also includes templates and UI components that are tested for accessibility. This ensures that people aren't solving the same simple problems, like what a button looks like, again and again, and it frees them up to solve more complex issues. These guidelines can seem very strict, but I think they work better for data visualization when you think of your brand as a family. You know, kind of like the Baldwin brothers. They each have similar visual traits, and you can tell that they're clearly related. But they each have their own unique personality with different quirks, like perfect hair or a quirky sense of humor. I think 538 does a particularly good job of creating a family of charts. Looking through their 2016 yearly review of the 52 best and weirdest charts they made, I was blown away. They all look similar, but they have unique elements to showcase the particular data. You can't tell what programs the graphs were created in, and they don't look like the software or a technology that was used to make them. But rather, they all look like the brand. The visual consistency conveys an attention to detail. That implies that similar care was taken with the data, while the uniqueness of each visual allows a particular point of data to be clear. Looking at the titles of some of these graphs, they each have a uniform, short and catchy title, and a longer but descriptive subtitle. The tone is similar as well as the color, spacing, and typography. And the footer has fairly consistent content, which includes the brand logo and the data source. It adds a layer of transparency and integrity to the graphics. And having these things included in a style guide makes including the contacts for your charts part of the routine production process. It ensures that information isn't left out. And all these charts have similar colors. The pie chart shows the usage of these colors over all of the charts. And they all have a light gray background and generally muted tones with more saturated colors for emphasis. However, there's a large variety of colors that all work well together to create a uniqueness and personality within the family of visualizations. However, your graph shouldn't look exactly the same, like identical twins. This is an old graphic from the Washington Post. And all of these pie charts are basically the same visually except for the numbers. You can't tell which charts are related and it's easy to gloss over all of them because it doesn't highlight the unique and interesting aspects of the data. It all just kind of feels the same. So why does data visualization in particular need a unique style guide? It would be much easier to have just one template and not a whole guide. However, there are so many data visualization programs out there. They each have pros and cons and people have different skill sets of what they're comfortable with. Having just one template for one program limits the organization to be just using that software. It would make it harder to adapt to whatever new crazy cool technology, like beta.plot.dash chart.ly, that slash JS that comes up in the future. You want to design something that can withstand the test of time, or at least last until the next version. If you have guidelines, then no matter what program the visuals are created in, they will look like each other and flow harmoniously in the same post. Even if not all of the software can 100% replicate the style guidelines, working towards the same ideal will help your graphics have more cohesion. So again, why should you have a guide? You want to design for organizations, not software. You want to build templates for common programs that all work towards a common standard that's not dictated by just one program. Make contrast and accessibility easy. If you bake in good standards for accessibility, then all the graphs are more readable by default. Having a data visualization style guide improves ease and speed. It makes it easier to make graphs when you don't have to redesign the wheel every time. It allows staff to have some flexibility and eliminate bottlenecks in the process. Attention to detail. When things are consistent and visually well designed, it can phase in attention to detail that implies that similar care was taken with the data. And you want to know the rules before you break them. Having some education within the guide so that people know why they're doing things. And if they're deviating from the guide, they do it with intentionality. So what in particular should be in a good data visualization style guide? Color, text, tone and layout. So look at how the brand guidelines specifically apply to data visualization. Someone who's creating a chart probably doesn't want to dig through the rest of the standards and take their best guess as if the headline should be an H3 or an H4. You want to set a consistent tone and expectations across all of your graphics. You want to include chart examples. Knowing what things have been done in the past can inform people if they want to do similar or different things in the future. You want to know who's reading your graphs, your target consumers. If you figure out your audience's base knowledge and needs, you can make graphs that work for them. You want to know who's making your graphs, your chart creators. And you want to write a guide for who will be using it and give them the knowledge that they'll need to create charts. And you want to find what works and what doesn't before standardizing it. You want to make sure that you have a solid foundation and a tested style before you go to write standards. So what does putting together a good family of charts look like? This first example is about making a data visualization style guide at the Selmaid Foundation. I worked there in 2013 and it's a non-partisan nonprofit that focuses on open data and government transparency. And at that time, there was about a staff of about 45 people. I knew everyone's name and it was easy to pop by someone's desk and ask them a question or to explain something. The tone of things being created was design heavy. We had several designers at the organization and had a unique visual style. The charts were also data heavy. We had a lot of open data and some of it was really complicated. And we were also doing sophisticated analysis that sometimes required complex visuals. But the data visualizations we were producing were not consistent with that tone. It was either a default ggplot style charts made in R with the logo slapped on them. And these weren't serving the organization's needs. They weren't getting picked up and republished by journalists, which was a big goal for us. Or the logo was being cropped out and we lost any sense of attribution and ownership over them. Or we were creating overly designed infographic style visuals. But they took forever to create and each one was unique and there was a lot of design work associated with them. They were popular on Pinterest, but not very republishable for the inside the beltway audience we were hoping to reach. And they tended to be more number decoration than the complex visuals with explanation language that were sometimes needed to show the depth of the analysis. They didn't look like they were related. They didn't look like part of the same family. So we made some adjustments and found a style that both sides could be happy with. We looked at the target consumers of the data visuals at the organization, which were mainly journalists and researchers. And we took into account the needs of the people who were creating the charts. Researchers who wanted to get things out fairly quickly and be newsworthy but also do in-depth analysis. Graphic designers who still wanted the flexibility to create something unique when a project required it. Developers who had a lot of data and wanted to show it in an interactive exploratory way, but still be on brand. Young journalists who might not have worked much with data before, but sometimes just needed a simple chart to support their story. So what did the data visualization style guide include? It started by setting the tone. It explained that this was just a guide that was a starting point and that you should do what makes sense for the data. And to respect the data as you explore the wonderful but often confusing world of turning numbers into visuals. The guide pulled out specific type styles and how they should be used for data visualization. It included hex, RGB, and CMYK values for brand colors. Each color included a tint and a shade of that tone for groups or stacked bar charts, which came in really handy for easily adding emphasis. There was a separate color for showing no data or null values rather than just ignoring that all together. We went further and we looked at what types of content we were showing. A lot of content dealt with politics, so it made sense to have a separate set of colors for the Republican, Democrat, and independent political parties that worked well together and could be visually separated from the work that focused on non-political things. We had visuals that showed pro-con or positive and negative data. So having a red-ish color and a green-ish color that worked well together, but were still accessible to people with color blindness was important. About one in 12 men of European descent are red-green colorblind. So it's important to build this into our color choices. The green-ish color had some more blue in it, so it was able to be differentiated from the red-ish. Having this check for color blindness built into our guide meant we didn't need to think about testing for color blindness every time we made a new chart. We just knew that these colors worked together. We specced out the basic structure of a graph in a size that would fit nicely on our blog and provided in-depth details, like what the weight and color of the access lines were, and how far from the margins the logo should sit. The developers loved this. They built templates for R and D3, and they didn't have to bug the designers for all the nitty-gritty details. Each of the basic chart types had a page that showed an example of what the chart looks like. It described in bullet points when it should or should not be used, and it showed a small table of what the data should look like to create that chart, which was useful for designers and journalists who might not have had as much data background. And it showed how to label your axes and add a data source. These things are important to remember to maintain the credibility and data integrity. So after socializing the guide within the organization and doing a couple of presentations about what it was and how to use it, this is what our charts look like. We put a lot of effort into getting everyone enthusiastic about using it and explained how much easier and better it would make their work. Overall, the charts are more harmonious. They look like a family, each with their different quirks, but similar genetic makeup. Since there's a solid foundation in place, when creating a chart, people could consistently break the rules in one or two ways, and the chart will still look like part of the same family. It allowed sunlight to make simple graphs more quickly and just more of them, and it allowed real effort to be put into making complex visuals when needed. And from the guide came templates. Ben Shardoff created a GG plot theme for R, which helped the team of researchers get graphics out more quickly. The graphics using this template were about 80% towards the ideal template, so they required less cleanup in Illustrator for the designers, and it allowed the visuals that really showed the uniqueness of the data. And one of the other developers, Bob Lanin, made a D3.js template. It allowed other developers to throw data into it and add the branding color scheme and the branding wrapper, so allowing people to use the tools of their choice that they were comfortable with made it really easy for them to produce publishable work. And it was easy for the designers to have a template in Illustrator, and they could expand to do custom things that required more design work. And it was easy to pull the essence of the style guide into other programs that might be more of a one-off need, like creating network graphs in Gefi. It wasn't a big deal to try new software for only a couple projects. And after all the designers were no longer with the organization, the communication staff still use the essence of the style guide for graphics, which I think makes it successful. I was hired by the Consumer Financial Protection Bureau, which is gonna be the second example of making a data visualization style guide. The CFPB is a US government agency that makes sure banks, lenders, and other financial companies treat consumers fairly. There's about 1,500 staff, which is a far cry from the 45 in a nonprofit. The tone of the design is a focus on plain language and centers on being user-friendly. It's a very clean and simple straightforward brand aesthetic. It's a design goal to give the data a voice and to make numbers digestible and clear. We strive to have honest, transparent design that wins the public's trust. Data visualization was not a part of their design manual when I started, but they wanted it to be. So we kicked off the project with a brainstorm and looked at the data visualization that had been created over the past three or four years. It was a lot of Tableau and Excel charts, some custom graphics and illustrator in D3, but the main visual was lots of brand green and very data heavy. So we also looked at style guidelines from different organizations, like the UK government and things like the data visualization checklist. We dot voted on what types of content we wanted to include and what would be useful to the users of our guide. There's a wide variety of people who create graphics at CFPB. And because of the size of the organization, it's impossible to have close relationships with every one of them. So the guide needs to be more verbose and do a lot more education and explain the why behind things. We also set up a series of one-on-one design consultation meetings to help people talk through their data visualization needs. The largest target for our visuals are the American public, which is a big target. It's everyone. And we can't exclude people. But another target for some of our projects is a focus on experts, basically people who have a higher level of familiarity with the subject so we can produce more complex visuals for them. Here, the data visualization style guidelines are part of the larger design manual for the organization. However, it's a separate section for people who might not need the other design or web components. It starts by setting the tone of when this guide should be used and why. There are key questions in each section which are a good overview of things to think about. And it's public on the web and on GitHub, like all of our other design manual content. It shows what colors to use and what to use them for, like emphasis or null, and it's tested for colorblindness. It gives a quick overview of the pieces of a graph which combines style notes with content. It shows how to display important contexts like sources or dates that help maintain our credibility as graphics get shared. And there's an emphasis on accessibility. As a government agency, we need to be 508 compliant. That's section 508 amendment to the Rehabilitation Act of 1973 for those of you who didn't know. Which Boiled Down just requires federal agencies to make their electronic and information technology accessible to people with disabilities. So how do we do that for data visualization? Well, it starts with having descriptive titles on charts to help the user understand the chart and give them context for what they're seeing. We try to not just rely on color for meaning, but to have direct labels or patterns in order to help people identify different things. There's a minimum standard for color contrast and type size. And so our goal is to follow the W3's web content accessibility guidelines, WCAG for short. These standards are included in the basics of the guide. It's not just in the accessibility section, so it's not an afterthought. And we try to write good alt tags for when our charts are just images. Our goal is to include the chart type for users who might be partially sighted and using a screen reader to supplement their experience. As well as a short description of the point of the graph and to include a CSV or other readable data sheet so that users who can't see can tab through the data and at least get a sense of things that are in the chart. But also having a CSV adds transparency so you can see exactly what data is in our graphs. So even if your organization isn't required to think about accessibility, I think it helps the experience for all users to do at least these basic things. Just a quick review. In both the data visualization style guide examples, they included color, text, tone, and layout, which helps the charts be consistent and provide context. Having chart examples helped users know what they should aim for. Knowing who's reading your graphs, your target consumers, and you want to make sure your audience's needs were met. Knowing who's making your graphs allowed the guides to provide tailored content for what would be most useful. And figuring out what works and what doesn't before standardizing it made sure that there was a solid foundation to build on. And they were designed for organizations not software so that people in the organizations could use whatever visualizing tool that they were comfortable with. They made contrast and accessibility easy. Good standards for accessibility easy makes good standards for accessibility made all the graphs more readable. Having a data visualization style guide improves speed and ease because it cut out solving simple problems multiple times. Having an attention to detail ensured that things like sources or logos were not left out. And knowing the rules before we broke them, just having rules in general allowed people to break them with intentionality. So take your data visualization to a more refined level. A data visualization style guide is not just for branding but for accessibility, consistency, and ease. It's really an investment in your organization's credibility. Thank you.