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, we are as excited as a Super Bowl in June. We are talking to Michael Edelstone and Nickolaus Wing from Texas State. Welcome, welcome!

Michael:

Thanks a lot for having us.

Nick:

Thank you.

Karen:

We’re so happy to have you.

Ethan:

But before we dive in, a few words about our sponsor. I couldn’t be happier to have Gather Content back as a sponsor on the podcast. You see, Gather Content is a content collaboration platform. It helps teams plan, organize, and produce all their web content in one place. They provide structured templates and simple workflows to make collaboration and production easy without the shuffling around of Word documents and unnecessary emails. Centralizing the editorial process will make approval of content easy, so everyone knows what they’re responsible for and when they’re responsible for it. And what’s more, Gather Content has recently published a free online guide to Content Strategy for Website Projects, which they’ve written for all the people who want to make smarter, content-led decisions on their designs. So every responsive design, I believe, benefits from a content-first approach. But as Gather Content’s guide says, that doesn’t mean waiting until all the content is written. Instead, it means considering and thinking about content at every single stage of your project. And Gather Content’s guide can help you do just that. So whether you’re working in an agency on client websites or maybe you’re working on an in-house team, Gather Content’s guide should help you more effectively contribute to your digital projects. You can read it online for free at gathercontent.com/RWD, or check out Gather Content’s products at gathercontent.com.

Karen:

So, I would love it if you could both start out, just introduce yourselves, tell me a little bit about what your role is at Texas State. Michael, do you want to go first?

Michael:

Yeah, sure. So I’m the web designer, my department is university marketing at Texas State. Because of the nature of the team here, I tend to be more of a generalist. So I do a lot of the design, I’m low and high fidelity, but I also do web copy and web publishing; I manage the home page, and I do some branding as well. So I’m kind of all over the place over here just because of the lean nature of our team here.

Nick:

And I am the lead developer for the content management system on campus, and our learning management system as well. Our content management system contains the vast majority of the websites on campus, I think only computer science does their own thing because they have the skills for it. So, we have in total about 400 sites, about 50,000 pages, and about 1,000 part-time content editors, so that presents a lot of unique challenges for us that might be different from a lot of other teams that might come on the show.

At one point we even stopped referring to it as a redesign, we started using the word “update” instead, simply because we just didn’t want to ruffle too many feathers.

Karen:

I’d love to hear a little bit about the decision to go responsive. So, were there questions or concerns or challenges that you had to overcome in implementing responsive design in such a large, decentralized framework?

Michael:

So, at the time when we decided we wanted to do a redesign, we hadn’t updated our web properties since 2009. In fact, the template that we were using we called “The 2009 Template.” So when we first started talking about doing a major redesign, I think that the biggest problem was that people were just frightened of that in general—definitely more at the higher levels because there it just kind of gets political in an organization like this. Their biggest concern was, “Okay, well how are all of our constituents going to feel about this?” as opposed to, “Give me the nitty gritty details of what would be involved in a redesign.” In fact, at one point we even stopped referring to it as a redesign, we started using the word “update” instead, simply because we just didn’t want to ruffle too many feathers. We knew this was going to be a big change, and the tolerance for change sometimes at those higher levels is a little bit difficult. I think it’s a common institutional problem.

We ran four separate focus groups and I’d say the biggest takeaway was that the templates we were going to release needed to be responsive.

So, the buzzword of responsive wasn’t really thrown around too much in the beginning of 2015 when we first started embarking on this, and later on, in order to increase the momentum and increase the buy-in from all of our stakeholders, including executives, we did start to kind of put out the word “responsive” in the way that we were saying, “Hey, look, there are competing institutions here, like University of Texas or Texas Tech, who are doing responsive designs.” We even at one point made a chart of who in Texas was responsive, who’s just got a mobile-specific template or an adaptive design, and who has nothing. Our home page at the time didn’t even have a mobile template, it was just the desktop site on a mobile phone. And so at that point, when those people have that kind of attitude of, “Keeping up with the Joneses” and a lot of them came from competing institutions previously… At that point, I think the attitude shifted to, “When can we have this?” as opposed to, “Okay, let’s worry about what all of our constituents are going to think.”

And just real quick on that level from the constituents: early on we kind of knew we were going to need some kind of swell of support from the rank and file, if you will, and so we ran a series of focus groups. At the time, I had been playing around aimlessly, not really knowing if some of these web prototypes that I was playing with would see the light of day, but it kind of gave us an opportunity to demo those, and they were responsive. We ran four separate focus groups and I’d say the biggest takeaway was that the templates we were going to release needed to be responsive. We were selling that concept to them, but I think most of the people there already knew that we needed to be there, we needed to be responsive in order to move forward.

Nick:

From my perspective in IT as well, I think it wasn’t a hard sell. This is where everything is going, this is something everybody understands we have to do. You mentioned the home page didn’t have a mobile template, but of course most of the rest of the website had a user agent-based swap to a mobile template, just not the home page. So, it was in people’s minds that we needed to support these devices, and responsive is just sort of the next step of, okay, now we need to support everything in between and do it in a really elegant way. But there was a lot of support in my part of the organization for a long time for this, and we were waiting for Michael to come and give us something really good like this.

Michael:

Right, we knew it was going to be a pretty big job. Where our CMS was at the time—I know we’ll probably talk more about this, but—we hadn’t updated the design in a while, but we had also needed to update to the newest version of our CMS, and that was going to be a big job as well.

I never thought about mobile and desktop users too differently. Our general philosophy was that people are trying to complete tasks and we just want to be able to have them do that as conveniently as possible.

Ethan:

Well before we dive into CMS matters, just hearing you talk about circulating the idea of responsive throughout the university, I’m just curious if, while you were talking to these constituents, given how distributed they are, were words like mobile and desktop thrown around? And specifically I’m curious because that’s something a lot of organizations struggle with, right? There’s still this idea of different camps or different user needs for different contexts, that mobile users need less information, that desktop users need more. When you’re designing for such a distributed framework of users, how did you think about those terms and how did that inform the responsive design?

Michael:

So I think, to me, I never thought about mobile and desktop users too differently. Our general philosophy was that people are trying to complete tasks and we just want to be able to have them do that as conveniently as possible.

But institutionally I think there was this app mentality, that, “Oh, we have an app for that.” The university does have a mobile app, but of course the audience is completely different than what we’re talking about. We do know that some of our websites are much more important that they are mobile-friendly and that the content should be geared more towards a mobile audience simply because they’re much younger. We can look at the stats and we can see that generally, across the university, we’re thirty to forty percent mobile views. But some of these sites that are a much younger audience are seeing between a sixty and seventy percent mobile use. And so, it was obvious that we needed to go there.

But yeah, I think we still see the bias even in those units that have the mobile audience. They’re editing these web pages on desktop machines, they’re choosing layouts that I would say are very desktop-specific. I think they’re okay with sacrificing certain bits of content if they’re hidden or they don’t function correctly on a mobile device. It’s really kind of just an ongoing conversation that we’re having with all of our stakeholders. There’s so few of us that are doing it and there’s so many editors out there in this decentralized fashion that it is a huge challenge, but it’s something that we’re looking at and trying to solve pretty actively.

Nick:

And I think specifically with this project, it’s been more of a challenge just to get people to think of mobile as well, just to get started about thinking about it, that going beyond to the next step of, “Okay, now what are mobile users looking to do that maybe desktop users are looking to do something different, or maybe they’re more likely to do one of those tasks?” We have that in the back of our head and we certainly try to pay attention to that when we’re working on the app, but in this case it’s really just stop thinking about desktop all the time and think there’s other devices out there and we need to think about them while we’re developing the content all the time.

In our case, we consider our editors to be more like users, so we sort of have a user base of editors and a user base of students and faculty and staff that are using the web pages that are produced by the editors.

Karen:

Well let me follow up on what Ethan knows is my most favorite subject, which is talk to me a little bit about the CMS and how questions around what the content is and maybe how the content is structured, particularly in such a large and distributed environment—how does that affect your responsive redesign?

Nick:

It’s really challenging to work in such an environment with so many editors, because I think in a lot of situations with the CMS, you have sort of a centralized team of content editors that you consider to be part of your team, part of the website team. But in our case, we consider our editors to be more like users, so we sort of have a user base of editors and a user base of students and faculty and staff that are using the web pages that are produced by the editors, and it’s a challenging way to think about things. You have two user bases instead of having a team, and then you have users. And since we have so many editors, we can’t really build pages for every site, we can’t build templates for every department around campus, so we try to build this template that’s sort of a one-size-fits-all, you can build whatever kind of content that you think is appropriate for your audience, and we sort of have to offload some of that catering to the website users to our content editors.

Michael:

Yeah, I agree, you summed it up very nicely. And I would say even within this editor base, it’s always shifting. We have people here whose title is “Admin II,” and there’s people that are marketing coordinators… People have such varying levels of abilities, and they’re coming and going all of the time.

And as well, like I mentioned before, you’ve got really different types of websites that we’re trying to put everybody under the same umbrella. We want undergraduate admissions to use the same templates, the same tools, with the same level of support as we want the budget office or parking—and up to 400 websites, there’s some pretty obscure ones out there. So yeah, it’s a huge challenge to figure out how to do that. I would say that’s kind of the phase we’re in right now. I think what we’re doing is trying to think about it more holistically, is just how do we help people make better web pages? We do have this perspective where they’re users, we need to train them on the technical tools, how to work in the CMS. But at the same time, I’m in the university marketing office, so we’re thinking, “This is our public face, this is the touchpoint that people are interacting with us more than ever.”

We had, in the past, gotten a lot of PSD files that we would have to slice up. Getting the really high fidelity prototypes that were already HTML and CSS, it was different, I think it was better.

Ethan:

Tell me a little bit about the process you used to manage creating the layouts for this responsive design. What kind of applications and tools were you using? Was it a mock-up focused approach? How did you circulate the design to your constituents? I’d just like to hear a little bit more about how you structured that.

Michael:

So, when I came on board here, there was not a whole lot of direction that a project like this needed to happen. We have some high-level properties that we’re focused on as far as the content on research initiatives, things like that on the web, that just as the central office here, we need to pay attention to, that I was working on. But at the same time, I recognized obviously, look, at some point we’re going to update this stuff, I’m going to be involved, and I just like playing around with the web—obviously I’m in a good job for that. And so what I started doing was taking our brand elements, taking logos, taking colors, stuff that we hadn’t used in a very bold way prior to that, and honestly just started making a demo of what I thought the university marketing website—because again, I am a content editor, I manage the university marketing site—just kind of saying, “This would be what I would like the university marketing website to look like.” Honestly, because I knew it was only me looking at it, it was little bit almost like a side project, that I really just went straight to HTML and CSS and just kind of set up a GitHub and was playing around with it there. Of course, I was learning about responsive design at the time, so I decided to do that.

Then it kind of sat there for a while and when we decided to kick all of this off, it was a really good time to say, “I’ve already kind of got the ball rolling here.” I don’t know how that was received necessarily from the developers, that my design process is a little bit in the browser and I like to use code and I’m making decisions about grids and things like that. But that was where we were, and so we kind of just started iterating on that. We had this kind of demo of what—this is template-specific for the subpages, not home page—but we had this demo that we were working with. We did some focus groups, we got some feedback from that, and so I made a second version, and we just kind of started versioning that in GitHub. I got feedback, just based on the links to the websites, from the people that were in the focus groups in a kind of continual follow-up feedback mode, and then we would share those with the developers and with the people who were running the project on the development side. It was also an easy way for me to share it with people here, and there wasn’t much concern about my methodology or anything like that.

So, for the most part it was really kind of straight to high fidelity—HTML and CSS and GitHub were our major tools. Moving forward, I think because we’d established all of these patterns that are familiar to the entire team, myself and all of my superiors and the developers too, I think now what we’re seeing more is that we’re just wireframing stuff. We’re using recognizable patterns, and so it’s clear when we’re going to iterate on something or when we want to do something like what we’re doing now with trying to update our search engine. I’m just using wireframes in order to get the point across about how it should work—and we use Balsamiq for that, just kind of on a tool piece. So, it’s kind of a mix, it was kind of an interesting process, I’m not sure if it’s very traditional at all.

When you’re talking about responsive design, it’s really difficult to make low-fidelity mock-ups and wireframes because you just have to make a lot of them.

Nick:

It certainly was a change from our side. We had, in the past, gotten a lot of PSD files that we would have to slice up and try to build everything around it. Getting the really high fidelity prototypes from Michael that were already HTML and CSS, it was different, I think it was better. I mean, we certainly second-guessed some of the decisions that he made and changed the CSS around, but that’s our prerogative as developers, right? Especially when you’re talking about responsive design, it’s really difficult to make low-fidelity mock-ups and wireframes because you just have to make a lot of them. You have to make one for mobile, you have to make one for somewhere in between—probably three or four in between—and then you just have to sort of look at them and switch between them and think, “Okay, this is how it changes.” But when he delivered us an HTML and CSS prototype, I would just change the browser window and I could see how it changes because most of that stuff he had already put in there, which I think is a really helpful way to do responsive. It seems to me that it’s very cumbersome to be looking at four different drawings of the same thing and trying to figure out, well, when did it switch to this, and how did it switch to this?

Michael:

Right, there were some growing pains there, because honestly, at the time when I made the initial prototypes, I was still learning, so I kind of built a responsive grid from scratch just based on a little tutorial that I had found. And so that kind of got wedged in there, the fact that there was kind of this backlog of learning that could probably have been rejected at some point in a proper development process. The units that we were using had changed, and so there was a lot of designer/developer back and forth there for a little bit. But then an interesting thing happened that I think we both appreciated, is when we started sitting down together from a design and a developer perspective, whereas before I think it was very much, “Okay, the designer, you do the design; you’re the brand guy; developer, okay, I’ll handle all of the technical anything, any of the ‘How it works’ decisions.” I think we saw a lot more overlap. We started communicating more on a deeper level, making decisions together and challenging each other on the conventions that we had thought existed, and so really in the long run it worked out great.

Now where we’re at, where we’ve got this design built up, when we want to add a feature or something like that, it’s easy to just kind of throw it on one of our CMS web pages and just say, “Hey, what do people think about this?” and tweak the CSS a little bit or whatever. Iterating now is so much smoother, I think is the big thing, than if we had stuck with the previous PSD to HTML setup that I think a lot of people have done in the past.

Karen:

I’d love to follow up on how you solicited feedback from people on these prototypes or in these focus group sessions. Did you have to explain how responsive design works to them and what they were giving feedback on and how that might be different? Did they have to provide feedback to you in different ways because they were looking at a responsive prototype?

Michael:

We definitely needed to explain how it worked. I would say that a lot of people that we were dealing with knew that, knew what we were talking about; it was a refresher for them. Because again, it’s a little bit of a self-selected group because we put out the notice that we wanted to do these focus groups. So the people that were attending them, there were more advanced people there. But at the same time, a lot of the people that were attending had been told that they should attend by a supervisor or something like that. So we had a good mix of people, and for sure we needed to just kind of rudimentary give the background, give the basics, “What is responsiveness? Why is it great? Why is it great for you and your audience?” And soliciting feedback for it… I mean, for our grouping, I think we are just so glad that we can update a digital product here, because we really hadn’t in so long. The feedback was just so positive, I don’t think that there was any special thing that needed to happen from the focus group users that was any more specific than just overwhelming support for it.

Ethan:

Well speaking of support, I’d love to hear a little bit about how you managed the QA and testing process. All these terrible devices we’re designing for now, how did you actually start looking at the new responsive design on them? How did you start gathering feedback and tracking issues, and how did you determine how to support all these mobile devices of different capabilities?

Nick:

So, first and foremost, you have to have all of those devices, so that was a process that we’ve been working more and more on, just to get some of those devices in our office so that we can pass them around. We do have a support team that has traditionally handled our testing, and so from probably the beginning of October 2015 until December, we were in just really heavy testing mode, and they pulled in more people than we usually have for support for the CMS during that time as well. So I think we had maybe six or seven people that were spending pretty much all of their day just poking around on different websites.

A lot of our websites already existed, of course, so they had to be transitioned to the new template, and that’s both an automatic process and one that needs some further editing to make it work. I mean, you have content, and if you just typed a paragraph or something then you switched the template to our new one and suddenly everything is responsive and it’s great and there’s no problem. But of course, a lot of people had more complex constructions in their main content area, and so we had to worry about the best way to migrate that content over to make it look good in the new template. So, we had a lot of people just looking at the way sites looked after the automatic shift, and then a lot of our own websites internally, like we have our department websites and we have one that’s about the CMS, and we have probably seven to eight that people in our support area are also the editors for those sites, so we focused a lot on getting those migrated over… Again, we still sort of have these two user bases, right? We have our editors and we have people that are using the site, so we had to evaluate it from both of those directions. That was just an intense process over a few months of spending a lot of time on it. I don’t know how else to attack it.

Michael:

Right. And again, I think we benefited from me being an editor—for my first year here, that was kind of what I was focusing on, I was the CMS editor, that’s what I was doing, I was perfecting that skill. And then because I understood how it worked and I had some opinions about how it should work, when we moved into the testing phase and we were doing a lot of back and forth, I was participating in that, too. So again, like Nick said, we had an all-hands-on-deck because this change was so huge, there were so many different ways that we could test this. It was definitely more than just, okay, let’s make sure we cover our main browsers and shrink the screen down, and stuff like that. We knew that people had content that was valuable that they were going to be moving over.

It’s not data, it’s definitely anecdotal, but from a political perspective, everybody here is very pleased with what we’ve delivered.

Karen:

Broadly, how do you measure the success of this responsive redesign, or how do you know if the site is working for you? What sort of research or data or analytics do you have that tells you what’s successful and what might need to change?

Michael:

So, first off, it’s not data, it’s definitely anecdotal, but from a political perspective, everybody here is very pleased with what we’ve delivered. I shouldn’t say everybody—obviously there’s criticism. But from the people that we were trying to please at an executive level, it worked, and I think there’s a lot of optimism about this team and where we’ll go. From a user level, I didn’t mention it, but another thing that’s changed is I talk a lot more to users now. And again, it’s pretty positive; people are pretty happy with the new tools and the layout. There were so many things that were updated, it’s hard not to be if you kind of remember the old days. As far as on a data level, we don’t really do too much. We move so rapidly that we don’t do too much.

I would say that we have noticed that our bounce rates have gone down for mobile devices across a lot of our sites, specifically home page and the other pages that I manage. But that’s really it. We don’t tend to look at data. I think it’s extremely useful to be informed by it, but I think it would be hard to imagine a scenario where the changes that we made didn’t have an impact.

Ethan:

Well Michael, Nickolaus, I’ve got to say, this has been a really great chat. But before we let you go, I’d love to hear if you’ve learned anything from this responsive redesign that you’d like to share with our audience. If there’s someone out there who’s about to start a responsive redesign today, what’s one or two things that you’ve learned that you’d like to share with them?

Michael:

Honestly, I learned so much from this process. I honestly didn’t consider myself a very experienced designer or content manager or anything before this process started. Over the last year, I’ve learned so much. But a couple things, if I was talking about this in terms of advice for other people in my situation, from a higher education specific sense maybe, or just larger organizations generally, I’d say the best thing that you could do is to seek out opportunities. Find the gaps in the organization, which I’m sure exist, and just fill them. Become an expert in those, and you can build really useful things for the organization. And it’s a lot of fun, too. You don’t need to be a go-getter type of person in order to figure out where those gaps are. This is your career and you need to worry about that, too. But it’s great for the organization.

And then kind of on a general designer level, and it’s come up a couple times in this conversation because I’m pretty big on it, I’d say integrate yourself in the design process generally, into the technical and development process. Learn the language of your developers and have a conversation, have opinions about how the product should actually work and behave in addition to the wrapper and the color and all those things that designers typically focus on. And if you learn tools like GitHub and high fidelity design with HTML and CSS, designing in the browser, I think you’ll create a pretty nice space for yourself if you can master those things.

Nick:

I think the advice that I have would be a little bit more specific, maybe. I think one of the things that I learned was that when you start thinking about responsive design, you have to start thinking about each of the things that you build in terms of the size of the container that it’s going to be in. So, one of the things that we learned fairly early on was that since we have so many editors and since we’re trying to build this template that’s everything to everybody, and we tried to build the ability to add the column layout to the page where you could say, “I want to add four columns and then I want to put more stuff inside those columns, and I don’t know what it’s going to be yet, that’s what my editor is supposed to do, is to figure out what goes in these four columns”… So every time we built something, we had to think about what’s it look like when it’s using it the full width, what’s it look like on a desktop, what’s it look like on a mobile. Now what’s it look like when it’s in one of four columns, and what’s on desktop and what’s on mobile? And so, that can get to be a beast to think about very, very quickly; there’s just so many possible combinations.

So, I think we had to sort of reshape our thinking into just, alright, here’s how we present events from our event calendar, and how much space do I have right now to display those events? Let’s just think about that; let’s forget about whether I’m on mobile or not, let’s just think, okay, maybe I’m in four columns on a desktop, maybe I’m on mobile and one column. I still only have 300 pixels to work with, so let’s just worry about that. I think that simplified things a little bit, and we came up with a lot of technology solutions around that, where we started using element queries and we started doing things with images where we would size them just to what they are on the screen. Maybe that’s very specific advice, but maybe it’ll help someone.

Michael:

I think that was even better than what I said, because it’s so pertinent to what you both do on this podcast. What I was getting at too with working closely with developers is that kind of thinking about those tools. Like Nick mentioned, we found element queries and these other solutions. We were making decisions about grids, we were making decisions about frameworks or things like font awesome and stuff like that. I would say think about stuff like that early on. Do some research on to the tool set that you want to use, and how you’re going to communicate, and how you’re going to get it built in the long run before you do too much work. And then again, just on that note, because a lot of organizations have so much to do and there’s tons of priorities, limited resources, we’ve all been there, but just kind of chip away at it, and every time you make a decision, try and scale that as far as you can and future-proof it as much as you can.

Karen:

Well Michael, Nickolaus, I guarantee you that all of this advice will be really helpful for people. Thank you so much for taking the time to come on the show and share it.

Michael:

Yeah, you’re awesome. Thanks a lot for having us.

Nick:

Thanks for having us.

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.