Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well, Karen and I are swelling with patriotic pride because we have the extreme pleasure of talking to Mollie Ruskin from the United States Digital Service and Julia Elman from 18F. Mollie, Julia, thanks so much for joining us.

Julia:

Thanks for having us.

Karen:

But before we get started, I’d like to say a few words about our sponsor, Harvest. I have to make a confession: I hate, hate, hate tracking my time. It always makes me feel like Fred Flintstone chiseling out his time boulder before he slides down that dinosaur’s back so he can go home. But using Harvest doesn’t feel like punching a time clock. Harvest is a beautifully designed tool that lets you track your time on client projects, start a timer from a web browser or mobile device, and it even lets you send invoices when your time tracking is complete. If you’re a responsible business professional you should be keeping tabs on which clients and projects are making you money—and the way to do that is through careful time management using Harvest. So check out Harvest today. Go to getharvest.com and start tracking your time. They’ll give you a thirty day free trial. When that’s up, enter the code RESPONSIVE at checkout and you’ll save 50% on your first month. Don’t hate tracking your time. Get Harvest.

Ethan:

So this is a bit of an odd episode for us because we are here to talk about the launch of a responsive site, but that website’s not exactly a website. We’re here to learn a little bit more about the design and process that went into building the United States Web Design Standards. Mollie, Julia, could you just maybe introduce yourselves a little bit but then we’d love to hear a little bit more of a story about just what these design standards are and who their audience is.

Mollie:

Sure, absolutely. I can tell you a little bit about me: I am a designer with the U.S. Digital Service, I’ve worked in the Federal Government for about two and a half years now, and I’ve worked on a number of different projects, many of which were public-facing, a number of which were internal-facing, which sort of is what helped plant the seed for the need for this. But before I go on, let me hand it over to Julia.

Julia:

Yeah, my name’s Julia Elman, I’m a lead front-end designer at 18F’s Experience Design Center of Excellence. I’ve been in the web industry since about 2002 and recently joined 18F back in March of this year.

From the user experience perspective, we’re asking our users to make sense of this myriad of brands and design systems and navigation structures over and over.

Mollie:

Awesome. So, you asked a little bit about how this all came to be and why. So, the Federal Government, much like many other parts of the technology sector—and yes, it sort of is part of that—has undergone a lot change in the last couple of years. We recognized the value and the need for good user experiences and design, and we’ve seen a huge amount of growth in information architecture and content strategy and just starting to actually make a dent in these enormous, daunting, somewhat unwieldy government websites.

As designers and developers at 18F and the U.S. Digital Service, we are often building products and services for many different government agencies, not just for a single set of users, and so we found ourselves kind of solving many of the same problems over and over and over again. As one of our colleagues likes to joke, “we’re all sort of building the same buttons.” And in addition, we realize that from the user experience perspective, we’re asking our users, which in this case are the American people, to make sense of this myriad of brands and design systems and navigation structures and all this stuff over and over.

We started to wonder if it wasn’t possible to maybe make our lives easier as product teams, saving some time and energy, and also start to build a little bit of consistency for the end user. So, that was kind of the big crazy idea about what if we could create what we’ve seen Google Material and from all of these other places in the private sector—what if we could bring that same approach inside of government? So, that’s what kind of got us kicked off.

Ethan:

I think that’s fantastic. One of the reasons Karen and I are both so excited to talk to you is pattern libraries or style guides have been such a big part of the conversation around responsive design lately. For our listeners who might not necessarily be super familiar with the idea of building a library of design patterns, maybe you could talk a little bit more about what that is and why it’s important to building a responsive interface.

Mollie:

Julia, you want to take that one?

We leveraged things like Neat in order to include a way for the users to be able to quickly and easily integrate responsive design into their patterns that they were using.

Julia:

Sure. So, in approaching the aspects of building different things in regards to responsive design, we’re really wanting to focus on the user, right; so, what are the users wanting. So, we did a lot of—in the beginning of the process, we started out, Russ Unger, who is the director of design over at 18F, Mollie and I got together and did sort of a precursor to all of this, which we got a bunch of people within government together to do various different exercises, which included empathy mapping and site mapping, and we found that it was about what they were looking at and what they needed in order to be successful. Really my role was to help lead from the technological standpoint.

We leveraged things like Neat in order to include a way for the users to be able to quickly and easily integrate responsive design into their patterns that they were using. And responsive design is a pattern within itself, so it sort of played out within the actual building of this thing. And one thing that Mollie and I were even talking about before this interview, one thing to differentiate is that we’ve got the pattern library itself and then we have the website. So, how are we going to actually differentiate how we use responsive design between the two of them, how they correlate together within the code, and then how they’re going to work for the user as well? So, we did a lot of testing with that.

We understand that you’ve been building this thing for desktop for a long time, but we now have this hard data to say a growing number of people are coming from screen sizes in different places.

Karen:

Maybe just following up on that, one of the questions that Ethan and I like to ask all of our guests is: how do you see the relationship between mobile users and desktop users? And something that’s of particular interest and importance to me is the need for organizations, in particular government organizations, to serve the needs of all of their constituents, and many of those constituents may be mobile users or maybe mobile-only users, people who don’t have access to the internet through other devices or may never have a broadband connection. Can you talk a little bit about how you deal with the mobile versus desktop question at USDS or 18F?

Mollie:

Sure. You know, it’s an interesting one, because in many ways what we’re often talking about is upgrading or redesigning legacy systems, so there’s obviously a lot of parallels to changes that have happened in industry in the last, you know, ten or fifteen years. So in many ways government is still catching up. There’s a really cool program inside of government that helps agencies build their own analytics, and there’s actually a cool website that our two organizations built together called analytics.usa.gov, which allows the public to see basically web traffic on all sorts of different devices and browsers and things like that. So, this gives us a little bit of an insight into how usage is changing on government platforms.

Right now I’ve got the most recent numbers here so we can see that 66.3% of our users are coming from desktop, 26.7% on mobile, and 7% on tablet. That’s really powerful data when coming in contact with people who’ve owned and managed long-standing services; to say we understand that you’ve been building this thing for desktop for a long time, but we now have this hard data to say a growing number of people are coming from screen sizes in different places.

Matched with information we know about the fact that particularly low income users are often coming on mobile devices, it’s really important that we start investing in designing for this continued growth. So, we didn’t spend an incredible amount of time digging into the complexities and the nuances for this project, but with every one of the different services that our two teams are involved with, doing that user research and trying to understand what technical capacity is and what kind of channels people are coming in on is hugely informative for us.

We needed enough to be able to actually build modular pieces out of it, but not too much so that we would never be able to ship something to begin with.

Ethan:

One thing I’d like to hear a little bit more about the standards is, well frankly, how you scoped it. I mean, for me at least, designing a pattern library traditionally, that’s often something that comes out of a larger design process. Like, you get a visual language in place, you try to identify the patterns, and then try to identify things that can be reused or broken up into smaller chunks. I think the standards that you’ve defined are incredibly comprehensive, but I’d love to hear about how you actually thought about building something, building these patterns kind of by themselves. Yeah, how’d you structure it?

Mollie:

It’s a great question and one that we’re continuing to figure out, because we feel like we’ve just scraped the surface as far as what we’ve included. We started with knowing that we were going to have to prioritize and to answer the question of basically, “What are the most foundational things to government websites, and what are the components and features that designers and developers building government websites need in their day-to-day life?”

We surveyed about forty different designers and developers. Then we did audits of a series of different government platforms to try to get a sense of, like, what interaction patterns do we need to plan for, what individual elements and components? We also were doing a brand audit at the same time—what were the visual factors we need to account for? I wouldn’t call it the most methodological and sane process because the scope of this could’ve been so daunting, but we knew we needed to get sort of some tangible number of things figured out that we could test or validate if this was even a worthwhile endeavor; we needed enough to be able to actually build modular pieces out of it, but not too much so that we would never be able to ship something to begin with.

Part of the rollout has been about getting our own teams up to speed and giving them the tools to be able to work with this; that’s kind of the low-hanging fruit part.

Karen:

Let me follow up on that and ask about one of my favorite topics, which is how do you plan a rollout of something like this? We’ve talked to many companies about how they have staged a rollout of pattern library or a responsive design across different sections of a website or a series of different sites, but nothing of the scale that you all are dealing with. So, how do you roll something like this out across the Federal Government?

Mollie:

That’s a great question. I think the first thing that’s important for us to clarify here is that this is really just kind of like—this is an alpha product for us. Like, we’re really just now kind of banging on this from all sides to figure out what we’re missing, what needs to be refined. When you call something a standard, you really need to have a lot of meat behind that, right? So, essentially when we set out to endeavor on this seemingly large task, we realized that we—our teams—had to first be like super jazzed and super ready to use this stuff. So, we kind of designed for people much like ourselves and did user research on our own teams to figure out what components we needed and how we wanted things to look and feel and all that stuff. So part of the rollout, to your question, has been about getting our own teams up to speed and giving them the tools to be able to work with this; that’s kind of the low-hanging fruit part.

The trickier stuff is all of the other folks out there. This isn’t required, it won’t be required any time soon; we are considering whether that is an option that makes sense. So, a lot of the focus on rollout, so to speak, is on finding the right kinds of partners who are looking for an ability to quickly prototype and stand up new things, and are flexible and interested in iterating along with us. And as we add more and more to it, doing outreach, it’s almost like a campaign, will require marketing, all of that kind of stuff. So, it’s a very interesting and sort of complex rollout, so to speak.

Ethan:

Well, let me actually ask—you know, when you’re thinking about rolling this out, I’d love to hear how USDS and 18F are iterating over the standards. I mean, presumably when some partners are actually working with the standards, they might identify things that they might want to change, or maybe there’s going to be some things that actually feed into the standards. I’d just be curious, have there been any discussions about how you can actually learn from implementation of the standards and bring them back into the canonical text, I guess?

Mollie:

Yeah, that’s a great question. Do you want to hear about how we’ve been iterating so far, or how we will be moving forward?

Ethan:

Can I just say yes? [laughs] I would love to hear about both of those things.

Mollie:

[laughs] Awesome. Well Julia, do you want to talk about the first part and I’ll take the second part?

Julia:

Yeah, so how we iterated during the process. So, let me keep in mind that this project was very fast—like, we had to work very quickly. About four months, did you say, Mollie, total?

Mollie:

Yeah.

Julia:

Yeah, it was about four months we had to do this, so we really started out really just getting going from the get-go. So, we decided to use static, create a static site using Jekyll, and separating things out into two-week sprints. And in these sprints, we did things like use Trello in order to organize our process and how to do it.

During that time, Carolyn Dew and Colin MacArthur were scheduling interviews, creating test plans, and various other things for us to be able to iterate on throughout the process. So, we’re not only building, we’re testing at the same time. And then Maya Benari and Marco Segreto, who were the front-end designers and developers on this as well, they were working with other people within 18F and USDS to start testing that implementation. For example, Marco worked with somebody in implementing the footer that was being developed, and seeing where were the pitfalls and where were we falling short; what were some other things we could do with the code?

It was really just trying to get things going from the start and working with people and seeing where we were falling short and then iterating throughout that two-week process. And then towards the end—a lot of projects do this “code freeze” kind of thing, where you have to kind of stop. So from here, I’m going to hand it off to Mollie to talk about that process and where it’s going from there.

Mollie:

Yeah, so basically we did kind of like—to the process that Julia was talking about—what we have now is the product of a couple rounds of iteration with a smaller community. But now that we’ve begun this rollout process, it’s like, “Okay, what is governance?” Essentially what you’re asking is governance. How do we decide what meets our bar of standard, our “standard of standards,” and how do we then fold that in? In many ways, that’s kind of the question at hand that we’re tackling.

We’ve done a lot of research as to how this has happened in other kind of open source and highly collaborative environments, and probably we’re all the hugest fan girls of the Government Digital Service in the UK and have tried to learn a lot about how they’ve gone about this. They have this incredible process using what is essentially a massive 700-person wiki, where people are constantly giving feedback on, “I’m trying to implement the date input field, and I’m trying to design a login interaction flow,” and they share bits of their research, and then there’s a team that’s responsible for testing and folding that in.

My sense is that what we’re working towards right now, and you guys are really getting the sort of “front-line to learning as we’re going” kind of information here, is that we’ll be scoping out the next priority of features based on what we hear from our users, and that some of those features might actually be designed and built by partners and other folks around the government. And then we’ll do reviews, make sure they are meeting our standards of visual accessibility, which is hugely important for government work, making sure that the code is written in the way that we’ve sort of spec’d out, it’s visually up to par, and kind of fold that in and include that in the next release of the stuff. So, we’re hoping to do it in a way that really encourages input from lots of different folks.

Ethan:

If I could just follow up on that, just a little bit more of the nitty gritty of how you’re actually building this, I’d love to hear just a little bit more about like the applications and tools that your designers are actually using to iterate on and evolve the standards. Are you tossing around Photoshop comps or are you just really diving more into the code on GitHub? What are you looking at on a day-to-day basis?

Julia:

So, I believe some OmniGraffle templates were being made. Mollie, is that correct?

Mollie:

Yeah, I think that was right. That was our UX tool of choice.

Accessibility is very very important to us at 18F, and so for us it’s important throughout the process in that we have someone at 18F that is actually checking the code for us and making sure that it’s accessible.

Julia:

Right. So OmniGraffle, as well as some Sketch files. So, to start with, again, just finding out what the users need and tools that we use at 18F, or the ones that I just mentioned, to iterate on. So, adding those in there, so templates to be working from there from just a visual design perspective, but also using GitHub and really, just from a raw coding standpoint, just making everything semantic and clean.

Accessibility is very very important to us at 18F, and so for us it’s important throughout the process in that we have someone at 18F that is actually checking the code for us and making sure that it’s accessible and available to people who can’t see and use screen readers, for example, and that the code is written in a way that someone can take it. Because if you’ve ever had to build an accessible form, that is just… it’s a very tricky business within itself, so it’s something we’re very passionate about and that we try to do within our practice, and now we’re trying to provide a way for other people throughout government to be able to do that and it being compliant in all the different areas that we need it to be.

Mollie:

To your question about tools, we kind of live on GitHub, and even though we were designing in OmniGraffle and Sketch and Illustrator, we just end up loading images into GitHub and pinging people for responses. And I think that’s really cool, going back, because it’s all in the public and you can sort of see the evolution of some of our design work in process. And it’s really neat, because it allows us to have this full history all in one place, and also to make it something that both government designers and developers but also the public can participate in as well.

Karen:

One of the things that I’m really interested in is pushing the industry toward a model of pattern libraries that is more integrated into the actual publishing system. So, I think there’s benefits to organizations having a reusable library of front-end code snippets, but I’ve seen lots of organizations benefit even more from having those sorts of patterns actually integrated into a CMS or some other sort of publishing system so that pages could actually be prototyped and published on the backend using this kind of functionality. Now, I also know that something like fifty-seven percent of Federal Government websites are published without a CMS at all, so… I’m not suggesting that you would be expected to be here today, but I would be curious: do you have future plans for actually building this into publishing functionality or building it into a CMS?

Mollie:

Yeah, that’s a great question, and we’ve heard a ton of interest in that since we’ve put this out. We had talked about kind of like creating themes on a couple different platforms early on and just decided, “Okay, focus is just build the stuff and first test the interest.” But we’ve tested the interest and there’s a ton out there. We actually have a group of folks independent from our core team who have taken it upon themselves to start building this out in Drupal, which is highly, heavily leaned on inside of government. I’ve heard a little bit of interest within WordPress developers, as well. So, I would expect that within the next six months or so we’ll have a couple different CMS platforms out there.

We learned that developing many different individual components and features all at the same time meant that we were building and designing much more iteratively.

Ethan:

One thing I’d like to hear a little bit about are reviews. As the standards are being designed and as you’re iterating over them, how are you actually talking about the work in progress as a team or with prospective partners? Are you showing them prototypes or are you showing them Sketch files? Tell me a little bit more about how you actually share the standards with other people.

Mollie:

That is a very interesting question. So, when we went about figuring out the process for this, we did a bunch of research and I spent time talking to a lot of the thought leaders of style guides and design systems. I talked to Nathan Curtis, and Brad Frost, and the folks at Google Material to learn about their ideas for doing this thing that they’ve done many times in this extremely federated, highly complex environment.

One of the pieces of advice that I got from all of them were surround yourself with people who are likely to be using this as soon as possible so that you can get people who are solely focused on the one thing that they care about, which is building a website for veterans or creating some sort of application or form online, to think about it in the context of their work in particular. There are so many people that we could’ve included and we just decided that, okay, for this first MVP, if you will, we wanted a handful of folks who are going to be doing that sort of thing based on that advice.

So, we kind of pulled together a collection of our fellow designers and developers from some mix of 18F, USDS, and then what we liked to call “lone rangers,” which were the designer, the developer, often a government agency completely by themselves, who would be heavily benefitted by having a tool like this at their disposal; they have to stand stuff up frequently by themselves, and these were the kind of folks we were getting feedback from throughout.

Originally we had imagined kind of like a, “We will show you all of round one and then you will give us feedback, and we will show you all of round two and you’ll give us feedback.” It turns out that we learned that developing many different individual components and features all at the same time meant that we were building and designing much more iteratively. And when I say we leaned heavily on GitHub, this is like really where this played out. So, we would start on the UX side and put up some wireframes and, you know, say, “Hey folks who are interested in this particular thing, come take a look, tell us what you think.” They would leave all of their feedback there, we’d give it another shot, add a little visual layer, more feedback, then we took it to code, and that became the process.

I think if I could go back and do it again, I would probably add to that core group of folks another rung of people who might be designing in slightly different kinds of contexts just so that we could get a little bit more of a range of feedback. But it really gave us a ton to work with. It was enough to work with that we were significantly iterating and not too much that it kept us from moving quickly, which was also part of the goal.

How much does it cost for the government to design a new website from scratch, and then could we then measure that against a product team inside the government using these tools?

Karen:

How do you know if something like this is actually working? Like, what sorts of measurement, what kind of metrics or data do you look at for the future?

Mollie:

[laughs] $60,000 question. That is a hundred percent a question that we’re answering right now. I mean, in essence, “are people releasing new product using this?” is the single most meaningful metric. One of the pieces of data I’ve been trying to get my hands on is: how much does it cost for the government to design a new website from scratch, and then could we then measure that against a product team inside the government using these tools, can we see the drop off? And there have been a lot of interesting conversations to try to figure that out. There’s all sorts of reasons which have to do with the way that government budgets are structured, why it’s actually quite tricky to do. But within our own teams anecdotally, we’re hearing a lot about how we’re able to stand up stuff faster. But I think the question of metrics and tracking is an interesting uncracked nut for this work, for sure.

Ethan:

Well Mollie, Julia, we are sadly coming to the end of our time together, and I’m sad about it because this has been a wonderful chat and I can’t thank the two of you enough for joining us. But before we let you go, I would love to hear if either of you have any advice for any other organizations, public or private sector, who might actually be starting on a responsive redesign right now. Are there things that you’ve learned in designing these standards that, for your next project, you’re hoping to carry forward?

Julia:

Yeah, I’d like to just say surrounding yourself with amazing people that you get to work with every day and just let them do what they do, it’s an awesome end product you’ll end up with. Because bottom line is that this project is just made of the input and the influence of so many amazing people, and I’m just so thankful to see where it’s going and where it’s ended up, where it’s going to go. So, I’m still just really proud of the work we did and the team did.

Mollie:

That’s such a good answer, Julia.

Julia:

[laughs]

Mollie:

Advice for other folks…I can’t believe I’m in the position to be giving advice, I feel like I have so much to learn from everyone else. I think that one thing that you have to just come to terms with in doing a project like this is that there are so many moving pieces and it’s a lot to keep track of all at the same time, and just to sort of like take a meditative, reasoned approach to that because it can be a daunting amount. I had been given that advice before I started, and it was about halfway through that I felt the zen of all of the pieces moving and realized that that was part of the beauty of doing this work, is that by us taking on this complex important problem, we were going to be making it easier for others moving forward. So, I would just encourage a can-do attitude and plow through those times where you feel like you’re building seventeen things all at once, because you will be.

Karen:

Well Mollie, Julia, both as a professional podcasting host but also as a U.S. citizen, I am just delighted by the work that you’ve been doing. I was so impressed when I saw the standards come out and I can’t wait to see what you do next. So, thank you so much for coming on the show today to talk to us.

Julia:

Thank you.

Mollie:

Thank you so much for having us.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast.

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Thanks for listening, and we’ll be back next week.