The federal government, bound by centuries of history and numerous regulations, has historically built online experiences that reflect bureaucracy rather than human needs. Government websites that don't meet user needs produce poor outcomes and worse opinions about the government. We’re doing something about this. During the summer of 2015, a team came together to create the Draft US Web Design Standards: open source UI components and a visual style guide to create consistent, cohesive, and easy-to-use user experiences across federal government websites.

We’ll explore:

  • How to create a style guide in a highly complex, old system with multiple stakeholders and different end users
  • How to make easy-to-use tools that solve real user needs
  • How we're creating a nexus for industry best practices and collaboration across government agencies and with the public
 

Unedited Transcript

Chris Coyier:

This is very important, the cookies have arrived. They are in the back middle. And they were baked right into the cookies and they weren't pushed in later. This is a special one. {Indiscernible} Up next, the president of the United States of front end. It's Maya, who I just met at this conference. I have a pod cast, and we had Maya on from an organization called 18 up, it's the U.S. government and you work on big important projects literally for the Government. And other government agencies hire them to do work for them. And they hire super smart people, to do their duty for the government. A little about, likes hikes and like her dog, and bit of a percussionist, and has maybe one other skill.

[Maya beat-boxes]

Maya Benari:

I was going to rap the whole talk but... just kidding. Hello, every one. I'm Maya, I'm a front end designer at 18 F. Which is a digital service team inside the government and I'm so stoked and excited to be here among your amazing designers and developers from the industry. Have a question for you, show of hands, closer to the mike. Okay. How many of you have designed something for at least 1,000 people? That's a good amount. Nice. How about at least 1 million people? That's also a good amount. There is a lot of global enterprise companies here, great. I'm part of a team that was tasked with designing something for 320 million people, the population of the United States. I want to talk about one of those people, JoAnn. This is JoAnn. She just came back from serving in the army. And she wanted to get her GI benefits to cover the cost of college. She had to wade through multiple websites to access the federal problems to help her afford college. She is confused. Are these programs related to each other? Are they all part of the federal Government? Are any a scam? When she tried to access the sites on the bus on her way too work, she finds that half are impossible to use on the phone. She is overwhelmed by how hard they are to use. Misses opportunities she is eligible for and feeling frustrated. Some of that is designed to help her stands in her way. She is not alone, million of people trying to escape poverty, have to wade through confusing paperwork. Others are caught in the maze of trying to immigrate to the United States. When people go on to the government services they are confused. Joann has at a relearn and orient herself. These are important websites it's the state DMV, the U.S. Supreme Court, and who can forget, N S A F kids. The problem is we don't have clear and open communication with our government. To show you how this scales, we spend to ton of money on federal A T projects. Over ninety percent of them are over budgets and behind schedule. Forty percent of them never see the light of day. You are spending a ton the taxpayer money and failing people. The Government has historically bought I T like pencils and tanks. Companies are contracted to develop products. And the government is either forced to use it or dump them. They meet specs or ignore the process developing it. It became clear that if we wanted to help JoAnn we had to help the people making these digital services. The question in front of us became could we build easy to use tool that serve the public's need? And second, is it possible to create a shared set of tools to provide consistent effecting and easy to use government web sites? We think this is possible. And the summer of 2015 the team formed to create these tools. We had a lot of help from the food and drug administration the adopt the education accident veterans fares U.S..GOV and host of others. We started the process and we noticed that the private sector has been exploding with style guides and conferences. And we saw some agencies that the consumer protection bureau, started to create frame works for their agencies. But not every agency has the resources to spin out their own to present end frame work. We admired how the park service did over a decade ago, set up a design tool. And they had a beautiful font and we have great history of great design in our public institutions and we wanted to do what they do in the digital space. We looked outside our borders, we are fans of the Government.UK, they have a single userfied system because of how they are organized. However we are much more centralized. We had the carrot but not the stick. They have the principal, be consistent but not uniform. They try to use the same patterns but they are not fixed. It's about serving the needs of the users. So this is how we did it. We had to make the case to something inside the general services administration called the great pitch which is an opportunity for anybody in the government sharktank style to improve something in Government. The pitch went through and we had four months. Four months is not a lot of time. We decided to start with simple question. What's it like to work on digital services in Government? And although we the team work on digital services in the government and in a sense we are designing these tools for ourselves we need to explore this and started our user research. We talked to people all over the government. We find people in these categories. We have loose user archetypes. This is a clock racer, this person has way too much work to do in too little time. They want quick prototypes. They are more likely to choose a tool they are familiar with than to choose a tool they are unfamiliar with. There is a master builder. They are used to working alone. And they see their code as their personal craft and want a clean mark up that is easy to manipulate. They have strong opinions about how codes should be written and they want to know why decisions were made about the code. And then there a lone ranger. They were trying to do the right things but without time and support. They will use resources to cut down to time. Then we have others, we found a guiding principal to guide us through these users. We wanted standards to be reusable. And we wanted them to be accessible they must work for everybody. And last we wanted to standards to be open source, this increases knowledge and understanding and shared practices. I wanted to talk about that first point, flexibility. And in particular flexible design. Joann wanted to and understand, she wants it to be familiar and intuitive. So she can accomplish her task. We wanted to explore thousand make a consistent feeling and behavior across the web sites. First we needed to decide what components were important to so brought in people from the F D A and Consumer Protection Bureau and the V A and brainstormed. And next we looked at nine top level domains, and we wondered could do we really need 30 different shades of blue. And next we were even more surprised by how many different button styles there were. Do we really need 64 styles of buttons? So we wanted to imagine what a unified government website could look like so we created three mood boards. So we wanted a modern American look and feel, and traditional. And topography is important, he needed to find a for the most part that is legible and was open source. So we tested typography appearance on actual websites to find pairing that would meet these needs. The draft standard offered the style that could be applied to a broad range of platforms but it's not required. It's about providing consistency and they provide default colors for teams that need direction. The styling can be customized so they go retain their own established identities. And this is important to help people to get on board and they have their own institutional memory and we need to abide by that. Here are some examples. If they are just starting out they can use the whole thing. Visual style and components. Here is the example of the V A which applies to the case system for veterans appeals. This is next example is from U S A jobs who took our design to tailor to our needs. And we need to talk more about these components. This is what it looks like in action. If they are in the middle of a project, refresh her recollection, if you want to add fonts and colors and leave the system as is, vets.gov did just that. They had a front end frame work, and they incorporated fonts and colors and so many components into their website. This is a location finder page that combines our components in their app. If they have an existing site already, it may not make sense to start over. They may want to follow best practices in accessibility. There are three ways to use the standards. You can use the whole thing our design and code. Our design and different code and a different design and our code. So we encourage folks to pick a flavor that work for them and their organization. You can already start to see what we are seeing is a lot of consistency and coherence in the agencies that use the web sites. Next I want to talk about flexible code. This is a good reminder from Luke W that we should really think about how we write our code, because the thousands of people working in federal I T and millions of Americans will be living with it. So no pressure. We built the standards to be lightweight. It's plain H T M L, C S S and java script. Nothing fancy. It lets the open source community work open frame works. We built it with Sass and we offer compiled C S S for people who don't need it. We want these tool to reduce repetition. But we want it to be accessible. How do we write our code so it could be used by beginners and advanced developers? We asked the developers how they wrote their C S S and what was really important. Here is what they told us they like, they like modular C S S and easy to understand syntax. When asked if they were willing to change how they wrote C S S if they had something else? Most people said yes, if we had something reasonable they would use it. The age old question, to BEM or not to BEM.ing on oriented C S S has value. It keeps your work modular. We thought people would favor the approach, but only a small percentage of developers use BEM. We didn't want to add more red tape, so we went with BEM guide, but without the underscores and bloat. So BEM is really good at keeping your C S S modular, but you it fills your code with classes. They wanted less classes in the mark up, so more nesting and data collectors. They wanted more things assumed. We are still working out what this reasonable approach will look like. It was okay. I talked a lot on that one. Everything we do is public from day 1. Our work is in the public domain. It's public property, you pay for it, it belongs to you. You pay for my salary. Working this way has benefits, it makes your code more secure and higher quality because people are catching the mistakes more easily and frequently. This project has had a ton the benefits for working in the open source. We have had over 50 people contributes code from typos to bug fixes to code refactors. Over 200 people have been participating be in conversations on GIThub issues. And a hundred and 50 people have split GIThub issues. We love our contributors. And in our first week since launching we have had 22 contribute ares who have had their code included. Working in open source means you can get answers from anybody. We got help from across the pond when head of gov.UK helped us out. They submitted a P R to ensure that our radio buttons works. There were P Rs around a future upgrade of bourbon to make it was the best it could be. We also got help from Eric Speakerman. We reach out to him on a whim and we asked him what font he thought was the best font for America. He said, without the doubt, Morris Fuller Benton, 20th century American Gothic. We knew we needed to use an open source font for everyone that needed to use one so we tested our fonts and the best picks were soon after we discovered that Source Pro was inspired by American Gothic. It was a great moment because it allowed us to honor typographic heritage. And Adobe who made that font, they created an open source font and reached out to us to help create a font. And here an a live templating tool, you can copy and paste mark up on the left and see out put on the right, and you can manipulate and play with it. So it's a great way to show the different aspects of the standards. Another thing is if you want to have an open source community, you want people to keep coming back and mozilla, found to respond to an issue within 24 hours and to code review within 48 hours. It didn't mean you have to have a fix right away, but a response. Also. Being kind. Thank the contributor for their input. Acknowledge them whether or not you use their contribution. When you work for the Government access because it is the law, it's not an add up. It's important that what we create work for every one. This is an awesome moment for everyone at the Grammys. Accessibility is hard and it takes time, so we wanted this to be easier. We built in accessible code into the component, and we had some best practices to fill accessible websites standard. We started with H T M L five with ARIA. Provides greater accessibility across the wider range of accessible technology. Testing is really important so we test all our code for 508 compliance. And we want this to be automated in the future, and for the final release a manual review with a reader is the best way to ensure a quality experience. A little about documentation, so copying and pasting as is, is just a bad as leaving it out. So we include information on whether and how to modify the code. And best practices on how to apply forms. And American inspired palate is accessible out of the box. People may need to change the colors for their agency needs and we encourage them to test the combinations for them in the wild. Next I will like to talk about how the standards are doing in the wild. Since launching the project, it's become the second most standard depository in the government. 50 websites are planning to use the standards. We were thrilled with the response we had from the public. We found a new team motto, which is, what a time to be alive. We made people feel a little weird for liking a government website design. But not everybody was happy. Here is a translation from English to American. We also found out about a list serve in the government that we didn't know existed. We have an issue of how we communicate to everyone else in the government. It's huge, there are a thousands people working in I T in the United States. We found out there federal employees were concerned that they had to use an outside thing just dropped off to them. And see this phrase, "naming things is really really hard." We ruffled some feathers actually because we called it a standard when it really wasn't an official government standard. So we had to change the name to it's important to choose your words careful. There is conversation about whether there should be a web policy or standard. Now we found our home in the federal front door initiative. It's an initiative to improve how government communicates across the board. What does it mean to trust a government website? And how do we deal with multiple lingual people. And with those things be captured in design patterns. We think the standard will be more useful and valuable. And last, some final thoughts. Recently the standards, we have a prototype on a project we are working on, and this is what a participant said after going through it. I like the clean format, I like it shows me all the things I need to fill out all at once. I can read it fine. This is good it has sharp contrast. This is what it's all about. Good civic design is about access. It must be available to all regardless of circumstance, device or location. Good design ensured us, it means that people can get the right help sooner and with less stress. I remember this from the code for America summit, she said the barriers here are not technical, you have a team of people who understand policy law and regulation and are some of the best in the country. Your organizational structure is not set up to understand what users experience when they are using your service. So design can provide the interaction people have with their government by having clear and open communication with public. By understanding what people experience when they use public services we can design and build better systems to meet the public's needs. This is 18 F and it's challenging work, it's the first time we tried this, we are working a lot and messing up a lot. So if you are interested in working, we are hiring. Thank you so much.

Chris:

Took me a minute to get up here. Wow. Lots of good stuff there. One of the interesting ones was that, and other people covered the fact that a design system might be for different types of people. It's for designers or developers but you have one into subtypes really. You might be a front end developer but you might be junior or senior or the clock master or super builder, the scope of the designer, maybe

Maya:

It's how you build this thing that is for everybody. That's the question and the challenge.

Chris:

There was a bunch of research obviously. It was months of research?

Maya:

We had four months of funding where we had to launch something after that.

Chris:

That was a pitch.

Maya:

Give us money and then the money will run out in four months.

We did the full research and specialists and front end specialists.

Chris:

If I had the idea, it will be so exciting to get started right away. Should you wait or can you do them in tandem?

Maya:

We talked to a lot of people but we had our eyes open, on style guides and all that so on to see everybody else was doing.

Chris:

Another thing you said, do we BEM or not? What is the H T M L structure we except is that because people have different needs?

Maya:

You go out thinking that developers said they want this to be modular, but then a lot of different classes but then it's annoying to them. It's unsolved. I was having a thought the other day, it depend on how stable your component is. That might not change. So if it's something that is going to be a lot of tables or changing things around maybe putting a ton the classes there sent the best thing.

Chris:

If source sand is the closest thing to an open source, what is the most American java script library.

Maya:

Vanilla J S.

Chris:

And the color scheme? Red write and blue, right?

Maya:

How could it not be.

Chris:

No oranging up in this style guide.

Maya:

Those are the secondary colors, green and purple.

Chris:

No only red white and blue. U S jobs, V A?

Maya:

There are 50, we have a spreadsheet.

Chris:

I think there was some questions of people, assuming maybe that it's a mandatory thing. You created it and now it's there and people can use it. It would be an another ball game if you said, the entire Government must use that.

Maya:

They would be mad if we said that. We wanted to make the best thing the easiest thing. Why would not you use it. Not everybody knew about it because we could not communicate everything to the thousands of developers in the Government because we would not have been able to make anything if we did that. So we collected a few that we thought were important that we had connects with to get a started now it's in the open.

Chris:

And you observed people migrate to it and start using it.

That's a fascinating part. Some people use just the design of it. Or we will just copy it. And so many use the code and keep their own design.

Maya:

That's the best. The best is whatever works for the agency.

Chris:

And the accessibility comes for the ride in a sense. We learned with accessibility, it harder to assume that it's there are. The law is a little twist in this. You wonder what the consequences are. It's not good whatever it is.

Maya:

The Government, a lot of like bad things you can see. The previous slide with bad websites, but they have good things. Yeah, accessibility is the law, it should be that way. Everything is open source, it should be that way.

Chris:

What's the tech stack like, did you you have to pick thing like it's weird to pick like is Sass involved.

Maya:

We all were comfortable with Sass, so we put in a little bourbon and neat. And what else? It's pretty plain. Actually when we started out, the second style guide website is a general website. But not for the system itself.

Chris:

You weren't afraid to make choices like that?

Maya:

In the beginning we were, but we talked it out.

Chris: Thank you.

 

Sketch Notes by Susan Lin