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, guess who we have to talk to? We have Perry Hewitt, who is the chief digital officer of Harvard University. Perry, welcome.

Perry:

Thank you very much for having me.

Karen:

So, Perry, please just start out by telling us a little bit about yourself, what your role is at Harvard, and maybe talk a little bit about how you oversee the digital experience.

Perry:

Great, my background: I’ve been fortunate to play a number of roles, both in sort of the software side of the business, the agency where we initially met, at Razorfish back in the day, and at Monitor Group. And also to work with big brands, helping them to think about their digital strategy. And here at Harvard the lens is very much: how do we think about using digital, these weird new technologies and behaviors, in a way that makes sense for us to communicate and engage with public, media, and alumni. So that’s the primary focus. I also work a little bit on the academic initiatives to think about what does the social media and digital world mean for these worlds we’re now living in? And, how do we begin to incorporate that into what we do?

Karen:

We’re here today, as you might have gathered, to talk about responsive web design. But before we do that, Ethan’s going to say a few words about our sponsor, Campaign Monitor.

Ethan:

We’re both very excited that Campaign Monitor is involved with the podcast. It’s especially timely because they have a new email builder that they call Canvas. What I like about Canvas is it’s based on styles, not canned templates. So the nice thing about it is that it means the content actually drives the design, instead of constraining you or your designers into boxy, predefined layouts. They do have some preset patterns that you can drop in, and it’s got this really nice, well-executed, drag-and-drop functionality. The nice thing about Campaign Monitor—I’ve been using them for the bulk of my career—they’ve always been great about publishing these fantastic resources for people trying to get into designing HTML email for the first time. So they have this decade’s worth of tricks and hacks to make sure that your letters and emails look and work great across all the various email clients out there. So thanks very much to Campaign Monitor for being involved.

Karen:

Can you talk a little bit about some of the initiatives that you’ve overseen at Harvard to implement responsive design?

For us, responsive design was never an “if.” It was definitely a question of how soon.

Perry:

Sure, for us, responsive design was never an “if.” It was definitely a question of how soon. We’ve been watching our mobile traffic trends pretty aggressively since 2009. I arrived at Harvard in 2009 and the sites were one to three percent mobile and had a pretty poor user experience. But today, with the sort of concomitant rise of social media as a big driver to our site, we realize that mobile is what everything has to be optimized for. So, we started with, I believe, Harvard.edu and Alumni.Harvard. We also worked with the admissions team on their site, recognizing the mobile first behaviors of many of the prospective Harvard college students. And then last summer, did a major responsive redesign of the Harvard Gazette.

Ethan:

That’s fantastic, Perry. I’d be interested to hear just generally speaking, how have you worked with stakeholders and various other product owners at the University to go responsive. What kind of discussions have you had there?

Just as a senior leader in the university would not be pleased to walk in the yard and see all the grass brown, a senior leader of the university would not be pleased to get a daily email and not be able to experience it fully on the bus on the way to work.

Perry:

Again, I do feel like there’s a general understanding of the way the world is moving. And there’s a real delightful emphasis on user experience of our digital properties. Just as we think about the beauty of Harvard yard and Harvard’s campus as a physical space we would not allow to be in disarray. Or in a way, that if you walked onto our campus you would not be able to orient yourselves. We’re really looking at our digital landscape in the very same way. We also look at the numbers. This is a pretty data-driven place. So our social media traffic to the Gazette website, is at least, about forty percent mobile. And, the email traffic that we send, so the Gazette team, the editorial team sends a news email during the academic year every weekday at 7 am. And traffic from that email is about thirty-five percent mobile. So, our users are, to an extent, our stakeholders—they are also users of some of our services. And just as a senior leader in the university would not be pleased to walk in the yard and see all the grass brown, a senior leader of the university would not be pleased to get a daily email and not be able to experience it fully on the bus on the way to work.

Karen:

That’s a great lead-in to ask a little bit about the different audiences that you see for the website or for other platforms that you operate. And, I guess one of the questions I would have is, did you have conversations about what should be a mobile web experience versus what should be an app?

The resource costs of native apps and the ability to update them and keep them fresh is a major constraint. So at times we think about doing them but we’re, we’re not a hundred percent sold in one camp or the other. We really look at the audience’s needs first.

Perry:

In general, we’re big believers in the power of the open web. It’s ideal for social sharing and I think it will always be a cornerstone of our strategy. However, there are use cases where apps do make sense at Harvard. And of course there are wonderful capabilities of native apps. But in a resource-constrained environment we’re always cognizant of: let’s do the thing that services the most users the best, and enhance when and where we can. For example, we have a mobile campus app which we talked to a bunch of stakeholders within the university. Which was a great way to bring together a bunch of disparate features that different people owned on different sites. The amount of time it would take to get those all into one magical website would be another 378 years of Harvard’s existence. So far better to find a way that we could have a native app—and also it worked on open web—that aggregated the content all in one place, and had things like directory look up and took advantage of the native features like add to calendar and add to your own contact lists. So we definitely had conversations. People do wrestle back-and-forth, but the resource costs of native apps and the ability to update them and keep them fresh is a major constraint. So at times we think about doing them but we’re, we’re not a hundred percent sold in one camp or the other. We really look at the audience’s needs first.

Ethan:

Well, that’s fantastic actually! So speaking about audiences, I mean, I know that a lot of clients and organizations that I work with, when they start thinking about responsive design, there’s often a conversation about the needs of the mobile user and the needs of the desktop user. Did that ever come up in any of the responsive work? How do you sort of think about those two needs, I guess?

We’ve all put to bed the concept of a mobile use case, right? It’s really just a use case these days. So what we think about is, not “here are mobile users” and “here are desktop users” but everyone is going to be mobile at some proportion of their time.

Perry:

So I think that we’ve all put to bed the concept of a mobile use case, right? It’s really just a use case these days. So what we think about is, not “here are mobile users” and “here are desktop users” but everyone is going to be mobile at some proportion of their time. Some people that’s going to look more like eighty or ninety percent, for some people that will look a lot more like ten percent. But I think we’re thinking really hard about: what’s the information people need and how do we create systems that get them that information when they need it? I mean there are factors that are unique to mobile, of course, like you know there’s the limitations of your thumb length versus the flexibility of your scrolling mouse augmented by your keyboard’s shortcuts. People in the end need the same information. There’s nothing more painful than being pulled to a mobile template that replicates very little of the desktop. So, I think it’s a trade-off but there are conversations where people are interested in doing a mobile app but we always go back to, “What’s the problem you’re trying to solve for your users? Let’s do some personas to walk you through to what those users may look like.” And that ends up driving the decision.

Karen:

Many of the case studies that have been published about how to execute a responsive design have focused, I will say, in many cases on simpler experiences in, maybe in a smaller site or a blog. When I look at organizations that I think have substantial challenges with implementing responsive design, it’s the organizations that just have the sheer volume of content that’s addressing why the scopes of different needs and different audiences. And honestly, I think there’s maybe no more demanding scenario than higher ed. Can you talk a little bit about perhaps the Harvard.edu responsive redesign and how you made decisions about how to prioritize or what to cut or what to keep? How, how did you wrangle all of that?

Perry:

So a responsive redesign is a little bit like when you buy a new chair for your living room and all of a sudden you look around and say, “Oh my god! How have I been living with that couch?” Or “Who bought those curtains?” and “When was the last time we painted in here?” I feel like the responsive redesign becomes the catalytic moment at which you look at all the other web decisions and web content decisions you’ve made and revisit them all at once. So Harvard.edu is a relatively smaller site because it spins off to all the different school sites. The Gazette site is probably more substantive and that’s was where we really had to think hard about what are the trade-offs, knowing that there’s only a certain amount of thumb scrolls people are likely to do. And inform that with both analytics, use cases, persona development and thinking about, you know, if someone’s a mobile user, through those personas, for example, I would argue that our latest and popular [section] becomes more important information than some of the more in-depth stories lower on the page. So those were some of the trade-offs we made.

Ethan:

That’s fantastic Perry. I’d be curious to hear a little bit about, as you’ve worked on a number of responsive projects by now, has the design process that you’ve used on some of those projects changed over time?

Perry:

We’ve been fortunate in that we’ve always worked fairly iteratively with development and design over time. I mean, one of the things that’s really changed in how we think about mobile in general, over the last three years, is when we’re working either with in-house teams or with vendors, I’ve really flipped the creative presentation, you know, the a-ha moment where the vendor comes in and shows you all the comps. We’ve really flipped it to ask the people to show us the mobile screens and spend the bulk of the time on those and save the desktop for later. Usually mobile is crammed in at the very end. We really want to try and reverse that, because we see the mobile experience is so paramount for many of our audiences. The design and development process itself is a lot of back-and-forth. You want to have the strategy. We sink, probably what some might think to be an unreasonable amount of time upfront in stakeholder alignment and strategy, so that by the time you’re in design and development, you have a smaller group of people making those decisions and you’re able to be much more iterative and back-and-forth and “you know, I thought that the slider for the photo gallery would work this way but you know, on implementation in the prototype, I see that it’s not working that way.” So let’s revisit that concept. But you’re not going back and saying “oh my gosh, you know, not sofas—love seats.” It’s not a wholesale revisiting. It’s more tweaking at that stage.

Ethan:

Man, I love that. So as you guys have been working more iteratively and working with more screens, have the applications or tools changed over time? Are you getting out of Photoshop earlier? What does that look like?

One of the things that’s changed a little bit in our design process, as we think about different devices, is: I love this concept of little-big details, just in general in the world of the web. And, I think in mobile, in responsive, those little-big details become more and more important. You know, what are those small UX moments that can produce real delight.

Perry:

So, I think we’ve always erred toward an early working prototype rather than showing designs in Photoshop, because so rarely can they be replicated. But, I think we have taken a look, in some of our projects at frameworks like Foundations or Bootstrap. To say, what is the work that has already been done in the world that can facilitate what we’re doing? But, that’s not always possible. Sometimes there are a lot of special snowflakes in large organizations. It’s not always possible to implement those. The front end designers have been and continue to use Fireworks primarily.

One of the things that’s changed a little bit in our design process, as we think about different devices, is: I love this concept of little-big details, just in general in the world of the web. And, I think in mobile, in responsive, those little-big details become more and more important. You know, what are those small UX moments that can produce real delight. And, I think of Duolingo, is absolutely best-in-class for that, from copywriting to graphic design. They really figured out that those small delightful moments in a responsive design can really make all the difference. Or in an app, can make all the difference.

Karen:

Another one of the things that I think is so challenging about working in higher education is the range, the sheer variety of different content creators that you have to work with. And so I know your team doesn’t own the editorial process, but, can you talk a little bit about your content management system and the publishing workflow and how you create a responsive design experience that you can have literally hundreds of contributors to?

We’ve always invested heavily in the user experience of the admin content management system screens. It’s probably the least sexy part of a website to many people.

Perry:

So, we’ve always invested heavily in the user experience of the admin content management system screens. It’s probably the least sexy part of a website to many people who want to come in on the big design review process—what will the whole page look like? The stuff that really jazzes our team is, how do we think about an interface that can service the needs of people who are content contributors versus publishers? How do we think about workflow? How do we think about design? And, in all cases, we’re really trying to limit the clutter that appears on those screens and optimize for the most common outcomes. I see large CMS projects fail at times because people are optimizing for every single fringe case that might sometimes happen. You have to make hard decisions around those admin use cases and really make sure the system works best for those who need it the most. We have the alumni site which has a large number of contributors. The Gazette site has fewer. Harvard.edu has still fewer. But, we try to design a system and definitely work with people as the system is being designed to understand what their use cases are. And to, again, iterate around that.

Ethan:

So in talking about that collaboration, from a design and development standpoint, have you learned any lessons from how designers and developers are working with the content team, from your first responsive project to this one, to the latest one?

I feel like we really learned that the more time you can spend on the strategy, the quicker your development cycles can go in subsequent editions. You want to find out the behaviors you want to incent upfront and allow that inform your design and development.

Perry:

I feel like we really learned that the more time you can spend on the strategy, the quicker your development cycles can go in subsequent editions. You want to find out the behaviors you want to incent upfront and allow that inform your design and development. Much more than if you went, “how do people feel about the color green?” Or, “I like buttons that look like this”. I think that if you have the strategy in place up front, that’s probably a lesson we learn and relearn every time. You identify what are the behaviors you want to incent, then you design your analytics programming around those behaviors. And then you can make the case with the numbers.

Karen:

You said earlier that you spent a fair amount of time getting your stakeholders aligned earlier in the process, so that the design process could be operating with a smaller team and thus go more smoothly. Can you talk about how the review and feedback process worked with the larger team of stakeholders? How did you socialize these changes? How did you get their input on perhaps where things fell at different breakpoints or other things they might have questions on?

Perry:

I think people were really curious [and eager] to say, “okay we identified these four behaviors as the things we really want to incent.” And they really wanted to listen and learn and understand how the mobile design would support those. So we definitely brought the stakeholders back in at I would say the late prototype stage. Not the “oh we’re so early were still batting ideas around” stage and not the “oh my gosh this is almost done we really hope nobody says anything” stage. So it’s sort of the late prototype stage to say: okay, these are the behaviors you want, this is our preliminary data on how this version of the mobile responsive experience is driving that behavior, how does that feel to you? And I think if you keep going back to the personas, and if you keep going back to the behaviors, of course we tweak and make minor changes at that stage, but that can really inform a smoother process throughout.

Ethan:

Perry, have you found that your stakeholders are fairly comfortable reviewing the design in a prototype form or was that a bit of a leap for them?

I’m really happy to have a meeting in which people have nice color printouts which they can touch and feel, and there can be an interactive demonstration on a screen and a couple of devices being handed out around the room so people can experience that way.

Perry:

I think it’s a bit of a leap for many, so we keep trying to multi-modal experiences in review processes. So I’m really happy to have a meeting in which people have nice color printouts which they can touch and feel, and there can be an interactive demonstration on a screen and a couple of devices being handed out around the room so people can experience that way. I feel like you need to—just as there are visual learners and oral learners and different kinds of learning styles—I feel like you want to conduct your review meetings to suit all those cases so that people aren’t poking holes or feeling excluded because, for example, they’re not as fluent with the touchscreen interface. They can comment on a piece of paper. I think that’s just an inclusive and smart way to engage people around decisions.

Karen:

Can you talk a little bit about the testing process, like usability testing that you might have conducted for example?

Perry:

We do not have a formal QA team. We’re lucky to have snagged a wonderful project manager from a local agency, with what I would call a sinister bent for QA. She’s a terrific ringleader in terms of bringing groups together to look at the final versions of the site. When we are still in the design and development process, we often open it up to small groups. The key is to keep—as they would say in science—the control group pure. So we do not want people who have anything invested in the design either way, because sometimes they’re terrific spotters of issues that all of us who are too close to it might not be. Occasionally we’ve done more formal usability testing but we do not have an in-house lab, or nor do we have a large equipment bank that we’re able to use.

Ethan:

That’s great. Would you say that designers and developers are starting to incorporate devices, even on an informal basis, as they’re working on the design?

There’s much more collaboration between content creators, designers, and developers to create a final product, because each group can inform each other on what’s going to resonate best and work best.

Perry:

Absolutely. I think there are so many blurred lines in what we all do today. I think that’s one of the biggest changes. One of the questions earlier I talked about the desktop process versus the mobile process, and I feel that there are none of those clean lines we had back in 1997 or 1999 talking about the web. So people are incorporating devices differently. And I do believe around the content teams, there’s much more collaboration between content creators, designers, and developers to create a final product, because each group can inform each other on what’s going to resonate best and work best. For the first time we can quantify in a really meaningful way what’s working and what’s not.

Karen:

University web sites have sort of a reputation of being really image-heavy, relying on lots of students sitting under trees kind of imagery. How did you talk about performance as part of this design process? How did you evaluate performance of the site?

Perry:

So of course we look at things like load time and people’s perception of load time too. Sometimes some of the numbers come back larger then I’d like and I realize it’s the third-party services at the bottom of the page that are not really affecting the core user experience. I think again we go back to the personas and what do they want to experience. I think you could have a really efficient, clean, information-rich admissions web site with no images or video that everyone hated, right? It wouldn’t resonate with the students and it wouldn’t resonate with the parents. So I think it’s about figuring out what are the right tradeoffs to make around performance and cost. And really we do spend a lot of development time optimizing the images and the video to make sure it’s as efficient as it can be. For example, I know there was some good work done in this redesign around the high-res graphics for the Retina display capabilities on high density mobile displays. So we really optimized for both the display and for the load time in those cases.

Ethan:

So Perry, I guess when a responsive design gets launched, how do you talk about and measure the success of it?

Perry:

So we go back again to that strategy process. Are people engaging in the behaviors we would very much like to promote? Are they consuming the content we would like them to consume? For how long? I mean, in the Gazette redesign, for example, we would like people to sign up for that daily newsletter. So are they signing up?

So there’s not one big responsive moment. We are living in a world of responsive moments where we’re constantly redesigning and realigning what we’re trying to do.

And one of the design decisions we made around the hierarchy of information was to make sure that there was some in-line call-to-action to sign up for the Daily Gazette newsletter. And now twenty percent of subscriptions come from this in-line feature, which we thought was a big win. Also, a less conventional metric versus time on the story or email signups, is the responsive design [creating] a learning opportunity for our designers and developers? Have we tagged it with analytics such that we can learn what is not working really quickly and switch that around? Unfortunately we’re long from the days when you launched a website and then you were done with it for a couple of years. So there’s not one big responsive moment. We are living in a world of responsive moments where we’re constantly redesigning and realigning what we’re trying to do, and analytics is a key part of saying, you know what, that behavior worked really well when we launched it, but now look, Tinder is around, and people swipe left and look what happens to our photo gallery when you do that.

Karen:

That’s a great lead-in to my next question, which is, what have you learned from the processes that you’ve been through so far? And how do you feed those into future design processes? What happens next?

Perry:

I think we’ve learned and relearned the lesson around strategy, right? That it’s most important get people signed-off at the level of the strategy brief. I think we’ve learned that we need to design for a way that we can keep designing. That we hope to do fewer and fewer big website launches and more and more iterative and incremental improvements that engage people with. I’d love the way that we can do more and more informal testing and feedback and prototyping through these amazing software as a service features so you can launch little efforts to do different versions of pages, or landing pages, or testing of where you put content on the page, and that is definitely informing what we do.

Karen:

I think that’s fantastic. I want to thank you so much for taking the time to join us today, I think it sounds like you have some really interesting experiences so far and quite a bit more to come.

Perry:

Thanks so much to you both.

Ethan:

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

Karen:

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’re also planning to offer these workshops to the public, so please go to responsivewebdesign.com and let us know that you’re interested.

Ethan:

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.

Karen:

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.