Episode Transcript

Ethan:

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

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well, I’m a little worried I’m coming down with something because my heart’s all aflutter that we are speaking with Paul Gee and Rob Wooten, who are here today too talk to us about the JAMA Network. Paul, Rob, thanks so much for coming.

Rob:

Oh, thank you.

Paul:

Thanks for having us.

Karen:

But before we get on with it, I’d like to welcome back our sponsor, Gather Content. I’m thrilled that they’ll be sponsoring this podcast for the rest of the year. I recommend Gather Content to my own clients who are going through a website redesign. Gather Content provides some much needed structure and editorial workflow to help manage a large-scale content creation process. Because Gather Content works with so many organizations going through a website redesign, they have unique insight into how content fits into a web project. And because they are such great people, they wrote down their advice for you! They’ve put together a 41-page guide to Content Strategy for Website Projects. Head on over to gathercontent.com/RWD to read their advice or download a PDF to share with your team. Thanks, Gather Content!

Ethan:

So before we dive in, maybe you both could tell us a little bit about the JAMA Network for the benefit of us and our listeners. Tell us a little bit about what you do and what this responsive website was all about. Paul, do you want to go first?

Paul:

Sure. The JAMA Network is the publishing arm for the American Medical Association, most famously known for publishing JAMA, the Journal of the American Medical Association. So, we publish JAMA but we also publish eleven other specialty journals. We publish the print, we also publish all of the websites in house, we produce all of the content, and it’s a pretty big publishing staff, about 180 people on our floor. So, we work with other vendors on our web platforms and mobile platforms, and Rob is speaking on behalf of Silverchair Information Systems, who supports our websites, and I’m responsible for everything web and mobile at the JAMA Network.

Ethan:

And Rob, how about you?

Rob:

I am a UX and visual designer at Silverchair Information Systems, which is a responsive platform for scholarly publishing.

Ethan:

Well, once again, welcome. It’s really great to have you both here. Maybe before we actually dive in, I’d love to hear a little bit more of the origin story of the JAMA Network’s responsive redesign. Specifically, I’m curious what drove the decision to go responsive, and when you were having some of those early discussions, were there any questions or concerns you might have been hearing from stakeholders about responsive design as an approach?

Paul:

We originally launched the JAMA Network as the JAMA Network back in 2012, and at that time we had a mobile version of our website and we had the full version of our website as separate, independent pieces. It became very, very quickly apparent, like by the end of 2012, that we wanted there to be more synergy between the web and the mobile for various reasons—and by mobile, sorry, I just mean the mobile view of the articles and the website. The main reason was that our mobile usage was going up dramatically. Within two years, our mobile usage went up from probably fifteen percent phone hits to about twenty-five percent, and we’re now nearing around thirty percent in some journals. So, the business case was really our users are using more and more mobile devices, and our mobile view was very limited, it didn’t have multimedia appended to it, you couldn’t buy anything in the store, you couldn’t take educational activities through the mobile view. It just didn’t support all the stuff that our full desktop version did. Additionally, instead of having twelve websites, we technically had twenty-four websites, and every time we added a new feature, we’d have to remember, “Oh, we have to add it to the mobile view too, we have to keep it in parity,” and it was basically double-coding. So there was an operational efficiency that went into the decision to go to responsive, but most of the decision-making was around where our users were going.

Karen:

Let me follow up on that a little bit and ask if you had any debates or concerns about mobile usage and desktop usage being different. I think one of the things that Ethan and I sometimes hear, particularly for an audience of people that might be reliant on desktop computers, or in some ways even reliant on print, there’s a sense that scenarios of use should be different on mobile devices versus other platforms. Can you talk about how that influenced your overall strategy?

Rob:

Paul, if you don’t mind, I’d like to talk about this from a UX standpoint. When we first spoke with Paul about the business decisions they needed, we created user personas, which are great in the beginning of a UX process. What we found out is that different user personas are engaging different content on different devices. So, say, like students and librarians, they’re doing research articles, so they needed to be able to view entire pages on their desktop, and a lot of the time they had the same article open on a desktop. On one side, they would have the copy of the article, and on the other side they would have references and tables and figures, and they would use all of this to help support their research.

And then we had the practitioners, the doctors, and the nurses. They don’t have time to sit behind a desktop, they’re rarely behind there. They’re mostly on their phone or on their tablet, in between appointments or in travel, and that is how they are ingesting that content. They’re actually not even reading entire articles, unlike the desktop users. They’re really just reading the top of the articles, which we call the abstract, to get the information they need to solve their medical problems.

Paul:

Just to add on, we initially went into the responsive framework with a couple principles in mind. We wanted to focus on the article, and that’s, I think, a little bit different than at least most of the web projects I’ve worked on in the past. We know that all of our traffic, whether it’s desktop or mobile, has one thing in common: it’s usually going from an email, from social media, from Google, directly to an article page. It’s not traveling through the top of the house, the home page; it’s not traveling through a TOC. It’s a direct-to-article experience, and so we started by designing the article, also with the principle in mind that we wanted the article to be synergistic and all the contents of the article to be the same on a mobile device or a desktop device. There shouldn’t be any reason why it’s hard to get to a video or find related content on a phone. We started there.

About three or four months in, while we were in the middle of designs, our editorial group felt very, very, very strongly that we build a use case for researchers on a desktop machine. So we kind of went backwards—we hadn’t even started working on home pages and stuff like that. We spent about three months on the article, which is the landing page for our journals now, and as we got the mobile framework up and running, there was a direction, a push to actually expand a special view on desktop. Basically, the way I think about it, usually you design everything for phone and then it expands when you go to desktop. In this view, we decided to design it for desktop and then also allow it to respond in a different way down to phone for a specific type of article. So for our research articles, which is what Rob is alluding to, we took up a framework where the data can be viewed side by side with the text to support everyone who’s trying to read about data and needs to see the data in a static, independent position while they’re doing that reading. So we introduced to our journals, for specific articles—research and review articles—this framework we call the split-screen that only appears on desktop and kind of very elegantly cascades down to a mobile view that feels like a normal mobile article on a phone.

Karen:

Let me ask about how you plan a project of this magnitude. I’d be curious, as you’re working with an outside partner and thinking about what the process is going to be or what you’re going to do when, and how long it’s going to take, and who needs to be involved, how did the responsive process influence your planning?

Paul:

I guess debating is probably the simplest answer. [laughs] We went back and forth on it, and we were very flexible with each other, with Silverchair and the JAMA Network, we both worked to change the process as we went. When we learned that something wasn’t working, we’d change it. We created a collaborative space where we could manage project plans and timelines, like a very traditional-type wiki, and we came up with a strategy where I was able to reflect all the requirements of my business, my stakeholders, and my users, and then the business analyst at Silverchair was able to break those down into user stories which I then approved, and then went into grooming with the developers, and we followed a kind of agile sprint model from that point on. Rob was involved in the designs, the designs kind of came first, and then the designs were based on a high level set of targets and goals and desires from my team and our users. After the designs were finally approved, I then finalized the requirements, the user stories were then all written, and then the development was planned. It probably took about six months to get to the point where the designs and the requirements were approved, and then it took about eight months after that for the entire site to get built and rolled out.

Rob:

And while six months might seem like a long time initially, for a site of this scope, it was actually pretty fast for us. We did something new when presenting designs to clients that we hadn’t done before. We presented wireframes first. No visual design whatsoever. We just got buy-in on all the components, where they should be on the content page, and once the wireframe was approved, we were able to get it sent to our back-end team and they could begin scaffolding the page while we were getting the look and feel approved by the client, so there was a lot of overlap in our build process and the design decisions being made.

Ethan:

Rob, I was wondering if you’d be willing to expand on that a little bit, because I’d love to hear a little bit more about how Silverchair actually manages the design process and if that’s changed as you’ve done more responsive work.

Rob:

As you know, all these websites are built from certain content pages, and certain content pages take longer to build than others and have higher importance than others. So, take something like the article page. That is the bread and butter for JAMA Network, so we make sure that we get that page solidified first. We get the wireframes approved, we create a visual style guide that we apply to the wireframes later, and then we move into other content pages, like the home page, or the table of contents, or the topics page, or search. So, it’s about getting done what’s most difficult first and leaving time for the easier, less time involved projects near the end.

Ethan:

That sounds great. If this question isn’t too deep in the weeds, I’d love to hear a little bit more about some of the applications and tools you’re using as a designer, or other designers on your team are using as they’re doing more responsive work. Are you doing more prototyping? More straight-up mock-ups? Tell me a little about your workflow.

Rob:

Okay, well as far as layout tools, this was done two years ago, Sketch wasn’t as robust as it is now, so we did use Photoshop, which is kind of tough because Photoshop at the time was trying to be a web program and a photo program. Now, currently we’re actually using a program that’s in beta called Experience Design by Adobe, and it has a lot of the great things that Sketch has, but it’s an Adobe product, which means that I can edit icons and create graphics in Illustrator and Photoshop and seamlessly bring them into another program without having to worry about program support. We also use an app called InVision, and InVision was great for our prototyping. We didn’t have to do any animations, which can take time. We can do flat mock-ups with click zones, and they can click through the experience. And another great thing about InVision is project managers, clients can directly comment on the mocks. So instead of me combing through email or combing through a JIRA ticket, I have the edits right there in front of my design and I only have to look at one browser screen when working in a layout program.

For layout purposes, we use Photoshop for wireframes and Illustrator to create the custom icons for the site. For prototyping, we use the InVision app to guide customers through the user flow and to document any aesthetic feedback.

Karen:

What about how this responsive redesign might have changed the editorial direction for any of the JAMA Network products? Sometimes we’ll talk to publishers that say that a redesign like this is an opportunity to really think more broadly about new editorial formats, products, new ways of presenting the content, and other publishers will say that this is really just a front-end redesign, where they’re looking to make the site work all devices, but it doesn’t change their editorial direction. How did that work for you guys?

Paul:

Well, there’s a couple things that went into it. We started this process before Rob really ever heard of it. We did a round of contextual design inquiries in December 2015, and we heard directly from our users not based on how they want to use a website, but really how they want to use medical literature. They gave us insights into their workflows, into what they’re interested in, and that’s a lot of where our user stories and our personas came from. We took that input, we went through the first round of designs, and then after we had the InVision mocks that Rob was referring to, we actually built an HTML version of those mocks that we brought back to users, and we allowed the users to sort of direct what they wanted. I say that because it did influence our editorial strategy. There were some echoes and some things that they said about the designs that we worked hard to incorporate into the original requirements and then into the revised requirements before we actually started building.

One of the things I thought was not as important of a feature necessarily from the web perspective but our editorial group loved a lot was this idea of sort of clustering editorials and invited commentaries in various places around the article and in the TOCs, and the users really loved that. They loved it so much that we’ve made it so that some of the related content appears in two or three places on a given page—at the top of the abstract, below the abstract, in certain tabs, in the TOCs. We want to make sure that if what we discovered, that people like to read in a cluster, they like to read the original article, they like to read the editorial involved with it, and they like to do it seamlessly in a circle, that we sort of supported that workflow circle. So, one of the things that we guessed at, editorial felt strongly about it and the users really validated it and kind of pushed it further: editorial also started writing discrete short titles for all the articles, summaries for all the articles which were embedded in the back-end of the HTML that we use in social media to automate our electronic distribution downstream. We’ve done a lot of work to try to not just publish a print object but also publish that electronic rendition that’s custom fit for the web a little bit more. And finally, all of our research articles are being published post the redesign, with a key point section. So instead of an abstract, which is short and a good summary of the article, we found that end users really wanted a more clinically-based, synthesized, like three-bullet summary of the article before the abstract. We worked pretty hard to build that into all of our editorial groups’ content creation process, into our production process, and into the front-end web in a new way. So we have key points now that appear above the abstract, which is a different thing in place of the abstract and sort of featured at the top of every major article.

Karen:

Let me also follow up on the content management platform that you’re using to manage and maintain things. Do either one of you want to just talk about how that platform works and whether it’s working for you?

Rob:

I can tell you how we solved the needs that the JAMA Network needed. The JAMA Network needed to create hundreds of self-served custom pages that weren’t part of the platform or anything that we were doing on their end. They also had their own development team over there. So what we did is we took the living style guide and made it so they could grab the syntax from the style guide, apply it into their own pages, and therefore build their own pages that would be cohesive with the rest of the website. We also added extra requirements or extra styles that they may need to fit the content for their self-serve pages. So they are able to build cohesive self-serve pages now using a live style guide that we created for them.

Paul:

Were you referring to more of the content management system on the production side?

Karen:

If you’d like to comment on that, that sounds great.

Paul:

We use MarkLogic and a series of other editorial systems to manage the work-in-progress content and then to store a single source and distribute it to multiple endpoints. So, Silverchair is just one of the endpoints. They have a transform from MarkLogic that includes some custom stuff that we want to do on the front-end web. We also have a couple different mobile apps and mobile outputs that come from that. So, the changes that came because of the user interviews influenced much more than just the Silverchair output. The print was also influenced, a couple of our mobile apps changed a little bit. We really used that user input dramatically, but we custom fit it to each of the experiences for what they were.

Ethan:

One thing that I hear from a lot of publishers that have gone responsive is that browser support becomes exponentially more challenging for them than it used to be back in the old days. So rather than just supporting a handful of desktop browsers, they’ve got all these different devices and operating systems to think about now. Has the way in which you tested and QA’d changed now that you actually have this wonderful new responsive site?

Paul:

I think we took it more seriously. We had already launched an HTML5 app back in 2013. It works in every browser, it works on every device, and it’s fully responsive, and we learned a lot about what it meant to support that browser and to keep the technology up to date. So, one of the fundamental things that we learned was we should only be on the hook, if at all possible, for keeping that application up to date with the most recent browser releases and to allow the browser versioning and our support for it to trail off after the most recent version. Which sounds a little dramatic, and it is in a customer support path, and in 2013 it was a little bit difficult, but I would say since releasing this in October, we’ve had very little complaints. What we see in our analytics is that the most recent version of every browser is the version that ninety percent of everybody is using, and people adopt things a lot quicker than they used to. If Apple releases a new browser version, it’s adopted by our user base overnight. If Google changes their operating system on phones, it’s not as quickly updated, but it doesn’t seem to cause a lot of problems and the browsers seem to be a lot more backwards compatible than they used to be. Even Internet Explorer isn’t causing us as many issues as it used to. [laughs]

When I say we take it more seriously, because of what we learned on the mobile app, we went into this process with test scripts for every single feature and page that we built that accommodated for multiple-device testing. We have a little shop here of testers—this is outside of what Silverchair does—they work to test across any of our products or any of our outputs and make sure that the expectations that we have for each of those devices is up to spec. But they only test on the most recent version, and that’s the only one we claim to support.

Karen:

How do you evaluate whether this responsive platform is working for you? What sort of metrics or data are you tracking to know what’s working and what might need to be improved?

Paul:

We went into the project with a series of critical-to-quality metrics that are just basic to how our business operates on the web. Traffic, time on site, page views, mobile traffic, that kind of stuff, we have baselines for that. We have a very heavy, sort of analytic arm that stabilizes our data and makes sure that we have a long history that we can use comparatively. So, we have about five years of history at this point that we can use to look for “disturbances in the force,” so to speak. So, we monitor those CTQs, and as we went live if we saw something go south, there were a couple issues that we had on the SEO front right out the gate, we had them resolved very quickly because we’re simply looking for things going in the wrong direction. But otherwise, we know we’re successful if we have a site that is more discoverable to more people and people stay longer on it. That’s what we’re really looking towards.

Ethan:

Paul, Rob, it’s been a real pleasure speaking to both of you about the JAMA Network’s responsive redesign, which is lovely. But before we let you go, I’d love to hear if you happen to have any advice for our audience. What’s one or two things that you’ve learned in the course of this responsive redesign that you’d like to share with our listeners?

Rob:

Take a lean UX approach to how you build these sites. Bring in the developers, bring in the stakeholders, bring in the project managers in the wireframe phase. What this does is you get everybody on the same page and it helps alleviate scope creep later on in the build.

And if there’s another thing that I can ask designers out there to do is read Designing for Emotion by Aarron Walter. It is this great insightful read on user empathy and making design experiences enjoyable. I know the first thing we need to do as a designer is make something functional, but that doesn’t mean that it can’t be an enjoyable experience. That’s where the design comes in, and the fun part.

Paul:

I would say to stay dedicated to being flexible through the whole process, really watching what’s important to you, prioritizing features and design choices that are important to you, making sure that your entire business is very clear on what they think are priorities or not priorities, nice-to-have’s. But then being flexible with the development group as you go through, to quickly understand why there might be problems and knowing immediately, when the developers need to know, what you can compromise on and what you can’t. That’s the key thing. I think there should always be one person at the helm who is responsible for understanding all the stakeholders’ needs and the priorities of those needs, and making very quick decisions about how to balance them when a developer needs to know. That’s what keeps you on track, that’s what keeps your scope relatively contained. I would say that’s probably the key thing that made this—it was a tough year, but it was a good year, and when we launched… This was kind of amazing: when we launched, we were prepared for sort of an all-night triage session. By 5:30PM, there was crickets. Not a single phone call, not a single email. Everything was quiet. Now, there were problems that came downstream that we discovered a week or two later and we’ve been resolving them, but nothing we’ve kind of anticipated for the depth and the… We didn’t just change the front-end, we changed a lot of the back-end as well. And we had a very quiet night, we went out to dinner and relaxed, which was the first time in a while. So, it was a good event.

Karen:

Well, that’s a great story and it really shows in the quality of the website. So, Paul, Rob, thank you so much for taking time to come and talk with us today. We really appreciate it.

Rob:

Thank you, it was a lot of fun.

Paul:

Yeah, it was great. Thank you.

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.