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 personally am quite delighted to invite Suzanne Connaughton and Frank Punzo from the Children’s Hospital of Philadelphia. Hi guys, welcome.

Suzanne:

Hi, how are you?

Frank:

Thanks, how’s it going?

Karen:

We’re so happy to have you here today.

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:

In particular, I’m very interested in hearing how your responsive redesign of CHOP.edu has gone. Could you guys introduce yourselves and tell us a little bit about what you do at CHOP?

Suzanne:

Hi, I’m the web strategy and operations manager at CHOP and I oversee the team of web strategists, writers, editors, content publishers on more of the content side of the redesign.

Frank:

And I’m Frank Punzo, and I’m the interactive design manager at CHOP, and so my roles and responsibilities focus on the design and UX portions of the website. I lead a team of three designers and we’re responsible for strategy, information architecture, user experience design, and also the front end design of the project as well. So, we really touch all the different portions of the project.

Once we were able to convince people and show them that about half of our users were already using their mobile device to connect to CHOP.edu, and that also half of our potential users were using only their mobile phones to access the site, it was pretty much a no-brainer.

Karen:

How did you convince your stakeholders and the rest of the organization that you wanted to do a responsive redesign? Was it hard for you to convince people that this was the right approach?

Frank:

It really wasn’t. We first approached our marketing colleagues to get the ball rolling. We were able to give them a lot of stats around mobile usage, both stats that we’d gathered from Google Analytics but also stats that we gathered in presentations from research we did online and other presentations we did and sat in on in-person. Once we were able to convince people and show them that about half of our users were already using their mobile device to connect to CHOP.edu, and that also half of our potential users were using only their mobile phones to access the site, it was pretty much a no-brainer.

We didn’t want anything not accessible on the phone, we wanted all of the content, all of the things that you would need to access immediately on mobile first.

Ethan:

As you were looking at these numbers and were starting a conversation about a responsive redesign, how did CHOP actually start thinking about the needs of the mobile user and the desktop user? Karen and I speak to a lot of organizations where, for the most part, those are seen as more or less the same needs across the board. Was that also the case for CHOP?

Suzanne:

I would say yes. Very early on we looked at all the needs and realized that they are the same. We didn’t want anything not accessible on the phone, we wanted all of the content, all of the things that you would need to access immediately on mobile first, starting with being able to contact—we really made sure that phone numbers, contact forms, easy ways of accessing the hospital were available upfront. Again, both on the phone but the same with desktop, really just making sure that what people were needing and how they were getting to the content on the site was accessible on both. There were no needs that we could think of that were mobile versus desktop.

What we did was we really scoped out all the way down from design through content strategy and even technical implementation.

Karen:

Sometimes when we talk to people, there’s this sense in the industry that responsive redesigns cost three times as much and take three times as long as doing any other sort of project. How did you scope this work? How did you communicate to the organization what it was going to take, how much it was going to cost, and what would be involved in the process?

Frank:

This answer might be a little bit complicated. When we initially started scoping things out, because our project was actually not just a responsive redesign but also contained elements of content strategy. We were moving from an existing CMS to the Drupal CMS. We really had to plan. We ended up working with some outside third party vendors to help us with the implementation. What we did was we really scoped out all the way down from design through content strategy and even technical implementation.

We probably used more time and resources than most people might, but that was mainly to get our team up to speed and put the power with us and have the control to then keep the site up to date.

One of the keys on the project from our perspective was what we did when we looked at everything, we thought “We have an in-house team here that’s going to need to develop the skills necessary to carry this project on once the third party vendors were gone.” So what we did was we actually built in a lot of time for learning. We were going from traditional HTML and CSS into an implementation with HTML5 and Sass, which some of our designers weren’t as familiar with. We built that time in and we had our third party vendor actually train the team so that we could get up to speed faster. By the time we were near the end of the project, we were really handling everything on our own. We probably used more time and resources than most people might, but that was mainly to get our team up to speed and put the power with us and have the control to then keep the site up to date so that any changes we make, whether technical, design, or content, we really have that strength on our team now.

We really touted the mobile-first approach so that whenever we were approaching anything, whether it was a presentation with an internal client or just a workshopping session with an internal team, we really tried to push that mobile-first idea.

Suzanne:

Early on with the vendors, we kept checking in and they would say “What’s most important? Is it time, is it cost, is it quality?” and we kept coming back to the quality of the project and that learning and bringing that in-house. Those really were the two key things. Of course, we didn’t want things to go way over budget, but time was the one thing that we were willing to sacrifice a little bit on. Even though, again, it took longer than we may have wanted originally, that was where we were willing to give some wiggle room because the quality of getting it right and getting that learning in-house was big for us.

Frank:

It really created quite a cultural change at CHOP, and so we sort of became evangelists for content strategy and design and responsive design. We really touted the mobile-first approach so that whenever we were approaching anything, whether it was a presentation with an internal client or just a workshopping session with an internal team, we really tried to push that mobile-first idea and think about what the most important things for users to access and to access first were. Just in thinking that way and creating that new culture inside our department, that really helped as well.

Because we were moving to an entirely new CMS, content structure, everything was so different, we really couldn’t have some of it co-existing with the other site.

Karen:

What about how you decided to roll out this redesign? We talk to some organizations that start with just a section or just a page of the site, and we talk to others that have a long-term beta process that they go through. How did you decide to redesign and roll out the new framework and the new responsive work?

Suzanne:

We did a big bang—we pulled the plug, “It’s live!” all at once. Because we were moving, as Frank said, to an entirely new CMS, content structure, everything was so different, we really couldn’t have some of it co-existing with the other site. We did a lot of testing of course, but once we decided it was “go live” time, it was all at once.

A lot of times we would be designing on demand, and what we did with this project is started out by creating the design pattern and the design library that really gave a lot of thought to how different portions of the design could be used throughout the site.

Ethan:

To follow up on what Frank said earlier about how you were trying to bring some of this knowledge in-house, how has your design process changed internally as you’ve been focusing more on designing mobile-first? What’s changed since you guys have become more responsive designers?

Frank:

We started by creating a library of design patterns, and that was something different for us. A lot of times we would be designing on demand, and what we did with this project is started out by creating the design pattern and the design library that really gave a lot of thought to how different portions of the design could be used throughout the site. So it created standards up front rather than trying to develop standards after we were done with the project.

It offers us a lot of flexibility now so that a lot of times we can wireframe the browser as opposed to actually going with the traditional Photoshop comp method.

That really helped everybody on the team, including stakeholders, but also the designers as well as our content team to really understand that these were the ways we were going to approach the display of this type of content, this was how buttons were going to look, this was how the grid was going to work. It offers us a lot of flexibility now so that a lot of times we can wireframe the browser as opposed to actually going with the traditional Photoshop comp method and things like that. That’s not to say we didn’t start with that in the beginning to get the design resolved, but now it offers a much more flexible approach to our designs.

A few of us just grab a room and do a quick little workshop of it, and that seems to have really been a big improvement in the way we work together and do design and content for the site going forward.

Suzanne:

Another part of the design that really changed is just the way we’re working together, the content and the design team. One thing we started with our process is Frank would just pull us all into a room and would put paper on the wall and really workshop the content and design together, like the IA, just really figuring it all out; taking a section of the site, prioritizing the content, what should be moved, how to get to it, what’s the most important. That’s something that we’ve really kept with after the project—even just for little things that come up with a client, a few of us just grab a room and do a quick little workshop of it, and that seems to have really been a big improvement in the way we work together and do design and content for the site going forward.

A lot of times we just try not to leave the room until we have something resolved. It’s really benefited the team because it shows the way we all think and work together.

Frank:

It really has. It’s just amazing once people start to get into that zone in workshopping where you just have a whiteboard or a bunch of pieces of paper up on the wall and people can get a better sense of how they can participate and how they can contribute and it really keeps the conversation moving. A lot of times we just try not to leave the room until we have something resolved. It’s really benefited the team because it shows the way we all think and work together, and it’s just made us more of a cohesive unit.

Getting into a room and sitting, for hours maybe, just on one section of the site, really tearing apart the pieces of what should stay, what should go, how these three pages should be combined.

Karen:

Suzanne, I’d love to follow up on some of the content changes that you made as part of this redesign. How did your team decide what to keep, what to get rid of, how to edit, how to clean things up—how’d that process go?

Suzanne:

It was a really long process. We started right at the beginning knowing that we had to clean house; some content hadn’t been looked at in a long time and we really needed to do an audit. We worked with some outside help getting an initial audit done, prioritizing content based on clients as well as based on the type of content. So we had a one-two-three-four priority system of the content and also just spreadsheets of every single page on the site. But then we took that even further by taking the spreadsheets, getting into a room and sitting, for hours maybe, just on one section of the site, really tearing apart the pieces of what should stay, what should go, how these three pages should be combined, looking at one section of the site versus another and seeing how they had similar content but were treated differently and what the best way was for treating that sort of content.

No one really wants their site to have a ton of PDFs but we had a lot—and we looked at every single one and made the decision to not include most of them.

We had tons and tons of spreadsheets going. We were thinking “We can add back. Let’s make some deep cuts where needed and we can always add some content back.” We looked at every single PDF—as we all know, no one really wants their site to have a ton of PDFs but we had a lot—and we looked at every single one and made the decision to not include most of them. But sometimes we still need them and we were able to add them back in. I think that was one of the larger things, was how much content there was and making those decisions.

We wanted to divide that content into such specific fields that they could be used across either multiple devices or multiple platforms.

Karen:

How did that process intersect with your replatforming to Drupal? How did you revise all the editorial content and do the replatforming of the CMS at the same time?

Suzanne:

That was one of the pieces where we started early on paper with content vendor and design vendor, really coming up with the content types. We put a lot of effort into that and that’s what was built first—Frank, what did we call that?

Frank:

We called it the MAP [migration assistance platform] system, but it was really just an initial prototype just to get all the content-type fields in and to figure out exactly how we wanted to, for lack of a better word, “chunk” the content. We wanted to divide that content into such specific fields that they could be used across either multiple devices or multiple platforms and things like that.

We spent a lot of time getting the content types right and getting the system right for the writers to be able to work in a Drupal system even though it had no front end, no style, and no display.

Suzanne:

Right, and knowing that we had so much content, that was where we started. So, the developers built us that first and we spent a lot of time getting the content types right and getting the system right for the writers to be able to work in a Drupal system even though it had no front end, no style, and no display. Just to get every field in and every content type in so we could start working in the system to move content over, to move editing, and even to write all the extra fields—teasers, intros, all the extra fields that we needed for the content, the writers had a place to do it even before anything was built on the site. We started there and then started working on the content.

You could be displaying the desktop version on a large projector, but then you could also be passing a mobile device around to show the client just exactly how it’s going to look on the mobile device.

Ethan:

I really like hearing that responsive design brought you into a more collaborative workflow. Have you found that the way in which you hold design reviews, either internally or with the rest of the organization, has changed as you’ve been doing more multi-device work?

Frank:

In some ways it has. In some ways, the designers still go back and design once a lot of the decision-making has been done. But in terms of presentation, that’s where the multi-device approach can happen, and so you could be sitting in a room with your stakeholders or the parties that give you approval and you could be displaying the desktop version on a large projector, but then you could also be passing a mobile device around to show the client just exactly how it’s going to look on the mobile device. Being able to show that kind of thing in person has really been helpful.

One of the processes that we went through was we did usability testing with an outside vendor and that was a way that we’ve changed as well. They actually had devices that they would put in front of users with a little camera attached, so when we were viewing that on the other side of the window, we were able to see the direct actions users were taking on the mobile device as well as the desktop, which really helped us in terms of increasing our knowledge of how people are using touchpoints and maybe making some of them larger or looking across the board at how every piece and element works together and what the user sees first.

As things that we could see were major changes that would need to be made—or even minor changes—we were able to be agile because we did it all in a development environment.

Ethan:

How did you guys then act on that feedback? When you needed to rework elements of the design, did you go back to Photoshop? How did you capture and act on that feedback?

Frank:

That was actually a lot of fun. We were able to go right to the vendor’s offices and we were there for a week just watching all of the participants in the usability studies. As things were highlighted—as things that we could see were major changes that would need to be made—or even minor changes—we were able to be agile because we did it all in a development environment. We would brainstorm as the user was finishing up and then we’d go right into the code and try something. When the next person came in, we were able to validate whether that design decision or change was effective. There were bigger ones that came out that we would then go back and maybe work in the browser or do a little bit of Photoshop or Illustrator work, just because as a designer that, a lot of the time, can be your go-to comfort level. But the ability to change right on the fly in a development environment was so key. There were a couple pieces with link text and buttons that we didn’t really factor in that, as soon as we made some changes where link text became a button, it just switched just like that and we were good to go, we solved that problem right on the spot.

We actually were putting so much into our teaser information that they thought that was it.

Suzanne:

It even helped some of the content problems. One of them was great—we kept hearing feedback that there wasn’t enough information on the doctors, and we were dumbfounded. We’re talking about the doctor profile, where you would look up a specific doctor and read about them. We had great information about the doctors, especially in this user testing, and we were just puzzled—”Why do they feel like there’s not enough information?” We actually had too much information in our microformat that they actually weren’t even clicking to read more. That gave us really great insight into “Oh, we actually were putting so much into our teaser information that they thought that was it.” They didn’t realize that you could click on their name and get more information about the doctor. So, we actually had to dial back some of the content on the first few and just give some key pertinent information and then, as Frank said, use some design elements to make it more obvious that you can click and get to a full detailed bio on the doctor. Things like that were really invaluable.

Karen:

Are there groups within the organization like, for example, legal review or medical and compliance review, where you needed to show different examples of how a responsive redesign would work to people who were less familiar with the design process?

Suzanne:

I don’t think we did have any of that.

Karen:

That’s good to hear!

Frank:

I think the content changes that we made, we had them approved through our internal clients, who were really the doctors and folks that work in the hospital, and so I don’t think the content changed enough to warrant the specific device change legal requirements or anything like that.

There was a way that we could do it that optimized better for the user’s browser, especially in thinking about how and where users are going to be viewing this information so that they might not have access to LTE, 3G, or 4G.

Ethan:

Did the topic of performance come up during the course of the redesign? Karen and I are both big believers that performance is something that everybody needs to care about. Was that something that impacted the design decisions at all?

Frank:

I would say that it did. We’re using large hero images, but we tried to optimize them as much as we possibly could. But when we were looking into how we were going to design things, we really wanted to make all of JavaScript calls from the appropriate places, use images where appropriate, not overload the site with images that didn’t provide value, things of that nature. We did go through and use tools like Google Website Optimizer and others to see where our pain points were, and as soon as we saw those we were able to work with our developers to solve some of those problems. That was key to be able to show the developers that we may have designed something a certain way or we may have tried to implement something a certain way, but there was a way that we could do it that optimized better for the user’s browser, especially in thinking about how and where users are going to be viewing this information so that they might not have access to LTE, 3G, or 4G, so we didn’t want the site loading very slowly.

As much as you can get in front of as many stakeholders as possible in the process, the better, because it just avoids headaches.

Karen:

Having been through this redesign, replatforming, and responsive work, do you have any advice for other organizations that are considering going through this process? What would you do or not do again?

Frank:

One of the things we learned was that we included a lot of high-level stakeholders in the approval process, but because we work with a large range of clients across the institution, it was difficult to go out and meet with each group or hospital unit individually. We definitely have had to go back and give that presentation to some of the folks who maybe thought that some of their content was gone or they didn’t understand why it didn’t look or perform exactly as the old site, or “What happened to this piece of content? Why does the design do this?” As much as you can get in front of as many stakeholders as possible in the process, the better, because it just avoids headaches.

Once we explained the process and that we took the mobile-first approach, and that we were really pushing to get users their content as quickly as possible, so that people could access that information more easily, they got it.

We felt bad for some of them, that we were giving them presentations almost after the fact; it was after go-live and they were now seeing this brand new site which we had such pride in, but they’re just kind of like “I don’t like it. This isn’t what we want.” Once we explained the process and that we took the mobile-first approach, and that we were really pushing to get users their content as quickly as possible, and to have a more structured navigation so that people could access that information more easily, they got it. It’s that cultural change that I referenced earlier, getting everybody to really start believing in the process and understanding it, because this isn’t what they do every day. It’s what we do every day, but it’s not what they do every day. They’re saving lives and meanwhile we’re just designing websites.

With how long I said we spent on the content, I feel like we still should have started earlier.

Suzanne:

I was thinking the same thing, it has to do with the content. My initial thought when you asked the question was “Even do it earlier.” With how long I said we spent on the content, I feel like we still should have started earlier. But that really has to do with the review. We sort of got into a “Catch-22” of not wanting to show it to a client until design and navigation was there and everything was almost perfect, but I think that did trip us up. My advice would be to try to figure out a way to get that client review of their content earlier. Even if the whole site is not done, even if navigation isn’t there, even if the pieces aren’t together, figure out a way to walk people through a demo of it for them to be able to see and feel what their content is going to look like in this new environment. That’s definitely one of the things that we struggled with.

Ethan:

I think that’s a common question a lot of organizations are asking themselves, but you guys managed to produce a really beautiful responsive redesign. Frank, Suzanne, thank you so much for your time today and I know personally I can’t wait to see where CHOP.edu goes next.

Frank:

Thanks so much.

Suzanne:

Thank you. It was great talking to you.

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 a public workshop on responsive design, taking place 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.