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 am just about beside myself with excitement to have Mike Donahue from Citrix joining us. Mike, welcome.

Mike:

Glad to be here Karen, thank you.

It was previously built on SharePoint, which is pretty common for most intranets. But we noticed there were some issues with that.

Karen:

I’d love it if you could introduce yourself; tell us a little bit about what you do at Citrix. This is the first time we’ve had a guest on the show that’s going to talk about a responsive intranet. So, perhaps tell us a little bit about that.

Mike:

As you said, I work here at Citrix. I was the lead UX architect on our redesign of the corporate intranet. The intranet serves about 10,000 employees. It was previously built on SharePoint, which is pretty common for most intranets. But we noticed there were some issues with that. Probably the single biggest one that we had heard about was the really poor relevancy of search results. That became one of our foundations for how we wanted to rebuild the whole thing and make it much more search-centric rather than a very navigation-driven type of experience.

I came back in and proposed that “we need to work content out, think mobile first, and then build up progressive enhancement,” and all of those fun buzzwords that everybody is using.

I was brought in specifically because of having some background in responsive design from my previous place, so I just jumped right in. I wanted to take everything back a step. The project had been started by a different team within Citrix and when they realized that it kind of wasn’t getting to where they wanted to go—no fault to the people who were currently working on it—but it just wasn’t progressing the way they had thought.

We all dropped back and started from scratch and that’s when I went in and proposed that we start working this from a whole different perspective. Responsive was already a given but what they really didn’t have was a great strategy at the beginning. I came back in and proposed that “we need to work content out, think mobile first, and then build up progressive enhancement,” and all of those fun buzzwords that everybody is using. I met with everybody, we held a huge team meeting up front, we got key stakeholders from pretty much every department that really hadn’t tackled this project or anything like this in that way prior. It was amazing how different it became once we got all the right people in the room at the same time and level set everybody on how we would approach things. The buy-in was pretty straightforward, and once that was done we were off to the races.

The bigger challenges came around trying to convince people to not jump in and start designing a website, but to drop back and start looking at their content.

Karen:

I’m always intrigued when organizations say that responsive “was a given” or a “no-brainer.” Were there any challenges in those initial conversations? Any concerns, frustrations, or difficult discussions that you had to have around responsive as an approach or a methodology?

Mike:

Not so much with responsive itself. Like I said, they brought me on specifically because they had decided to do the intranet responsive. They just didn’t have anybody here at that time who had much experience with responsive, and that’s why I was hired on in the beginning. The bigger challenges came around trying to convince people to not jump in and start designing a website, but to drop back and start looking at their content.

One of our key drivers, and it goes right in line with what Citrix tries to promote with all the products and services that we sell, was this any time, any where, any device connectivity.

Ethan:

One thing that struck me in listening to you is in the early days of responsive design, there was all this talk about the so-called mobile context, that mobile users were on the go, running down the street trying to catch a bus, so we should be providing them with less information. We’ve matured past that a little bit, but one of the things I hear when talking to people that are redesigning intranets is that there’s almost a desktop context when you’re designing for internal users who might be seated at workstations or the like. How does Citrix think about those two words, mobile and desktop? And how did that shape the responsive product?

Mike:

Actually one of the first things that I did when we first kicked off this project was I did a presentation to the entire group, and one of the parts of that presentation was to go right at some of those preconceptions that people were going to have about mobile. “Well, they’re not going to want to do this if they’re on their phone,” and “they’re not going to want to read that if they’re on their phone,” and “they’re only going to do this if they’re on desktop.” I went through all of that stuff. We know that there’s a lot of research out there now proving that people are using their mobile phones, in some cases, it’s the only thing they use, and they use it in all contexts. They use it while they’re sitting on their couch watching TV, et cetera. To get people to understand that you just don’t know what people are going to need at any given point in time, one of the use cases that we shared happened to be one of our managers. His wife had gotten sick and had to go to the hospital and suddenly he needed some information about his insurance, and he couldn’t get to it while he was not connected to the network at the office.

We put that whole thing to bed and didn’t focus so much on the two separate experiences, so much as really focusing on what the user needs.

One of our key drivers, and it goes right in line with what Citrix tries to promote with all the products and services that we sell, was this any time, any where, any device connectivity. We did away with the whole notion of desktop and mobile needing to absolutely be two separate things. I really pushed what Luke Wroblewski talks about, which is you have to understand who your users are and use a mobile first approach to identify the limitations and capabilities of both the device and the user. We focused more on context than we did on the devices and I think that really helped us refine the feature sets that we provide, the content that was created—we stripped out a ton of content from the old SharePoint site—we really drilled down to what was absolutely necessary. We put that whole thing to bed and didn’t focus so much on the two separate experiences, so much as really focusing on what the user needs.

The overriding thing that drove a lot of the decision-making on what stayed and what didn’t was this idea that we wanted to create this one Citrix point of contact, and that definitely impacted a lot of the scope.

Karen:

How did you plan and scope the project itself as well as the rollout of the responsive redesign? How did you plan for time for cleaning up the content or revising the design, and how did that factor into your rollout strategy? Did you do it all at once or did you do it in pieces?

Mike:

The rollout itself came all at once. In fact, we just did the full launch at the very beginning of February. We did, however, do a nice sized beta rollout to about a tenth of our population to get in there, start getting feedback from the users, and to start making refinements before we even had our main launch.

As far as the overall scoping of things, that happened a level or two up from me. I was not the person responsible for most of that. I had input on it, but most of it was handled by our project manager. But it was all done through a lot of collaboration with stakeholders, a lot of user research upfront to find the things that were most important. We really whittled it down to “We need to make search work,” that was not an option, “we need to improve the internal support experience,” trying to give people the ability to create tickets for internal help much more quickly and easily.

But the overriding thing that drove a lot of the decision-making on what stayed and what didn’t was this idea that we wanted to create this one Citrix point of contact, and that definitely impacted a lot of the scope. For instance, on the SharePoint site we had probably about 14,000 team sites that were built, but if you remember, we only had like 10,000 employees, so people were getting a little crazy with that stuff. That was one of the things that, for v1, we knew it was out of scope immediately. There was no way we were going to deal with that.

Within Citrix, we need tools that everybody can work with and not all of our UX team, or outside of development, has the same skill levels of being able to do it through CSS.

Ethan:

You mentioned earlier that you’ve had a significant amount of experience with responsive design, both at Citrix and then with previous engagements. How, if at all, has your design process changed over the years? As you’ve been doing more multi-device, more responsive work, have you changed the way that you work?

Mike:

There are two answers to that question. For me personally—yeah, absolutely, and it’s constantly evolving. I’m leaning more towards, whenever possible, to developing in-browser using various frameworks or going out to CodePen or something like that and doing things on screen, making it fully responsive and being able to test how my content is working in there.

But within Citrix, we need tools that everybody can work with and not all of our UX team, or outside of development, has the same skill levels of being able to do it through CSS. So, I’m also looking at a lot new tools that I’m just uncovering fairly recently, things like Macaw, Responsive Layout Maker Pro, Edge Reflow, AnteType—things like this that are getting better at making it possible for somebody who doesn’t know how to code to do pretty good at creating responsive layouts.

We’ve been using Axure, but the challenge with Axure is you have to make three separate breakpoints that are stiff. You’re basically doing three screen sizes and not a true responsive thing, so you don’t really see what some of those in-between sizes are where your content is breaking in between various breakpoints. I’m constantly looking for new things to help with that, and some of these new tools are looking pretty promising. The one that has piqued my interest right now is Responsive Layout Maker Pro—I have to look at that more deeply. But I also know Macaw 2 is coming out soon and we’ll take another look at that when that comes out.

In a company like this, you always need to have some of that stuff so that you can create the artifacts that are going to stick around that people can rely on as the company memory.

Ethan:

Putting the tools aside for one minute, could you tell me more about how you collaborate with other UX professionals at Citrix? How do you actually work together, what kind of mock-ups and prototypes are you reviewing and creating, and do you find yourself actually hiring different roles or organizing teams differently?

Mike:

Lots of good questions there. I just got done reading Jeff Gothelf’s book on Lean UX six months or so ago, and that’s been shifting me away from some of those tools. But in a company like this, you always need to have some of that stuff so that you can create the artifacts that are going to stick around that people can rely on as the company memory. But for a lot of stuff, I’ve really tried to shift towards minimizing that and going more whiteboarding.

We get an idea, we comp something up real quick, we test it out and we make adjustments fast.

The way we organized the team for our intranet project is they pulled together a complete cross-sect functional team—we have our devs, our visual designers, myself as UX, our QA, our strategist. We all sit in one area, no walls, and so whenever a conversation needs to happen on something, it happens right away and we’re able to make changes and be very quick in responding to finding problems. When we see something of “Well, you know, we thought this would work one way, but we’re seeing it’s not,” we’re able to make adjustments more quickly because of that. It really has been great to be sitting next to the developers because, relative to these guys, I know nothing. But I know enough about code that I can sit with them, we can discuss the challenges; I can propose some kind of wacky things sometimes and they look at me funny, and then we discuss it and I can actually have a conversation with them. “How can we actually implement this now?” The same goes for our designer. It’s been really great to have a team that’s been so open-minded and willing to talk about things.

The other thing that is different for me here at Citrix than in any other place I’ve worked before is they really believe in the whole design thinking process, and so we do a lot of that here. We get an idea, we comp something up real quick, we test it out and we make adjustments fast. For me, that personally was a big shift in process—that and also working in an agile environment versus the waterfalls that I had been in before.

We don’t want to be market-y to our own internal employees, so we’re going to get rid of anything that just sounds like we’re trying to sell our way of doing business to our own employees.

Karen:

You’ve mentioned a couple times already that one huge component of this project was cleaning up and paring down some of the content. Can you talk about how that process was managed? I’d be particularly interested in how that editorial and content clean-up process was managed alongside the design process. How did you ensure that the content team and the design and development team were working together?

Mike:

One of the things that we did early on, right at the very beginning of it in fact, was we actually created a design persona based on the template that Aarron Walters created, and we worked that out as a team. We wrote down “If this site were a person, how would it speak to people?” We went through that exercise, we got a really well thought out design persona put together, and we’ve been using that a lot of the time as sort of our tiebreaker. When it comes down to how something is going to be written or what we’re going to include, we say “Well, what would Claire say?” That’s the name of the persona that we created. “How would Claire handle this?” We used it as a way to be a little more objective about things because you kind of have that third person involved as a moderator of sorts, because sometimes you get real close to stuff, you think you know all the answers, but you have to throw on somebody else’s glasses and their lenses in order to really see it in a different light. That helped us out a lot.

One of our early successes was in our benefits section alone, we managed to cut down something like 215 pages of content down to about twenty, and it was because we sat with the HR team and we co-developed and co-created their content with them.

The other thing was we had a full team that did a complete audit of the site—that’s how we uncovered that we had 14,000 team sites. We went back, and we had our principles that we defined in that design persona as well. “Here are the principles that we’re going to be following.” We want our content to be appropriately concise, we don’t want to be overly wordy on stuff, we just want to tell them what they need to know and get out. We don’t want to be market-y to our own internal employees, so we’re going to get rid of anything that just sounds like we’re trying to sell our way of doing business to our own employees. “They should know this, they should already feel it.” So, we cut out a lot of that cruft that was in there.

At the very beginning, one of our early successes that we like to tell people was in our benefits section alone, we managed to cut down something like 215 pages of content down to about twenty, and it was because we sat with the HR team and we co-developed and co-created their content with them. We had a lot of workshop sessions with them and we went through the process of really—again, coming back to Claire—“Is this the way Claire would say this? Are we being overly wordy here? Can we reduce this some more?” We had some really great content writers working with us, the team that owned that content was very eager, they wanted people to make more use of this content because they knew it was important but they also realized that they had probably gone overboard because they were so close to it. They were writing it the way HR people would think about it and not necessarily the way the general person would think about stuff. It was really a wonderful and great example of when you can get people aligned on goals and strategies, that you can have these open conversations and really whittle things down to just what you truly need.

The less stuff we have to translate, the less costly it’s going to be to do the translation. So there was some plain ’ol bottom dollar ROI to us getting better at doing the content.

I tend to throw out something Kristina Halvorson used to say, which is to “edit ruthlessly.” We really took that to heart and got people to seriously rethink and re-evaluate some of the stuff they had on the site for its merit within this new version. Also, knowing that people were going to be using this on their mobile device, and you don’t want to just cut stuff out because they’re on mobile, “We have to figure out how we can make this more digestible.” So readability too, in the sense of being able to physically read it; dealing with typography and adjusting font sizes was one thing, but also readability and the language, making it more understandable, because Citrix is a global company too, we knew certain stuff was going to have to be translated. The less stuff we have to translate, the less costly it’s going to be to do the translation. So there was some plain ’ol bottom dollar ROI to us getting better at doing the content.

We would just take certain components, build that out for a sprint, do a review and a demo of that with the stakeholders. We were doing that every two weeks, so we had a pretty constant feedback loop going on.

Ethan:

As you’re working on this responsive prototype, as you’re iterating over the content, the interface, how do you actually talk about your progress within the team? How did you evaluate its quality? Has that process changed at all since rolling this out?

Mike:

There were two ways we were doing it. One way was just through some guerrilla user research, get a little something done, go done to the cafe in our main office here and just grab people and start doing some interviews here. “Take a look. What do you think of this?” and that kind of stuff. Another aspect to it was because we’re working agile, every two weeks we were having a demo of our progress with key stakeholders as well. So, we began with the most basic things. I won’t say we went quite so far as to be doing the true atomic, drill it down to the smallest piece kind of thing like Brad Frost talks about. But we would just take certain components, build that out for a sprint, do a review and a demo of that with the stakeholders. We were doing that every two weeks, so we had a pretty constant feedback loop going on.

We haven’t really changed too much of that at this point, however moving forward we’re looking into using an online user testing site so it can help us facilitate a little bit better some of our research with our international people. I keep trying to tell them “Just get me some plane tickets, send me around the world, I’ll be happy to get test anywhere,” but I haven’t gotten too much buy-in on that yet. For right now, I’m going to have to settle for doing some more online stuff. We use GoToMeeting and we’re able to do some of that, but it’s not really ideal. We’re looking into additional ways to do that user testing and research on a more global level.

We were trying to reduce call volume to the call centers and raise the number of people who were just entering tickets online, and I’m happy to say that the success of that has gone way beyond what we thought it would be right out of the gate.

Karen:

How do you measure the success of this responsive redesign? What techniques do you have in place to know whether this is working or not?

Mike:

One of the things that we built into this intranet was we basically put feedback forms on every single page of the website. So, one way that we’re testing and trying to measure this is through the feedback. Mostly that gets us the negative feedback, which is always good because it shows us where we have room for improvement. The other thing that we’re trying to do there is that by doing that, we’re also helping to make people feel like what this really is an intranet that’s going to continue to grow with them because it was designed for our employees and they need to have some say in it. So, user satisfaction is another thing.

But there are also certain key things—search results is one—and we’re just now starting to get enough data to have some sense with how we’re progressing with improving search, because that was a huge pain point initially. Another way that we’re trying to measure it is on the support side. Two of the key metrics we were looking to target there is we were trying to reduce call volume to the call centers and raise the number of people who were just entering tickets online. I’m happy to say that the success of that has gone way beyond what we thought it would be right out of the gate. I don’t recall the exact figure for the reduction of call volume, but the increase in opening up tickets online using that service versus phone calls has gone up nearly fifty percent in just the first thirty days. We weren’t expecting that for probably three to six months, so we’re really, really happy about that.

As far as the business owner of that particular piece of this puzzle goes, he’s ecstatic, he couldn’t be more happy with the way that this has worked out.

But we do have some challenges with that. One of our teams, they had a very simple way of doing it on theirs but now that everybody is using the same system, we unfortunately had to take that tool away from them so we could have a more global system. They’re not entirely thrilled. That’s our first area that we’re coming back to, to continue to refine it and to try to improve, we have to still try to elevate that—so that one group. And they’re a pretty sizeable group, I’d say they account for ten to fifteen percent of the company. We want to try to get them back to being as satisfied as they rest of them. As far as the business owner of that particular piece of this puzzle goes, he’s ecstatic, he couldn’t be more happy with the way that this has worked out.

The other thing we’re trying to look at too are things like the news that was on the old intranet wasn’t getting as much readership as they would have liked, so we’re just now starting to track how that’s changing. Like I said, it’s only been thirty days, so everything is brand new and it’s kind of hard to tell for sure if the numbers are right, but they’re looking good in that we’ve helped improve the readership of the news for the company. In another sixty to ninety days, we’ll have enough data now to have a much more realistic and complete view of how we’re progressing.

Of all the challenges I had, trying to get complete buy-in on progressive enhancement is probably the single biggest challenge I had.

Ethan:

Well, strong start. That’s fantastic, Mike. One thing I’d really like to hear about is this idea of support. You mentioned earlier one of my favorite phrases of all time, which is progressive enhancement. How does Citrix talk about support in the context of this responsive design? Has your QA process changed at all?

Mike:

That gets a little out of my wheelhouse. I work with the QA teams; I don’t know how much it’s changed. In fact, I don’t know for sure that they’re actually disabling JavaScript and testing things like that. Of all the challenges I had, trying to get complete buy-in on progressive enhancement is probably the single biggest challenge I had and it’s not been implemented to the extent that I’d like it to be. We’re using Adobe CQ, the whole thing is based on Java and JavaScript for the interactions. There are certain things that they were not even able to build unless JavaScript was enabled. I’m not too worried about this on our internal intranet site because we have almost complete control over what browsers employees can use. One of the Citrix products is Citrix Receiver, and inside Citrix Receiver they can publish out specific browsers. So, for better or worse, internally we’re not having to worry about IE8 and 7 and 6 on these things.

But we have already seen where there are times—and I’ve been having an issue myself and I’ve been trying to see if we can get it recreated—one of my extensions in Chrome, every time I use it, it somehow disables the JavaScript just on our intranet. I don’t know why it is, because all the other sites that are using JavaScript run just fine. But something about Chrome and one of these extensions is killing JavaScript, and when it’s doing that my menus are dead. So, we’re working through that now and this is one of the things I’m using as an example of why we really need to be paying attention to this and trying to get better at making sure that we’re building escalators and not elevators.

Around here, I think they’re a little tired of hearing me preach on about ”Start working content out, mobile first, and progressive enhancement.”

Ethan:

Do you have any advice for organizations who are starting to think about going responsive? What have you learned as a result of this project?

Mike:

A few things. It really does—and I know this is a talk about responsive and I keep coming back to content—but it really is about starting there. Around here, I think they’re a little tired of hearing me preach on about “Start working content out, mobile first, and progressive enhancement,” but I really do think you’ve got to get back and you have to start with that content. You have to have a damn good reason for everything you put on the page and for everything you want to take off the page. Really understanding how that content is going to fill user needs—that’s where it all needs to start. After that, you start to focus on the mechanics of it and how to get things to rearrange and fill space appropriately. But it all starts with the content.

Our company motto is “Any time, anywhere, any device.” If you really want that, I think accessibility is sort of the pathway to getting there.

The next thing after that is when you do get into the mechanics and you start to actually build the site, focus on the accessibility. When you start thinking and really dealing with accessibility—and part of that I realize for some that their initial reaction would be “Well, I’m not building sites for handicapped people,” and I don’t think they realize at times that when you build these things that are accessible, you’re actually helping out more than just people with some sort of disability or handicap. Power users now have access to keyboard shortcuts. People like developers never like to pick up their mouse if they can avoid it. If they can just get through your site using the tab key the way a hearing impaired person would, both sides win. So, there’s a lot of upside to that.

Also, think about accessibility in terms of speed or images, et cetera. “Why am I putting an image on the page?” Make sure you’re dealing with accessibility as you build these things. That’s another one of those challenges where it can hard to get buy-in because it’s so hard to show the ROI of something like that in companies, a lot of people tend to gloss over it. But I really believe that it’s one of the keys to creating websites that are inclusive, that everybody can access no matter what. Especially around here. Like I said, our company motto is “Any time, anywhere, any device.” If you really want that, I think accessibility is sort of the pathway to getting there.

Karen:

Mike, I really appreciate your perspective. It was a pleasure to meet you in person and I’ve been looking forward to this interview for some time. I have to say, this has been even more interesting than I had hoped. So, thank you so much for being on the show!

Mike:

Glad to be here.

Ethan:

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

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near 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 podcast episode at responsivewebdesign.com.

Thanks for listening, and we’ll be back next week.