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 could not be more delighted to talk to two people who I have a huge amount of respect for, Miguel Gomez and Jeremy Vanderlan, who are here to talk about their work on AIDS.gov. Welcome guys.

Miguel:

Hello, well thank you for having us. This is Miguel Gomez.

Jeremy:

This is Jeremy, thanks for having us.

Ethan:

But before we dive in, I’d like to take a minute to mention our wonderful sponsor, Campaign Monitor. If you need an email newsletter you should absolutely check them out. Campaign Monitor features Canvas, which is their easy to use builder for creating wonderful email newsletters that look great everywhere, even on mobile devices. We’ve actually found here on the podcast that it’s very easy to create an email newsletter in just minutes. They have a great editor with some really decent drag and drop functionality, as well as some flexible, customizable starter designs that allow you to create these lovely looking emails that match your brand and your content. And the nice thing is, you don’t actually need a Campaign Monitor account to check out Canvas or their other offerings. You can actually just go to their website, campaignmonitor.com and start experimenting today. So thanks again, guys.

Karen:

So Miguel, maybe you could start us off by telling us what your role is at Health and Human Services, and a little bit about the work that you’ve been doing.

Miguel:

Sure, well thank you again for having us. At AIDS.gov, which is a program, my role and responsibility as the Director of AIDS.gov is to make sure our program moves forward. It’s important for folks to know we work in three specific areas. Information on, we provide information on federal HIV policies, programs, and resources across the entire government, so we push that information out through basic web pages, blogs, and social media on a weekly basis.

The second domain, which I’m so excited about, is that we provide our federal stakeholders and groups outside the U.S. government who work on HIV domestically, information on how to use new media to extend the reach of their work.

The third area we provide informational resources on is basic HIV information. For us at AIDS.gov it’s really important to understand who comes to your pages. The bulk of people coming to AIDS.gov are people who are looking for basic HIV information on signs and symptoms. So it’s my job to make sure all three elements of those things happen. I’m also lucky enough to be an advisor to those within the federal government who help build the future planning for our digital strategies. So thanks for the question.

Karen:

So, Jeremy, why don’t you introduce yourself and tell us what your role is on AIDS.gov.

Jeremy:

Thank you, Karen. My role on AIDS.gov. So I am the mobile practice lead at ICF International, and we work with AIDS.gov, in the technical implementation of the AIDS.gov website. I’ve been on the AIDS.gov project, actually, since 2007 and have worked on the project just as a front-end web developer initially, and then working as a CMS developer and CMS architect, and ultimately to the point where now I’m technical deputy for the project and work on the various technical aspects for AIDS.gov, including mobile applications, our responsive website, certainly, and then the other aspects of AIDS.gov, such as the blog, locator service, and a couple of the other features we have.

From the very beginning, bringing together the technical folks, the content folks, and the program and policy folks. When we build something, we’re doing it in a holistic fashion. We started from a better place to get us to responsive design. We always, from the very beginning, had an expectation we should be doing what’s best for the user.

Karen:

So we’re here today to talk to you both about your responsive redesign, and Ethan and I were really excited to see this. I believe you were the first federal agency to go responsive. Can you talk a little bit about the decision to build a responsive website? How did you decide that was the right strategy? Did you have to convince other people that this was the right approach?

Miguel:

Jeremy, why don’t I start? This is Miguel. When we first launched AIDS.gov in 2006, we were very lucky, because we started from the ground floor. There was a URL that wasn’t being used at the White House, actually, and as someone who’s been working on HIV/AIDS within the federal government for 20-plus years, I knew how important it was to provide users information about what the federal government is doing on AIDS.

So when I found out there was a URL that was as simple as AIDS.gov, I worked very hard to make sure that we used that functionally within the government. And at first I just thought, terrific, we’ll just list in one place all the federal resources when it comes to HIV/AIDS. But from the very beginning, I had folks like Jeremy say, wait a minute. You actually have to understand what the user experience is. And I, of course, had to ask, what do you mean by the user experience?

From the very beginning, what we started and we built AIDS.gov from a foundation is, bringing together the technical folks, the content folks, and the program and policy folks. When we build something, we’re doing it in a holistic fashion. We started from a better place to get us to responsive design. We also put together, across the entire federal government, a planning body from all of our AIDS programs that also included some tech folks and communication folks. What we did is, we always, from the very beginning, had an expectation we should be doing what’s best for the user.

Where we were really lucky is that, when it came to responsive design, you couldn’t necessarily say to a policy person that “I need something that’s device agnostic.” But what I could say to a policy person is, “doesn’t it tick you off if you’re trying to read something on your Blackberry, use that to go to the web, and you can’t read it?” Or an iPhone. And so what we started from was a place where on a monthly basis we were having conversations about what we can do to make our information available. So we were able to start from a place that we knew that we needed to be smart and we had smart technical folks. So I’ll punt to Jeremy to talk about the technical side. And Jeremy, if you want to add anything to what I said, please go for it.

We know we can do everything on the front end. Our CMS was flexible enough to do everything on the front end. So why don’t we just handle everything we can for mobile on the front end? Responsive design was the best answer for us.

Jeremy:

We actually initially started looking at ways to do better on mobile in 2008 and 2009. And it was really from an understanding of who our primary audiences were and who was coming to the AIDS.gov website. So, understanding that most people looking for information on HIV/AIDS are perhaps going to be doing it on a personal device or smartphone, and knowing that that was the case it became a primary use case for us. How do we take care of these mobile visitors? Because at that time it was just a big website and we didn’t really have either the content or the technical framework to actually accommodate those folks.

It started with us really taking a reassessment of the content in 2008 and 2009. We built an m-dot site in 2010. We were trying to do some redirects but we weren’t very good at it. Our technical environment wasn’t set up in the way that we could really take care of a full device detection system like WURFL. And so when we saw Ethan’s article on responsive design we began to think about handling all of the device detection on the front end and allowing the client side to do it. Basically saying, okay, we know we can do everything on the front end. Our CMS was flexible enough to do everything on the front end. So why don’t we just handle everything we can for mobile on the front end? Responsive design was the best answer for us. That was when the planning started.

Our second step was to actually do a really quick, almost like a pilot on AIDS.gov. We have a campaign site called Facing AIDS and Facing AIDS is all about sharing photos of people who are facing the stigma of HIV and AIDS and saying okay, I’m putting a face on AIDS. It’s a pretty cool campaign. It’s a lot of people taking pictures with their smartphones. So we thought, okay, we have this smaller website, it was really only three templates. We got all of the technical team in the room and we just basically said, let’s try and figure out if we can do responsive design, because we’d never attempted responsive design before that. So we pushed out the Facing AIDS website in November of 2011 as kind of a test, knowing that we were going to tackle the big project for AIDS.gov in 2012.

We could not just start creating the change around responsive design for ourselves. We started creating the expectation across the federal government that if you’re running an AIDS organization, we want you to understand what responsive design is.

Miguel:

Jeremy, I think real important to add to that is that we needed to actually make sure that AIDS.gov got funded and supported. And so, each step of the way we shared what we were doing with senior management across the federal government. Not just at the agency I work with, but even our folks at the White House. And it was really important that we had AIDS policy people at the White House, but we also had the tech staff. And so we made sure we introduced them.

Ethan, you will love it. Many times we actually brought you up, and the work you’ve done to explain to folks why responsive design is so important. So as the tech team was doing their work and making sure that we could do it, on my side of the street I was making sure that folks who don’t necessarily… they just demand get the products done, educate the public, that we really explain to them the best—at least what we think is the best way—to educate the public.

It was really exciting when, as Jeremy mentioned, we launched our first responsive through Facing AIDS. We actually also blogged about, and we gave speeches about, the fact to our HIV community that we were doing that and why we were doing it. We could not just start creating the change around responsive design for ourselves. We started creating the expectation across the federal government with our HIV partners, but also the AIDS service community around the United States that, if you’re running an AIDS organization you also need to think about how you’re preparing information for your client, and we want you to understand what responsive design is. I hope that made sense and I’ll punt back to you all.

Jeremy:

I like it.

The end goal was that if we did this right for mobile, I think the benefits were actually going to trickle back to the desktop users as well. It was going to allow us to streamline a lot of the content we had across the website, and also simplify a lot of the pages.

Ethan:

Yeah, that was all wonderful. I guess one point I’d love to hear a little bit more about is, Karen and I speak with a number of companies and organizations who are excited about responsive design, but one thing that tends to come up a lot in their conversations are these two words: mobile and desktop. That there’s this idea that mobile users and desktop users have their specific needs and wants. Was that a conversation that was ever part of the AIDS.gov redesign? I’d be curious to think about or hear about how AIDS.gov thinks about mobile and desktop when looking at the site.

Jeremy:

Miguel, I’ll take this one, I think. So, we made an attempt at mobile first when we redesigned the content back in 2008 and 2009. It was really just apparent to us that the mobile wave was coming and it was going to be looking at a lot of the content.

Then what ended up happening as well, is once we actually got our mobile website out there in 2010—this was before the days when Google was hiding all of the search terms behind SSL, so we were able to see a lot of the search terms that came to the AIDS.gov website. For the folks using mobile devices, they were actually using more explicit terms and more personal language when they were searching for HIV information. It was really a definitive break. The majority of searches that came via the desktop were coming via just kind of general terms like HIV, AIDS, or AIDS awareness, or HIV symptoms. Whereas people on mobile devices were, “How do I get AIDS?” or “I feel sick, do I have AIDS?” And even using explicit sexual language when they were talking about “Can I get AIDS from X?”. They were using those terms and they were getting to the mobile website that way.

We actually make sure that we understand how many people are coming to AIDS.gov from a mobile device or a desktop. That’s really important because it informs all of our thinking and our decision making.

We began to understand that the mobile users—we were actually really beginning to separate them, because we knew that was happening—but we felt like we could go mobile first in that sense because the majority of people were going there. Now, AIDS.gov, because we have three separate entities under one umbrella, being the HIV/AIDS basics, the federal resources section, and then also the “using new media” section, we knew that there were going to be other people.

But the end goal was that if we did this right for mobile, I think the benefits were actually going to trickle back to the desktop users as well. It was going to allow us to streamline a lot of the content we had across the website, and also simplify a lot of the pages. From the technical side too, was actually allowing us to really abstract a lot of the styling and customization that we did on some of the other pages and make it a whole lot more modular between the various sections.

Miguel:

Jeremy, thanks to your work and some of the instruction from you and your colleagues, is that very early on, on a monthly and sometimes weekly basis, which we still do today, is we actually make sure that we understand how many people are coming to AIDS.gov from a mobile device or a desktop. That’s really important because it informs all of our thinking and our decision making.

We thought specifically of people who felt like they had put themselves at risk for HIV, as being someone who is anxious and needed information because they had to make a decision about getting themselves tested. We wanted to have them make that decision quickly and to do it on their phones.

Karen:

Some of the people that we talk to who have an existing desktop website or maybe they have an existing m-dot site, they seem to struggle with making mobile first decisions, or figuring out how they’re going to prioritize information, or plan for a responsive redesign. Can you talk a little bit about how you made these mobile first decisions? How did you decide what should be most important, what you should prioritize for a responsive site?

Jeremy:

Well, it definitely started with the analytics and understanding where the most people were going and what their paths were to get there. As I mentioned too, I think we really took that personal use-case as an example that people were seeking personal information.

The other piece of it, that we looked to a lot, is Pew Internet does a great job of pushing out a lot of information, not just on how people are using the internet, but how people are using the internet in the context of health decisions. There were some really good statistics from Susannah Fox, of the Pew Internet project, where she talked about how people, especially people in a health crisis, were turning to their phones. I think the number she cited was that, of people who have searched for health information on their mobile phones, forty percent of them went to their mobile phones because of a health crisis. We thought about, specifically, of people who felt like they had put themselves at risk for HIV, as being someone who is anxious and needed information because they had to make a decision about getting themselves tested. We wanted to put the right language in front of them to be able to have them make that decision quickly and to do it on their phones.

We still have to sometimes challenge ourselves to remember mobile first. It’s always an ongoing education and an ongoing challenge. We use data and we use ongoing conversations to make sure that we’re thinking about where our users are, regardless of the device.

So it meant making some mobile first decisions like connecting them directly with our HIV service locator, prioritizing that as a use case. Then also we did have to rethink some of the other components of the website. So we had a podcast gallery that was Flash-based, and we knew that we were going to have to rethink how we were going to deliver that to people. So we had to basically restructure that. The bottom line for us was that we made the use case with a determination that if it wasn’t going to work on mobile then it was going to be broken and we were going to have to prioritize the mobile use case first.

Miguel:

Jeremy, it was also really nice that your team annually worked to do usability with our target audience, not just the general public looking for basic AIDS information, but even the policy wonks who wanted information about policies and procedures. So you had incoming data coming to you throughout the year about what was working, what wasn’t working, on both desktop and mobile, which I thought was also very, very helpful for us as an entire team.

Our traffic in 2010 and 2011 on even our m-dot site, we were only seeing maybe eight to ten percent, maybe fifteen percent at the peaks, from mobile devices. It was about twenty-five percent when we launched. As of this month we’re at about sixty percent mobile traffic across the AIDS.gov website.

I also think what’s important is that we still have to sometimes challenge ourselves to remember mobile first because of the bulk of individuals coming to our page. It’s always an ongoing education and an ongoing challenge. We use data and we use ongoing conversations to make sure that we’re thinking about where our users are, regardless of the device.

Jeremy:

Miguel, to a certain extent, our traffic in 2010 and 2011, even to our m-dot site, we were only seeing maybe eight to ten percent, maybe fifteen percent at the peaks, from mobile devices, of the overall traffic to the website. When we pushed to responsive design we saw an uptick almost immediately, but since then it’s actually completely overwhelmed us. So when the site launched in 2012, we were at about twenty-five percent mobile traffic—and this would be mobile only, we’re not taking tablets into account for what we’re saying is mobile. So it was about twenty-five percent when we launched. As of this month we’re at about sixty percent mobile traffic across the AIDS.gov website specifically.

One of the things that we definitely had to rethink a number of times was both the navigation and then also how we’re going to get people to the different services for AIDS.gov.

Ethan:

That’s marvelous! I’d like to hear a little bit more about the actual design process. So, you know, Jeremy as ICF International is actually starting to talk about the creative direction for this site, what the responsive layout is going to do, how you’re actually introducing that design to Miguel and his team at HHS, are you showing mock ups? What are some of the tools and deliverables you use to talk about responsive design?

Jeremy:

Yeah, that’s good. We had regular updates with Miguel, just to talk through how we’re approaching the responsive design. It really started with the content. So, we worked with the content team at AIDS.gov to begin hashing out what each template was going to look like.

We had a good baseline because of that m-dot site where we could say, okay, we’re going to lay this all out in a linear fashion and this is what it’s going to look like. We were really focused mostly on the content pages as opposed to the homepage itself. So we knew the homepage was going to be a bit of a different animal. The things that I think we struggled with on the redesign were, we had our content pretty well organized. The things that we had a hard time figuring out were the navigation and also how to prioritize routing some of the users to some of the different services.

We initially laid out everything and had some wireframes. What we did for the wireframes we had both a desktop and and a mobile version that we worked through. And then we actually, once we had those wireframes done, we did some full design mock ups in Photoshop, got that done and immediately tried to start really doing the coding for it. Then we would share that with the team. We’d had a staging site that we had everybody take a look at and review.

One of the things that we definitely had to rethink a number of times was both the navigation and then also how we’re going to get people to the different services for AIDS.gov. I think as a team, we ended up going through about four or five different iterations on the navigation itself. The AIDS.gov website is actually fairly deep. We go, I think, six levels deep in some of the navigation. We found that just really hard, in terms of how we’re going to get people to those content pages that are a lot deeper in the website, say if they are starting from the homepage or even if they are starting from a completely different section of the site. The team had a pretty good idea of how we were going to lay things out on the content side, especially with most of our basic information pages but it was the stuff around the content that we had a hard time really prioritizing.

One thing actually happened is it made it a little easier because we weren’t having to publish to two sites. In terms of publishing within the CMS it made it a bit easier.

Karen:

Let me follow up on some of those comments you made about the content. I would love to know a little bit more about how you worked with the content creators at HHS. I know you mentioned earlier that the content management system that you’re using was pretty well set up for responsive. Can you say a little bit about how the publishing process might have changed based on this responsive design?

Jeremy:

One thing actually happened is it made it a little easier because we weren’t having to publish to two sites. In terms of publishing within the CMS it made it a bit easier. The good thing about the content management system we had was that there weren’t dependencies set up within either the WYSIWYG editor or some of the other components on the CMS to create specific styles on the page and things that would break the layout once it got out to different breakpoints. So the CMS set up I think was actually pretty straightforward, in the sense that we’d worked on the CMS actually since the inception of the website. We knew what we were doing and we had a pretty good way of laying out the front end and then just being able to push the content there.

We’ve worked so closely as a team for quite a while that as a technical team we’ve learned to kind of anticipate what the content folks were looking for and vice-versa. So the responsive design was kind of just an outflowing of a process we had in place for a while.

As far as working with the content team itself, we meet so regularly as a whole team across AIDS.gov. So, the communication side of the team, the content side of the team, the policy side of the team, and the technical team. We were always talking about responsive design. We had just these regular touchpoints as a team to say, “okay, here’s what we’re doing, and here’s what we’re thinking about,” and then regularly educating each other. We would also hear from the content people about, “hey, you know, this is a real priority, we feel like we need to communicate this well.” We’d hear that as a technical team and we’d want to actually find a solution for it. It’s interesting, we’ve worked so closely as a team for quite a while, that as a technical team we’ve learned to kind of anticipate what the content folks were looking for and vice-versa. So the responsive design was kind of just an outflowing of a process we had in place for a while.

Often what I’ve seen happening with my colleagues, is suddenly a team will come in and say we’re going to do responsive design and the person who is doing the monitoring of the contract or the work doesn’t even know what that means.

Miguel:

Jeremy, I think you are so right because what I love about the philosophy and approach that you and the tech team have taken is, you know, keep us educated, keep us educated on the content side. From the very beginning, let us know all the key elements of what responsive design is about, how it will impact the user, and what you need from us. And then the conversation then flips, and we’ll share that this will work or this won’t work. The fact that we meet collectively actually every week and periodically together as a group, really creates a cultural environment that allows us to work together.

Often what I’ve seen happening with my colleagues, is suddenly a team will come in and say we’re going to do responsive design and the person who is doing the monitoring of the contract or the work doesn’t even know what that means. And so it’s a delay. Or they don’t know how to challenge it if things need to be improved.

In today’s world, if you are not part of the technical conversation from its beginning, you’re wasting labor hours and time.

I think what’s so important is that so many of the folks that listen to your podcasts, my guess may be more on the technical side of the street versus administrators and policy folks. Just really drilling into our administrative policy and those doing governance of programs, how important it is that in today’s world, if you are not part of the technical conversation from its beginning, you’re wasting labor hours and time.

Ethan:

I want that on a T-shirt officially. That’s wonderful line, Miguel. That’s perfect. I’d be interested to hear a little bit now that you have this wonderful site up and running that’s responsive and beautiful and providing a great service. What have you learned from the process that’s gotten you up to this point? Are there things that, if you were redesigning AIDS.gov tomorrow, what would you do differently? I’d love to hear from both of you on this one if that’s an option.

Responsive design is a tool to help the user, and we have an ongoing list of everything users would like more of. The good news is that the tool of responsive design speeds up the dialogue with the user, trying to see what we need to do better.

Jeremy:

We’ve made small iterations through the entire process. I think we’re constantly learning from the site. At the same time, there are some bigger things that we have on the site that we understand aren’t necessarily working as we’d intend them. I’d point to the homepage as probably a number one place where we have a lot of information that’s really important to the program—and it’s important not only to the program in terms of making people aware of it—but it’s important to the program in the sense that it needs to be out there because this is what the federal government is doing for HIV/AIDS. So since the launch of the responsive design, things like the National HIV AIDS strategy have been really at the forefront of what the Obama administration is doing for HIV and AIDS. And we get that information on the homepage. We find ways to put it into the content, but I suppose one of the drawbacks to our approach is that we haven’t been able to, within the context of some of the content we have on the site, suggest other places for people to go on the site.

We’re definitely seeing both from the homepage and the messaging we’re getting there, specifically in the carousel and the basics content where most of the traffic is going, that we’re not seeing those people pick up those messages and actually dig deeper into the site on some the specific either policy or federal initiatives that are going on around HIV and AIDS.

It’s not just that individuals are looking for HIV information, but that incredibly busy policy maker in a state legislature. Or individuals concerned that they’re at risk for HIV and are so scared and so shaky that they’re only staying on the page for a few minutes, and if they don’t find it they’ll bounce off the page.

Miguel:

It’s Miguel again. Responsive design is a tool to help the user, and we have an ongoing list of everything users would like more of, and have it provided in different ways. And so, I can’t really answer your question because I want everything different almost every day. But, the good news is, is that the tool of responsive design allows us to at least get the user to be able to say, “well, information here, I want it this way” or “I’m not getting this information.” It speeds up the dialogue with the user, trying to see what we need to do better. I actually think that’s the best way to answer what we’d do differently is “everything” because if you’re not believing that every day is a day for continuing ed, and the learning never ends, you’re not supporting the users.

So I would support 100 percent what Jeremy just said. I’ll just say that it is one of the “it” tools—that “it” being responsive design—to help us constantly move forward, be faster, and get critical—not to sound dramatic—but get lifesaving information to people when they need it. Also make sure that it’s not just individuals that are looking for HIV information, but that incredibly busy policy maker in a state legislature, and some legislation is going to pass and they need clean information, quickly, about policy, that it doesn’t take long to get it, because a vote is happening in ten minutes. Or individuals concerned that they’re at risk for HIV and are so scared and so shaky that they’re only staying on the page for a few minutes, and if they don’t find it they’ll bounce off the page. That’s not good.

Jeremy:

I’ll specifically talk on the technical side of things. One thing I think we would definitely consider making a change on is just how we handle navigation on the site overall. We’ve seen within the main basic HIV information content pages—and even on the federal resources and stuff—we have a sticky navigation that goes with the user on the desktop. But it also stays at the bottom and just kind of sits at the bottom of each article on the mobile view. People are using that a lot. They aren’t using as much the hidden menu that we have on the site. So the menu that you can navigate almost anywhere on the site, we’re not seeing as many people use that as much as the information that’s right in front of them. So if they’re on the signs and symptoms page for AIDS.gov, they are clicking on “How Do I Get HIV/AIDS,” or they’re going to the statistics page, or they’re going to “Reducing their risk for HIV.” They’re going to these pages that are much closer to them and are actually presented to them on the page versus doing the exploring through the navigation we have. So I think one of the primary things we’re really trying to rethink is making sure that the information that’s relevant is on the page right from the get-go. Even if it’s something that’s on a different part of the site.

Miguel:

Jeremy, is there something to add about how photos and infographics impact what you just spoke to?

Jeremy:

That’s true, and one thing that we definitely noticed, too. On the basics pages themselves, we have a lot of different kinds of pictures, and if you look at it, the pictures just illustrate a lot of the things that actually are in the text, and they’re at the top of the page. We definitely noticed that people were trying to click on it, but we hadn’t actually enabled any clicking, because most of the information that’s there is actually on the page. So we decided when we noticed this, that we were going to allow people to actually use those images to navigate, and people really started to use them, too. So that was another key finding, or a different thing, is making the graphics that we have on the site more interactive.

Karen:

Well, this has been amazingly helpful and interesting, and I’ve really enjoyed listening to both of you talk about why this is so important for the audiences that you’re trying to reach. So thank you very much for taking the time to talk with us this morning.

Miguel:

Thank you.

Jeremy:

Thanks for having us.

Ethan:

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

We’re really excited to announce that we’re offering public workshops on responsive design, taking place on March 06 in Boston, and on April 2-3 in New York City. If you’re interested in attending, visit responsivewebdesign.com and register for a ticket today!

And 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. If you’re interested in bringing us to your company, please go to responsivewebdesign.com and let us know that you’re interested.

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 again to our sponsor, Campaign Monitor. Be sure to visit campaignmonitor.com and check out their email editor, Canvas. Thanks for listening, and we’ll be back next week.