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, we are practically beside ourselves to be speaking with Leigh Shoemaker and Michael Purdy, who are coming to us from the University of Tennessee-Knoxville. Leigh, Michael, welcome, thanks so much for joining us.

Michael:

Thanks for having us.

Leigh:

Yes, thank you.

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 could just introduce yourselves to our audience, tell us a little bit about what you do at UT, and why you’re here today. Michael, do you want to go first?

Michael:

I am Michael Purdy, senior interactive art director for the University of Tennessee-Knoxville. We work here at like the central communications and marketing office for the university. Our primary roles are to create the new main website, which we’ll be talking about today, and a lot of the external websites, like the departmental and office websites throughout the campus.

Ethan:

Nice. And how about you, Leigh?

Leigh:

My name is Leigh Shoemaker. I think you’ve already said that, though. [laughs] I’m the assistant director of creative communications here at UT, and my area is web and electronic media. I’ve been in this position for five years and this is my second major website rollout for the university in that leadership capacity. And then before that, I was a web designer here for four and a half years. So, I’ve been in the trenches as well. I like the trenches. [laughs] I prefer them, actually.

If we had not made this site responsive, I fear there would’ve been pitchforks and torches and so on and so forth.

Ethan:

[laughs] Well I have to say, the trenches made a really beautiful redesign of UTK.edu, and Karen and I are both really excited to speak to you about it today. Maybe we could just sort of kick things off by having you tell us a little bit more about the decision to go responsive. Why was that seen as the best approach for this redesign, and were there any concerns or questions that came up around responsive redesign when you were talking to stakeholders at the university?

Leigh:

So, I’m going to start this and then I’m going to throw it over to Mike. But Mike joined our team in 2011, and at the time responsive web design was fairly new and he was really eager to put the main website into responsive format. And so, our 2012 redesign was responsive, and so there was no way we were going to backtrack on that. We, in fact, over the past four years, have created a great enthusiasm for responsive design on campus. People really enjoy the functionality, they enjoy that it works well on mobile, they enjoy that they don’t have to maintain two separate websites. So we had a really good experience selling the concept and executing it and getting lots of buy-in. So if we had not made this site responsive, I fear there would’ve been pitchforks and torches and so on and so forth.

One thing that we did do this time differently was we started with the template redesign first and we made all of the templates responsive, which we had not done in the past. So I think there’s been a lot of really good response to that, as well. And I’m kicking it over to Mike.

Michael:

Yeah, the selling of responsive would have happened back in late 2011 or so, and if I recall correctly, I think we had started out, we already had architecture and wireframes established… I developed what I had called at the time just some proofs of concept, where we coded out some HTML and some CSS and put in just some big basic various shades of grey boxes on the browser and said, “Okay, here’s our wireframe in HTML,” and then just moved the browser around to see how it adjusted. And just showing that, it sort of sold itself. Putting your brain in 2011 mode, it seemed really, really new and it seemed absolutely magical, and I don’t recall it being a real tough sell after that point, because we sort of shifted our language, even. I don’t think we talked about having a mobile site anymore, it was just The Site. So, when it came to this 2016 redesign, it was sort of a known quantity that that’s what we were going to be doing.

Leigh:

And part of my job is taking this around to administrators and representatives from the faculty and the student body and sort of selling it to them. And in 2011 and early 2012 when we had these proofs of concept for the responsive design, the rooms would just light up. We’d take the edge of the browser and drag it over and make everything narrow and things would move… That was huge. I think we could’ve done anything we wanted to at that point. [laughs]

Ethan:

[laughs]

Karen:

[laughs]

Michael:

[laughs] That is the most untrue thing…

We are a university and every year we need a whole lot of new students. But at the same time, we also still have a very important audience that doesn’t go away and uses the website to do their work.

Karen:

I’d love to hear a little bit about how you might conceive of the need of a mobile user and how that potentially is different from what people want to do on their desktop. One of the things that I’ve heard in talking to universities is that there’s this sense of students coming in and maybe researching the school or applying for the school, and that’s seen as a desktop task. Whereas current students often want an app, for example, to help them manage their life on campus. How did you talk about these different scenarios of use?

Michael:

Oh boy…

Leigh:

That’s a really good question.

Michael:

Focusing on the difference between a mobile user and a desktop user isn’t something that we really, really focused on. We approached it more from a content standpoint and also an audience standpoint. In the world of university websites, it’s hard to really choose a finite audience, because we’ve got prospective students who are maybe seventeen-years-old, we’ve got older faculty who’ve been here for years and are accustomed to the way things work now, and there’s everything in between. So trying to strike that balance between what would be important to whom is easily one of the hardest jobs that we have, because we have to recognize that, yeah, we are a university and every year we need a whole lot of new students. But at the same time, we also still have a very important audience that doesn’t go away and uses the website to do their work.

So, thinking about whether it’s on a phone or on a desktop, I don’t know if we really, really got that granular in thinking. We were thinking of it more in terms of, “What do faculty need? What do prospective students need? What do current students need? What do staff need? What do alumni need?” We started dividing the content along those lines and tried to build in some functionality along the lines of the content rather than what is on mobile versus what is on desktop.

There’s a few things that we’ve fudged on, of course. One of the things we are pretty sure that new students in particular use the site for is to find their class. So on mobile, we did put a link to the map right up at the top. That’s not necessarily reflected primarily on the desktop currently, but we know that’s an important thing that new students are doing when they’re coming to class for the first time. So there’s a little bit of wiggle room in my answer, but primarily we approached it from more of a content standpoint than a, “What do mobile users want versus what do desktop users want?”

Leigh:

I’m going to take a step back even further because I think there are a lot of philosophical issues that come up with regard to the university at large. We’re a small department in the university, we’re not actually centralized, we don’t maintain all of the websites on campus. We do create the templates and we set the reigning guidelines and so on and so forth for university academic and administrative websites. But beyond that, we don’t have a big stick for enforcement. And so we’ve found ourselves in the role of evangelist and teacher from time to time when we were talking with our other clients, like admissions and, to a lesser extent now, alumni, and colleges, other campus communicators that run their own websites.

One thing that has been difficult to push the needle on is this idea of a simple application, a simple form that students can fill out to express their interest in the university. The forms for that tend to be really, really long and complex… “Name, address, major, interest, etc.” I know for mobile users, those forms have to be incredibly frustrating from a usability perspective. We don’t control those, we don’t have those on the central website. What we have on the central website is a bit of information to pull people in and then a lot of links to send people out, and then beyond that, as I said, we can be an advisory role or we can be in the role of sort of the agency to the client, helping to guide their online communications.

But we still have a lot of elements present on our website that are not mobile-friendly and that are not mobile-first. We have a campus intranet that is used by the majority of the students probably on their phones—we don’t design that. We have, of course, the online application, which is created by a third-party vendor—again, we don’t design that. So, there are a lot of little loose ends out there as far as how we would consider users interacting with the site, particularly mobile versus desktop, that we just don’t control.

We know that our prospective students use mobile devices when they’re investigating programs, colleges. We know that if it doesn’t work well on their mobile device, they will go elsewhere.

I will say with this last redesign, when we started to think about the templates—and we redesigned the templates first and did kind of an inside-out approach to the redesign—we started that design literally mobile-first. And so the first wireframes, the first proofs of concept that we tested with the user base were mobile. And we had students test those; we tried to get a representative sample from all different age groups for that because we know that the academic and administrative units on campus are going to be seeing a lot of mobile traffic from students in particular looking up requirements, looking to get to applications and so on and so forth. So we really wanted to focus on them as a user group. And then for the main website, because we had done that groundwork with the templates, we brought some of that sensibility into UTK.edu, and reused a lot of the strategies that we had developed early on with the mobile-first approach with the templates. And so even though we didn’t technically do a mobile-first design with UTK.edu, it was definitely informed by a mobile-first philosophy.

We know that our prospective students use mobile devices when they’re investigating programs, colleges, looking to see if the university is a good fit for them. We know that if it doesn’t work well on their mobile device, they will go elsewhere. We want to turn those lurking students into actual prospects for admissions, so we want to route them in as quickly as they can be routed to get the nuts and bolts done. And so, as Mike said, we also recognize that the bulk of our users are desktop users, are people who are employed here. We are a large university, and so if you look at our Google Analytics, you see a huge spike on Mondays when people come in and turn their machines on, and then that drops off during the week. So, our most important audience is prospective students, we know they’re on mobile. Our largest audience is right here, and we know they’re on desktop. And we’re decentralized and we can’t control everything from this mobile-first perspective. So we really tried to increase the conversation among campus communicators and get people thinking about mobile-first and the benefits of that, because that’s where their audience is coming from.

That first presentation was about how we were really going to hammer this Volunteers story home, because that ties in with the university’s larger strategic plan and our larger marketing plan.

Ethan:

Tell me a little bit about how that mobile-first thinking translated into the design process for these responsive templates. Specifically, I’d love to know what kinds of applications and tools you were using to actually create this responsive design. Was this a very mock-up focused process? Were you a little bit more prototype heavy? Tell me a little bit more about how that was structured at UT.

Michael:

If anyone might be confused, there’s two things happening here: one is what we refer to as the templates, and then there’s the main website, which is www.UTK.edu. Now, the templates are just essentially a set of, in their barest form, patterns and a collection of HTML and CSS and JavaScript files that any unit, be it the Department of English or the Office of Human Resources or what have you, or if you’re a part of the University of Tennessee, you should be using those templates so that all of our websites kind of look the same. Then there’s the main website. We finished the current set of templates in the middle of last year and we immediately began on the new main website, so that was the timeline. I think the process began with me going, “Okay, we’re going to do this right! We’re going to have this standard procedure and it’s going to be just perfect and flow beautifully!” What it ended up was closer to some organized chaos.

I think it began with a couple of us with Sharpies and notebook paper drawing squares on paper, just talking about how this could work and how that could work. There were a couple of knowns to begin with, and I don’t really like to go into any project being adamant about how anything should happen. But there were some things that we knew we wanted to happen—we wanted the logo to be in a certain place, we wanted the navigation to at least closely relate to how the navigation on the templates worked. So there were a handful of knowns. I think another known was we didn’t want any sliders or carousels on the site. But from the paper sketches, we kind of talked about, yeah, this may work, and I think at that point I did the little proofs of concept or HTML wireframes or whatever you would like to call them, just to see where things might fall into place at different screen sizes. I like to do that because it’s a good way to make sure that what’s in your head will actually be practical on the computer.

From there, we went into InDesign, and in InDesign, that just goes into my background of being a graphic designer who’s worked in print for a while. I know that there’s Sketch and there’s some new hot tools out there, but I still like InDesign. So, we brought it into InDesign to try to bring out the design, put in some real pictures, start adjusting the typography, and getting a good idea of how it might actually look, brought that back to the web team. The web team is composed of about five people, including Leigh. We kind of divided ourselves into two mini groups, like a design and development group versus a little content group. We brought it to the whole group and talked through some things, and, “Wouldn’t this be nice,” and had some arguments and some thrown chairs, I think. We eventually settled on something, we brought that back into the HTML wireframes to do a little bit more tweaking there.

At that point, the first presentation we did was to what we would call the managers group, that was kind of the first-level presentation. We presented just JPEGs to show, “Hey, this is what we’re thinking it will look like.” And I’m leaving out a huge chunk, because simultaneous to this was what the content team was doing. They were developing strategies with how to talk to the different audience types that we mentioned earlier. We had come up with this idea of, “What is a Volunteer?” We’re the University of Tennessee Volunteers. That separates us from a whole lot of different universities, and we wanted a place to tell that story. So the redesign really happened around that, and that first presentation was not about how cool the design is. That first presentation was about how we were really going to hammer this Volunteers story home, because that ties in with the university’s larger strategic plan and our larger marketing plan.

So all of that was feeding into each other at the same time; you had the content team working in concert with the design and development team. Every web designer in the world loves to say, “Oh, this was a huge project! Multifaceted; so many things were happening!” But this was a huge project and it was multifaceted and so many things were happening! The previous website was on a really old server and it was powered mightily by just HTML and CSS files and a handful of very special PHP files. It was not content managed at all. If any change needed to happen, one of the four of us on the web team had to do it.

One of the parts of this project was for the first time ever we were going to content manage the main site at the University of Tennessee-Knoxville, and this was huge. This involved not only our team, but we also involved the Office of Information Technology here on campus to set up the server for us. So, we were working with them at the same time, and at about this point it came time to actually choose a content management system. We looked at a number of different content management systems, and the thing that I think actually made this project a success, and I cannot speak more highly of it, is that we set up that content management system, we put it on the development server that the Office of Information Technology had set up for us, and barely knowing how the content management system worked yet, I took those HTML wireframes and those proofs of concept that we had done months earlier and just made some very rudimentary templates for the content management system. Made some really what felt like just the best guesses at what the content types should be and built those out in the CMS, and immediately gave the content team access to it.

The last thing you want on a project of this size is some designer/developer going, “No no no no, we’re going to do it this way because this is more efficient for computers!”

So we had this very rudimentary, skeletal, kind of crummy looking website that was breaking a lot and stuff, but we got the content folks in it just very, very early. And Angie Vicars, who is on our team as a writer, at that point, once she had access to it, she was coming in saying things like that, “Okay, we have these profiles; we know we wanted to have these profiles. But there needs to be a way of maybe saying what year they graduated,” and that would allow me to add that field type to the content management system. Same thing goes with we have a content type called Spotlights, and if something wasn’t working for her, she could come just walk down the hall and say, “You know how this could be better?” At that point, it became really, really organic, and I can’t really say that there was any special tool that made that easier other than just really close collaboration. Because the last thing you want on a project of this size is some designer/developer going, “No no no no, we’re going to do it this way because this is more efficient for computers!” [laughs] Because the writers are going to be in this website every day, churning on it, and they’ve got to get comfortable with it, they’ve got to really like using it. If it’s just something that the designer or developer just does and flops over to the content team to deal with, that can become an issue.

So, that was one of the most important things that we did, getting that collaboration with the content team going a whole lot. And from there, it just sort of developed, and I would come in and say, “I need to make these Points of Pride look good,” and I’ll start working and I’ll be like, “Oh man, there’s fifty of these now! How did she get all of these in here? I’m going to have to rethink this!” As that process went along, we really started bouncing off of each other and informing each other about how these things could work better. And simultaneous to that, just refining all the styles… At some point, we all took a look at it again as a team, and there were some things that just weren’t working, so we returned to InDesign to tighten up—because you can’t adjust type styles, you can’t adjust margins and stuff in a design program (or at least me) faster than in CSS. Once we got those tightened up the way we wanted it, then we went back into the CSS and tightened it up for the screen as well. And there was a couple of other presentations that happened somewhere in that process. [laughs]

Leigh:

Yeah, and a couple rounds of usability testing.

All of our discussions were shaped by an orienting statement and by this sort of larger vision of we want to do something that sets us apart—but not too far apart.

Karen:

So Michael, Leigh, as we are getting to the end of our time here, I would love to know if, based on this process, if you have any advice for our listeners. Is there one thing that came out of this process that you’d like people to know that they could do to make the process go more smoothly?

Leigh:

I think just getting your goals straight initially, making sure that everything is in keeping with both your branding and your marketing strategy, communications strategy, and goals. And involving as many people who are responsible for shaping the content that your organization puts out as possible is really important; it’s important to get all of those people bought in early on. We did a lot of things that seemed really rudimentary to us at the time when we were first starting with the content production and came up with a very simple, almost silly orienting statement that involved the word “Fun!” And we also thought a lot about what makes our university unique, and the fact that a lot of university websites look alike and then function very similarly. And so, you have to take into consideration user expectations as well as the need to have something unique. And we wanted to make it as simple as possible, and I think we got there with the design and with the content. But we set those goals early on, so all of our discussions were shaped by an orienting statement, by branding and marketing standards that we had in place already, by the content that we were already creating out of our larger office, and by this sort of larger vision of we want to do something that sets us apart—but not too far apart.

So I would say involve as many people as you can without having “too many cooks in the kitchen” initially, and have more people available. [laughs] I laugh, but we’ve actually been fairly severely understaffed for quite a while and this team has done an amazing amount of work migrating websites—over 150 websites—while developing this website as well. But having a close, collaborative team that talks to one another, that shares visions, that isn’t afraid to share criticism, doing planning, lots of visibility testing, planning/testing for accessibility… All of those things helped our process go more smoothly. And having that CMS worked out in advance would probably be something I would have wished we had had earlier in the process so that that organic process that Mike described of creating content and design simultaneously could take place.

Michael:

Yeah, if your listeners are designer/developers, I would say collaborate really well with your writers and content folks, and listen to what they have to say because they are ultimately going to be the ones who are making the content that your users are coming to your site to see. And if your listeners are content folks, I would say collaborate really well with your designers. [laughs] Because that can make your stuff look awesome.

Leigh:

[laughs] And don’t spend a whole lot of time having chicken and egg discussions, because you will get stuck.

Ethan:

I couldn’t have said it better myself. Well Michael, Leigh, thanks so much for joining us today. We really appreciate your time and are excited to see where UTK.edu goes next.

Michael:

Yeah, we are too! Thank you very much for allowing us to talk.

Leigh:

Yes, thank you.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast. Thanks also to our sponsor, GatherContent. Go to gathercontent.com and take control of your content production process.

If your company wants to go responsive but you need help getting started, Ethan and I offer a two-day onsite workshop to help you make it happen. Visit responsivewebdesign.com/workshop to find out more and let us know your company is 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 for listening, and we’ll be back next week.