Episode Transcript

Karen:

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

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week, I don’t think Ethan and I could be more excited. We are here with Danny Chapman and Emily Wright-Moore to talk about vets.gov. Welcome, thank you so much for joining us.

Danny:

Thanks for having us.

Emily:

Yes, excited to be here.

Ethan:

But before we dive in, I’d like to take a moment to mention our sponsor, GatherContent. They’re a wonderful content collaboration platform that helps teams plan, organize and produce all of their web content in one place. We’re excited to have them as a sponsor, as they want to make collaboration easy. GatherContent lets you centralize your editorial process, allowing your team members to easily edit and approve content: they offer simple workflows and structured templates, leaving off the mess of mailing tons of Word documents around.

What’s more, GatherContent’s designed a powerful API, allowing you to take your content wherever it’s needed: whether it’s publishing to your CMS, or pulled into an in-browser prototype, or directly into your application. If you’re looking to make your website responsive, you might give GatherContent a look. Check them out today at gathercontent.com.

Karen:

So to start this off, I’d love to have you both introduce yourselves and tell us a little bit about what your role is on this beta site that we’re talking about today. Emily, why don’t you go first?

Emily:

Sure. So, my role on this project is the lead designer for vets.gov. I am part of the team called the United States Digital Service. I am employed by the Department of Veterans Affairs, and we are a new team that started about a year ago, and we are working on making government services work better. Yeah! I think that’s all I can say without dropping a bunch of acronyms on you. [laughs]

Danny:

[laughs] There are plenty of those at the VA.

Karen:

Danny, how about you?

Danny:

Sure. I’m Danny Chapman, I serve right now as creative director for a company called Ad Hoc, which is a small startup that is focused on making things better for government, and we’ve been partnered with the VA for about eighteen months now I believe, give or take. So, my involvement on vets.gov goes back I want to say about a year, when it was really just an idea between a couple of people that was getting kicked around, and have been serving as a designer on the project ever since.

The idea was to launch the small-scale experiment just to see what would happen if we rewrite a lot of VA content and really streamline the process for vets.

Karen:

So I’m very interested, as you have spent this time working and you now have a beta release of vets.gov, can you talk about how responsive design played into your discussions about the overall strategy for this project? Like, were there questions or concerns about using responsive as a methodology?

Danny:

I don’t think there were really concerns at all from the get-go; we had tremendous buy-in in terms of responsive design. This project was largely the brainchild of the CTO at the VA, the chief technology officer, her name is Marina Martin. Certainly she wanted this to be responsive from the get-go, and the idea was…

Just to level-set a little bit in terms of what vets.gov is: vets.gov is really a parallel website that’s running in parallel with the VA’s main site, which is VA.gov right now. The idea was to launch the small-scale experiment just to see what would happen if we rewrite a lot of VA content and really streamline the process for vets to get content—information about the services that are relevant to them. So, it wasn’t the case that we were retrofitting an existing website or having to pour a lot of this existing technology into something that was responsive. We were starting from the ground-up, so that certainly made things a lot, lot easier. And like I said, the buy-in that we had from the very top of the VA was just fantastic.

Emily:

Yeah, I think, to add to that, if we were to go down the path of retrofitting existing websites, just for some context, the last count I had was that the VA has 1,427 websites. That is an undertaking that I think is completely insane to replace all of the functionality and the content of all of them, so our approach has been to start really small and just get it out there and meet our users exactly where they are in the most user-centered way possible. Responsive, I think, is very much part of that.

We just really don’t want to make any sort of assumptions about what device you’re using, and that’s been at the core.

Ethan:

I’d love to hear a little bit more about how some of that user research might have played into the design of this completely ground-up responsive experience. Specifically, tell me a little bit more about how the needs of the mobile user and the desktop user came into play. We talk to some organizations who think that mobile users are always running down a street and they’re completely distracted and they have absolutely no time to focus, whereas desktop users are on the other end of the spectrum. Meanwhile, some organizations say that they more or less need the same information all the time. Can you tell me a little bit about where vets.gov played out in that?

Danny:

Emily, do you want to take that?

Emily:

Sure. I don’t have a lot of numbers in front of me. I wish I did. I like to go to numbers for questions like this. But I think one thing I’ve found in this role is that we don’t always have all of the comprehensive data because we have such a distributed series of websites. We do know that a lot of our services are accessed on mobile devices or on a variety of screen sizes. You know, I think we just really don’t want to make any sort of assumptions about what device you’re using, and that’s been at the core.

We have a lot of services that are oddly browser-specific and that’s also played into some of our decisions. We have things that we’ve realized, since launching into them to try and rethink them, that they work only in Internet Explorer or something—and I do know that that only accounts for I think thirty percent of our users if it works in Internet Explorer. But as we’ve looked at it, really just going for the most simple approach possible using plain language, using content that is written for humans, has been super crucial. And testing that with people—we’ve had really good feedback from our usability sessions on making sure that people understand what we’re trying to tell them. [laughs]

Our mobile and tablet traffic combined is pretty close to thirty percent right now, and I think certainly as more vets do come home from Afghanistan and Iraq, those numbers are only going to increase.

Danny:

Yeah, I think to Emily’s point, the use cases for the VA have such strong mandates, right? Whether it’s from getting a home loan to getting your benefits as you come back from, say, Afghanistan, the use cases are so big and so broad and so important, we just don’t want to make distinctions—Ethan, to your point, that the vet on the street corner with that sort of mobile use case, “Oh, they shouldn’t get all the content or all the service.” It’s just so important to not make those distinctions in our case. And certainly, right now, just to throw a number out there, Emily I believe our mobile and tablet traffic combined is pretty close to thirty percent right now, and I think certainly as more vets do come home from Afghanistan and Iraq, those numbers are only going to increase as those demographics change. So, we’re certainly expecting that to just continue to grow.

The other awesome thing about our content team is that they are almost all, or possibly all, veterans or veterans’ spouses. So we’ve kept the people who are making the content really close to the people who are our target audience.

Karen:

Emily, you said something that made my ears perk up and my heart sing a little bit, which was plain language and making sure that the content works for people. Can you talk a little bit about how you thought about the substance of this site? So, what do you communicate, what are people looking for, how should that be prioritized, and how is that influenced by the fact that this website has to work on all these different screen sizes?

Emily:

Yeah, so, first and foremost, our content team was really the first—I mean, I think we had lots of initial design thought that mostly Danny had done, but the first real team that we put on this project was the content team, and we really looked at entire content areas rather than looking at a specific service or a specific department at the VA that has a website. We look at if you want to apply for disability benefits from the beginning, what are all the things you’re going to need to know whether or not you know they come from the VA? We don’t need you to understand our business.

The other awesome thing about our content team is that they are almost all, or possibly all, veterans or veterans’ spouses. So we’ve kept the people who are making the content really close to the people who are our target audience, and that’s been really helpful just as far as making sure that we have the right perspective and the right voice. Yeah, in addition to that, I think usability testing and checking in with users on a regular basis—I think we do biweekly usability test sessions for each of the different tools that we’re working on, so making sure that’s a constant, that that’s iterative and ongoing and we don’t ever drop that part of our work has been very core for us.

We made it a point to get to designing in the browser, to coding as soon as we possibly could, and I think that was really key.

Ethan:

I love that focus on frequent usability testing. I’m wondering if either of you could talk a little more broadly about your design process for the new vets.gov. Has that changed, generally speaking, as you’ve been doing more multi-device work over the last few years? I mean, heck, if you want to get even into the nitty gritty of the applications and tools you’re actually using to talk about a responsive design, I’d love to hear anything you can share with us.

Danny:

In terms of vets.gov specifically—and then I can maybe dial back from there—but in terms of vets.gov, we certainly did start wireframing, we used mock-ups as our initial tool, which is to get very, very loose ideas in front of some of the major stakeholders at the VA.

But we made it a point to get to designing in the browser, to coding as soon as we possibly could, and I think that was really key. We had a pretty short cycle on this project, under a year from some of those initial kick-off meetings to launch on Veteran’s Day in November, so it was a pretty tight time frame in terms of what we were looking to accomplish. So I think making that jump to the browser as soon as possible certainly on vets.gov, and I think more broadly in other projects, has been the biggest shift for me. You know, I think that sort of feedback loop of designing it in a browser, passing someone the site on a tablet and letting them understand how it looks on a tablet versus a phone that you hand them next, that’s, to me, when those light bulbs go off when you’re working with stakeholders.

We’re designing systems rather than specific views or specific apps. When you look at an agency this big you really need to think beyond what you yourself can create.

Emily:

Yeah. I would also add that, any possible opportunity, I think we’re designing systems rather than specific views or specific apps. When you look at an agency this big—like I think the VA is half a million people and that doesn’t include contractors who are actually working on a lot of these projects—you really need to think beyond what you yourself can create. So creating style guides and creating sample applications that people can download and get started with, and just making sure that we’re designing for a way of working to build sites for vets.gov, more than just building the actual website we really want to make sure that the VA is coming along with us on this journey to make better content and make better technology.

We made a pretty conscious decision not to design too much with these systems early on before the content team had had a chance to really write to what the user actually needed.

Danny:

Yeah, I think one of the interesting things to that point is, in collaborating with the content team, we made a pretty conscious decision not to design too much with these systems early on before the content team had had a chance to really write to what the user actually needed. A lot of times in projects past—for me at least as a designer—it’s very easy to build a container that then the content team has to kind of pour the content into that middle area that wraps around your header and your footer and your navigation and sidebar and so on, and you give them a sort of amorphous blob in the middle, and we really didn’t want to do that. Again, back to Emily’s point about scale, it’s just not something that was going to work or really serve our users’ needs. So, we actually designed a lot of these kind of UX and design patterns after we’d had a good look at the content and worked with the content team.

It’s always a dance in any process, but the bigger the amount of people who want involvement, the more precarious the dance might be.

Karen:

I loved what you said about bringing the VA along with you as part of this design process. Can you talk about how you managed reviews of the work in progress or reviews of your designs or your prototypes with the rest of the organization? How did you communicate what they were looking at and what kind of feedback you needed?

Emily:

That’s such a good question. It’s a dance, I would say, in getting the right amount—I mean, it’s always a dance in any process, but the bigger the amount of people who want involvement, the more precarious the dance might be. [laughs]

I would say one of the best decisions that I think Danny made early on was let’s not have a bunch of photography, a bunch of icons, a complicated design system, let’s keep it very simple so there’s basically less to go over on an individual process basis. The content review process at the VA can be very cumbersome, as well as like individual departments having their own design, their own logos, their own branding, their own everything. So, what we’ve really done is say vets.gov has its own voice and tone and brand and look and feel, and this is how your product will look in vets.gov. It won’t look like it does now, we won’t be able to bring in your logo, because that doesn’t serve the need of a veteran looking for a service.

Certainly having a beta release has helped with that as well, because it’s not as public as most government website releases. So, setting the groundwork early with all of our stakeholders and all of our coworkers that these are the decisions that have already been made and we have the buy-in of our agency to move forward with this process has been really helpful. I think that that level of clarity is actually quite welcomed once you get past how different it might be from how they’ve worked before.

We’re under 500k right now—frankly I’d like to be about half that, because we do have a lot of vets that are on rural or slower internet connections.

Ethan:

As you’re having discussions with stakeholders about content, hierarchy, priority, and layout, I’d be curious to hear if performance was something that came up in discussions around responsive design. Was this something that was a design requirement, or something you’re continuing to measure?

Danny:

Yeah, it’s something we’re certainly measuring going forward. I wouldn’t say it’s a hard and fast requirement yet, but I will say I think one of the great byproducts of having such a minimal design—as Emily mentioned, we don’t have images, we don’t have video, we don’t have a lot of the standard embellishments you might see on a traditional design—that’s really helped keep that performance to a pretty good place.

I think we’re under 500k right now—frankly I’d like to be about half that, I think we can do it with a little bit of work, because we do have a lot of vets that are on rural or slower internet connections, and that’s hugely important to us. So it’s certainly been a welcomed byproduct of our minimal design approach, and that’s something I think we’ll hopefully focus on more as we go along.

Getting that real qualitative feedback has been really great. It’s a much more constructive conversation that way.

Karen:

I’d love to ask more broadly how you talk about measuring the success of a responsive project like this. Like what sorts of metrics or analytics do you look at to know if this responsive design is actually working?

Emily:

That’s a really interesting question. It’s something that’s funny, coming from private sector or startups, which is where most of my experience has been, and a lot of my team has come from that world—not all, but some—you’re set up with these sort of metrics that are based on a signup or a purchase, and when you look at a public service, you don’t really have that. Like, the best thing you could do is make sure they got what they needed, which is kind of awesome, though slightly more complicated when you look at the metrics that your site is generating. So starting to dig into that is really fascinating.

As we’ve watched our traffic grow, we’re getting a lot of response through our—we use UserVoice, in the bottom corner of our site you can click on a little light bulb and send us your thoughts, and we also have an email address that we take in for feedback. And just getting that real qualitative feedback has been really great, and it’s really great to go to the stakeholder, our business partners, and say, “Hey, this is what somebody said. We think that makes a lot of sense. What do you think about this?” and it’s a much more constructive conversation that way.

Danny:

Yeah, I would agree completely, I think in government it’s very tricky to manage qualitative versus quantitative, and it’s tempting to want to look immediately to the quantitative. But in a case like vets.gov where the content is very succinct, the pages are very short, you’re not going to have that traditional customer retention model. A page might have a really high bounce rate and that might be a really good thing in our case, so it does sort of turn the model on its head. I think, just to add one more thing, a great area we’ve had tremendous feedback on is GitHub itself. We open sourced the site on day one, and that private sector or concerned citizen engagement we’ve had there in terms of making the site better has been really fantastic.

Cutting down the number of variables of things that can go wrong in any project, particularly in a responsive project, is always a good thing.

Ethan:

Well Danny, Emily, I’d love to hear, now that you have this beta responsive site for vets.gov out, I’d love to hear if there’s anything that you’ve learned that you’d like to share with our listeners. If someone is tuned into this podcast and they’re about to start a responsive redesign today, what would you share with them?

Danny:

I think for me, the biggest lesson learned is to start small, which we did just by nature of the constraints we had and the time frame we had, but I think that’s been hugely valuable to stay focused. Particularly in government projects that I’ve been involved in, there’s always this temptation to want to bake the entire product and then launch it with a big amount of fanfare, and that’s not what we did here, and that’s been hugely, hugely helpful, particularly from a responsive standpoint of just making sure that, frankly, everything works. Cutting down the number of variables of things that can go wrong in any project, particularly in a responsive project, is always a good thing.

Emily:

Yeah, I think that matches my experience. I also think that keeping the momentum going to move forward at all times has also been really crucial. There are an infinite number of blockers that can come your way with how to deliver services in this ecosystem, and figuring out a way around them or sometimes just changing your plan…

One good example of this is we don’t have a lot of the core services the VA offers yet because in order to collect personal information, you have to get lots and lots of security work done, and lots of authentications and different approvals, and we just haven’t done that yet. Getting the momentum of the site moving before we start to tackle these things that are pretty huge has been really helpful. And saying, “Oh, we already have a product. Now it just keeps going”—initially that was too big of a thing to tackle when we had nothing out there, but now that we have something out there, people know where we’re headed and it’s just the next logical step to add that thing. So, making sure that we’re transparent in our process and our direction, and just being iterative and keeping the momentum going on our team has been really helpful for those things.

Karen:

Well Danny, Emily, this has been really insightful and interesting to hear you talk about the work that you’ve been doing on this beta site for vets.gov. So I just want to say thank you from me and from Ethan, and I hope from our veterans as well, for all the work that you’ve done. Thanks for being on the show.

Danny:

Thank you.

Emily:

Yes, thank you, thank you. It’s great to be able to talk about this work.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, GatherContent. Go to gathercontent.com and take control of your content production process today.

If your company wants to go responsive but you need a little help getting started, Karen and I offer a two-day onsite workshop to help you make your responsive design happen. Visit responsivewebdesign.com/workshop to drop us a line—we’d love to hear from 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 episode at responsivewebdesign.com.

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