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, Karen and I are high-fiving ourselves madly because we are incredibly excited to speak with Justin Lucas, who is the audience and community relations manager at NPR. Justin, thanks so much for joining us.

Justin:

Thanks for that warm welcome. Happy to be here.

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.

It’s clear to everyone that accessing websites via tablets or mobile devices is pretty commonplace and it’s a part of everybody’s life, and it makes sense to people that you would design a site around that.

Ethan:

Justin, could you maybe just introduce yourself and tell us a little bit about how responsive design has influenced your job lately? What have you been up to?

Justin:

Sure. Well, the way that responsive design has been influencing my job—I would say that for the last few years, as NPR.org has been undergoing changes towards responsive design, I’ve kind of been on the sidelines of it, watching it happen and experiencing it more from the perspective of seeing our audience’s response to that. So, getting the earliest feedback from our very, very first responsive redesign of the website, as a person who heads the team that responds to audience emails sent to NPR, I would see the early feedback about the site design, and it’s been interesting to see that evolve over time.

Initial reactions, people are always a little uncomfortable with change, and there might’ve been some early feelings, like “You’re designing your website for the few; you’re trying to make it mobile compatible—I see that you’re doing that, but most of us are still on desktop computers.” Over the last few years, that feedback dropped off rather quickly and I think that it’s clear to everyone that accessing websites via tablets or mobile devices is pretty commonplace and it’s a part of everybody’s life, and it makes sense to people that you would design a site around that at this point.

So it’s been interesting to see that change, and I would say that, if anything, getting the contact pages set up that way, and our help pages, has been the final component. I think we were the last piece of NPR.org that wasn’t responsive, and part of the reason for that is that we’re not actually technically a part of NPR.org, and I can explain that later.

Everybody is behind responsive design; everybody wants the help pages and the contact form to look and feel apiece with the NPR website.

Ethan:

Oh, well that’s really interesting, because you mentioned the help pages, and I think help.npr.org was the reason we dropped you a line in the first place. As one of the last properties to go responsive, I’d love to hear a little bit more about what drove that decision. Were there any stakeholders who needed some convincing on why to go responsive? Or what influenced the timing for launching the site at this point?

Justin:

Sure. I’m definitely the lead in terms of trying to figure out what it is that we need to do with the help pages and contact form, but I certainly answer to some people. I think everybody is behind responsive design; everybody wants the help pages and the contact form to look and feel apiece with the NPR website. So, the struggle isn’t so much to make people understand why responsive design is good, it was simply, “How are we going to execute it and what’s the pain point?” Because for us, the contact form and help pages are actually wrapped into a whole larger email management system, so it’s not just the user interface, it affects the entire way that we receive feedback from our audience. So there’s a complex system for whenever anybody uses the contact form, it has to be routed to all sorts of different internal departments.

There are a lot of moving pieces, and we’ve got live feedback rolling in the whole time, so you have to look at it comprehensively.

NPR is kind of a unique beast because we’re not business-to-business or business-to-customer in the traditional sense that most companies would deal with. We’re media organization-to-audience, so it’s a very different type of relationship and there are a lot of complexities involved in that. So just making sure that it not only looks good and works the way we want, but that it also works well on the back-end and gets audience feedback to where it needs to go. And that’s a large undertaking and there are a lot of moving pieces, and we’ve got live feedback rolling in the whole time, so you have to look at it comprehensively, if that makes sense.

Karen:

Let me follow up on that, because I think it’s an interesting segue into a conversation about all of the digital touchpoints that NPR operates on. I think the website is an important front-end, but I think NPR also is well-known for having a variety of different platforms. So you’re on apps and you have players, and you’re really trying to reach your listeners or your audience wherever they are. How does having a responsive site for audience support or customer support fit into that overall digital ecosystem, if I can call it that?

Justin:

Yeah, you hit the nail on the head: we’re receiving mail about a lot of different content and products. So we’re not only receiving contact from our audience about NPR programming but also about all of our apps, about our website, really about everything that NPR does. And for me, the primary goal is always just to remove barriers to contact; we want to make sure that our audience can reach us and we want to make it as easy as possible. So, I would say that one of the most compelling figures towards responsive design for us is you get Google Analytics, and I know that just looking at that every day, roughly half of the people that visit NPR.org—not our apps even, just NPR.org—are using a mobile device or tablet. I think when you add the two together, it’s half or even more than half of the people visiting NPR.org.

If you need to limit your content in order to have a separate mobile site, you have one of two problems: you’re not giving people enough or you have too much.

So if that’s how people are getting to us, we need to make sure that we’re serving those people, and having a separate website or a separate contact form or separate help pages for mobile usually under serves in one way or another. Either you end up offering a light version of your content, or… Basically, if you need to limit your content in order to have a separate mobile site, you have one of two problems: it’s either that you’re not giving people enough on their mobile devices or you have too much on your desktop site, if that makes sense.

If you’re building a page piece by piece, implementing a change here and there as needed, you can end up with a Frankenstein site.

Ethan:

Justin, tell me a little bit about how you actually got your arms around the scope of this responsive redesign. I mean, when you were actually starting to think about taking this established audience-focused site like help.npr.org, how did you actually think about translating it into something that could be a little bit more device agnostic?

Justin:

I think that over the years we’ve sort of—you can run into issues where if you’re building a page piece by piece, implementing a change here and there as needed, you can end up with a Frankenstein site, where all of these additions aren’t necessarily improvements in aggregate.

We knew we wanted to implement responsive design, but we also didn’t want to just stretch responsive design over what we had, we wanted to rethink all the content that was on those pages.

What I really wanted to do was step back and take a look at everything we had and figure out are we doing everything the best way we possibly can, and is everything that is here something that needs to be here? Is anything overcomplicated? Are there any new features that we haven’t considered that we should? And so really, in the past year the process for me was, if I could just knock this whole thing down and build it from scratch, would it look anything like what I have? So we knew we wanted to implement responsive design, but we also didn’t want to just stretch responsive design over what we had, we wanted to rethink all the content that was on those pages.

Then it just became a question of: What does a better site look like? It really just started out with simple brainstorming.

Karen:

Say more about that. I’m really interested in how you planned a rollout strategy. Rollout strategies are one of the things that’s most interesting to me, because some organizations do opt for the Frankenstein site model, other organizations roll things out—like they launch in beta, so they have two sites to compare to. So you mentioned that help.npr.org was the last part of NPR.org to go responsive. Can you talk about how that planning and rollout process was scheduled and managed?

Justin:

Yeah, because we’re separate from the website, it kind of falls completely in our hands, and I think that, frankly, we just had our hands full. We had gone through some changes in staffing over the last few years and there just wasn’t really time to step back and look at the bigger picture. But it definitely needed to happen, and especially once we realized that the entire rest of the website had been redesigned. I was looking at our help pages and our contact form, and they looked like the 2009 version of the NPR website. So we were many years behind on our design and we knew we had to fix that.

So then it just became a question of: What does a better site look like? It really just started out with simple brainstorming. I had heard through a number of contacts in the building that one of our UX designers on the digital media team at NPR had done some wireframes for a contact form, I forget exactly what for, but it wasn’t for the larger NPR.org contact form, it was just some ideas that he had about contact forms in general. And I went and talked to that designer, Vince Farquharson, who works at NPR, and just told him that I was trying to reimagine the contact form and help pages at NPR, and I’d be curious if he could share his wireframes or if he had any feedback. And a happy kind of coincidence of that moment was the digital media team was just about to go into their “serendipity days”—should I explain serendipity days?

Ethan:

Yeah, please.

Karen:

I insist upon it.

I’m coming at it from a firm basis and understanding of what it is that our users need, what our audience is looking for in a contact form.

Justin:

[laughs] Okay, so serendipity days at NPR are basically born out of the same sort of ideas of the “twenty percent time” that you may have heard of at Google, where periodically throughout the year the digital media team—and folks from other areas of the organization, but predominantly the digital media team—get about three days to brainstorm a project. It’s a very quick and dirty process of coming up with anything that you want to work on, anything you want to investigate. You’ve got a couple days to plan it, to create some sort of outline, and then at the end everyone gets together and does a three-minute presentation about what they did and what they learned.

It happened that when I went to talk to Vince and our digital media team about our idea to redesign the contact form and help pages, it was the week before a serendipity day time period. So, he offered to give me his time for that, very generously, and we put our heads together on what an improved version of those pages would look like.

What we ended up with, when we finally implemented everything, was remarkably similar to what we came up with in those brainstorming sessions.

It was, I would say, a really great combination of talents and knowledge and skills, because I’m coming at it from a firm basis and understanding of what it is that our users need, what our audience is looking for in a contact form, and I’m pretty familiar with what it has to be able to do, what type of information that I need from the pages, and what type of information I have to present. As Vince put it, I “understand what the weight of all the components are,” and he has clearly the more firm UX viewpoints and just knowledge about how to properly build a page, what good design looks like and also just what NPR’s web design looks like.

Putting those two things together, we came up with a pretty quick draft of what the help pages and contact form could look like if they did everything we would want them to, sort of a dream build of it. And what we ended up with, when we finally implemented everything, was remarkably similar to what we came up with in those brainstorming sessions.

We sat in a room with some Post-its and a whiteboard and talked about “Let’s list what we need it to be able to do.”

Ethan:

Justin, I’d love to hear a little bit more about that process, specifically how you migrated from early wireframing and sketching into the finished design. I mean, if it’s not too deep in the weeds, I’d love to hear a little bit more about some of the applications and tools that you and Vince used to talk about the design. And what were you using to create mock-ups? When did you start prototyping?

Justin:

We sat in a room with some Post-its and a whiteboard and talked about “Let’s list what we need it to be able to do.” So, what’s the information we need to get from people, what is it that we want out of these pages, and what are the things we wished we had that we don’t have, what are the things that can’t be gotten rid of? And what are the problems that we want to solve, so what’s not working right now that could be better? And we sat there with all that info and just basically pretty much sketched out a diagram on a whiteboard, which Vince then photographed and took back and did a PDF mock-up of, then we kind of edited down that mock-up. We’re talking about two days of work and then one day to just present it, so it all happened pretty quickly.

Ethan:

That’s fantastic. Well I guess now that help.npr.org is live and out there, and you seem to be keeping a pretty close beat on what your users are asking for, I’d love to hear if there are any parts of the site that you’ve had to rework since you’ve launched it. Anything you’ve learned from audience patterns since it’s been launched? Just curious to see how it’s evolved since then.

Justin:

Very few things have needed to be reworked. It’s gone remarkably well. I think one thing that we left off—I mean, this is so minor—is that for the weekend edition, Sunday, NPR does a very popular feature actually which accounts for a huge volume of mail to NPR, which is a Sunday puzzle. So each week, Will Shortz—who’s also more famously probably the editor of the New York Times crossword puzzle—does a live on-air challenge, usually some sort of riddle or quiz, to which our audience members then send their answer. It’s the only time where we ask anyone for a phone number because we call the winner and talk to them on air the following week, and I had not put in a phone number field and people were panicking about where they could put in their phone number to make sure that they had a chance at being called as a winner for the puzzle. So, we very frantically and quickly added that field back in for people about one day after launch. But other than that, there haven’t been many hiccups, it’s really gone quite well. And I can definitely talk to you more about just sort of the decision-making about what we wanted to add in and leave out of a form, and what the problems are that we were solving there.

We had to look at everything as though we are the outside user, as though we’re the audience member trying to contact us.

Karen:

Yes, let’s do that now! [laughs] I would love to hear just more about the process that you mentioned earlier for making choices and prioritizing what you wanted on the form, and also going through all the content and cleaning all that up. Tell me how that worked.

Justin:

Sure. We had to look at everything as though we are the outside user, as though we’re the audience member trying to contact us. And it’s not that hard to do, because any time we’ve had to test any change, we have to go through our contact form and try sending an email every way possible just to make sure everything works, or go to our help page and make sure we can find the answer to a question we’re looking for. There were certainly cases where we were trying to do that and it was just a painful process; the form was taking way too long to fill out and there was no logic to it. We had just one page with all of the fields kind of splayed out across it and there’s no feeling of being guided through the process—what information do I need to put in, in what order, and why?

My experience was that we were getting a lot of emails, for example, sent to the wrong department, and the presumption is that it’s because people go to a form and they know “I’ve got to put in my name, I’ve got to put in my email address, and then I want to put in what I want to say to you.” Anything after that is something that I don’t particularly want to do but that you might be asking me to do, and if I get to those steps last, the tendency is going to be to just sort of button mash. Just imagine if you call into a phone tree and you know you want to talk to a person, you just start pressing zero over and over again, hoping you’ll get somebody. The problem is that if people send their contact to the wrong department at NPR, it might take us twice as long or five times as long to respond to them while we kind of track down their email, figure out what it’s about and get it to the right department.

We wanted to really strip it down to “What information do we really need?” As much as possible, whatever fields that are there are required and there are as few of them as possible.

One of the big things we wanted to do was just make it more of a guided process, more of a step-by-step, and to just remove as many fields as possible. We wanted to really strip it down to “What information do we really need?” We did away with subject lines, we did first name/last name is just one field, so full name; just in general trying to make sure that, as much as possible, whatever fields that are there are required and there are as few of them as possible.

Finding ways to get people to that content faster was super important.

Then in terms of help page content, we were able to implement one of the features we had most hoped to be able to create, which is the ability for the contact form to actually, based on what selections you make and based on keywords you enter when you contact us, suggest help articles to you. Because we do want to remove barriers to contact, but we also want to make sure that our audience isn’t waiting two days to get an answer to a question that’s explained completely adequately on our help pages. Finding ways to get people to that content faster was super important.

We want to make sure that the help articles we have are actually about NPR content. When you focus the information, it’s easier to get the right answer.

Another thing that was important was with the hindsight of 2015, as opposed to say a site that we built in 2009, knowing what content people actually need explained to them on a help page. What we did away with a lot was explaining the internet to people. We had a lot of articles that would say how to delete your cookies or cache from your computer or how to make NPR your homepage, and I think that at this point we were really able to step back and say, “At what point are we condescending to people or explaining the internet to them?” We want to make sure that the help articles we have are actually about NPR content, and by just getting rid of that superfluous content, that “explaining the internet,” we were able to really just focus the information that’s there. And when you focus the information, it’s easier to get the right answer.

If you’re going to a help page or you’re going to a contact form, it’s not your favorite place to go. I wanted to make sure that those pages are an enjoyable experience, but also without needless bells and whistles.

Ethan:

Justin, I’d be curious: did you have to circulate the responsive design to any other parts of NPR? And if so, how did you actually manage that process?

Justin:

Sure, yeah. So I started out with some of the basic skeleton that I had come up with with our UX guy, Vince, during the serendipity days, but then I wanted to make sure that I had some time to really just get the look and feel of it right. I come from a little bit of a print and graphic design background, less of a web design background, so I feel like if you’re going to a help page or you’re going to a contact form, you’re already not often in the best mood, it’s not your favorite place to go. I wanted to make sure that those pages look nice and that they’re an enjoyable experience, but also without needless bells and whistles.

I went around NPR.org and just looked for some of the more pleasing design elements I could find, and I pulled a lot of the touchstones for what the contact form and help pages look like from other elements that existed at NPR.org. So immediately the thing I wanted to do after that was go to folks like Scott Stroud and Patrick Cooper, whom you’ve had on this podcast as guests, and asked them, “First off, is it okay to use those design elements in the context that I want to use them in?” Because often, there can be restrictions on how certain buttons should be used and in what context, and what they should look like when you use them. Basically at all steps I would create a design, draft it, and then take it down to the digital media folks and all of our web developers and say, “Is this okay, and what’s your feedback?” And they were extremely helpful all along the way on outlining what an NPR page should look like and giving me great feedback and tips as I developed the site.

If we start to see fewer of the types of questions we have answered on our help pages, that’s a great sign.

Karen:

Justin, if I know anything about people who work in customer support, it’s that you have a lot of data about the types of requests that you’re getting, and you’re really doing a lot to measure and track what sort of messages come in. How do you measure the success of this responsive redesign? How do you know if it’s working?

Justin:

That is a good question. I think we’re just starting to figure that out. So, what I have is a lot of information from, say the past year, about how many people were contacting us and just how long it takes us to respond and what types of questions we’re getting. I think that if we start to see fewer of the types of questions we have answered on our help pages, that’s a great sign.

I’d rather hear from the people who are frustrated about something very specific or about programming or content than hear from people who just have a really simple usability question.

I’m also just looking for increased turnaround time. I would say that we’re hoping that more people will be contacting us, just more people with questions about things that we can’t answer on our help pages. And we’re hoping we hear—and maybe this is counterintuitive—but I’d rather hear from the people who are frustrated about something very specific or about programming or content than hear from people who just have a really simple usability question, because we should be addressing those things up front; those usability questions should be things that you can find answers to easily on our help pages, you shouldn’t need to contact somebody and wait for an answer.

And I should say that each week—I lead a small team of people, and we answer most of the mail that’s sent to NPR. There are a few exceptions. There’s the ombudsman that is almost like internal affairs for media organizations; sometimes ombudsmen are also referred to as public editors. They use the same form that we do, the form that I built, but they answer their own mail. Our corrections department clearly gets their own mail. And all mail sent to NPR programs go to those shows, but largely my team is responding to all of the folks that are writing in to us. So through this form and through these help pages, we’re trying to intercept as many people as we can and just get them information automatically if it’s the right answer to their question, but we’re also personally responding to about a thousand NPR listeners per week.

It’s just important to imagine yourself as the user. It’s easy to forget to do, but it’s not that hard to do if you remember to do it.

Ethan:

Justin, I’ve got to say, this has been an amazing twenty minutes chatting with you. We’ve really appreciated your time, and just hearing a little bit more about the help site’s evolution has been great. Just as we start to wrap this up, I’d love to hear—do you have any lessons that you’ve learned over the course of this responsive redesign that you might share with our listeners? If you were starting a redesign today of NPR’s help site, what are some things you’d like to share with them?

Justin:

It’s just important to imagine yourself as the user. It’s easy to forget to do, but it’s not that hard to do if you remember to do it. It’s just to think about what would you want if you were accessing a site? What would seem helpful to you? When you’re going to sites, what’s useful, what do you wish was there? I feel like it’s just often much more simple than we would maybe expect it to be. What absolutely needs to be there; what does a good site look like?

For me, it’s all about removing barriers to contact, and the easiest way to do that is just to put yourself in the shoes of the person using your site.

Especially for help pages and a contact form, you don’t want to overcomplicate it. So my use case is very specific, but I think that it’s extremely important to have something that’s just—you want it to look good, but above all you want it to be functional. You don’t want to have to have a help article to explaining how to find help articles on your website, you don’t want to have people contacting you to figure out how to use your contact form. It should all be very intuitive and you should feel guided through the process, and it should be simple and quick. Again, for me, it’s all about removing barriers to contact, and the easiest way to do that is just to put yourself in the shoes of the person using your site.

When you’re talking about accessibility issues, it’s not a consumer choice when people have those needs, so it’s important to rope that in early in the design process.

I would say also, just as a sidebar, that we went to great lengths to try to make sure that we incorporated accessibility into our design, and I think that it’s extremely important that everybody designing anything for the internet always thinks about that. It’s easy to get caught up in thinking about user bases—so, “How many people use this phone? Do we need an app for this phone?” But when you’re talking about accessibility issues, it’s not a consumer choice when people have those needs, so it’s important to rope that in early in the design process and make sure it’s not something you’re going back to fix later.

Karen:

Justin, I learned something today, which is that apparently everybody at NPR is a fantastic interview guest. This has been amazing. I don’t know what they have in the water over there at NPR, but you have been so interesting to listen to, and I really thank you that you took the time to talk to us today.

Justin:

Ethan and Karen, it was my pleasure. Thank you so much for talking to me.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, Harvest. Go to getharvest.com and start tracking your time, painlessly, today.

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.