Episode Transcript

Ethan:

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

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well folks, I have to be honest, Karen and I have been high-fiving each other all day over Slack, because today we have Arquay Harris, who’s here to tell us about Slack.com’s new responsive redesign. Arquay, thank you so much for joining us.

Arquay:

Glad to be here. Thanks for having me.

Ethan:

Absolutely. So Arquay, maybe you could just introduce yourself a little bit to your listeners, tell us a little bit about yourself, what you do at Slack, and the role you played in this redesign.

Arquay:

Sure. So, I’ve been at Slack for about a year and a half, and I’m the director of two different groups. One is a team called customer acquisition, which is involved with the top of the marketing funnel, so Slack.com, and we do a little bit of lifecycle stuff as well. And then also another team that’s at the polar opposite bottom end of the funnel, and that’s called upgrades and expansion, and we are responsible for converting people from free to paid Slack. And so the team of engineers that I manage are both front-end and back-end engineers, and they work both inside the product and on Slack.com as well.

Ethan:

Well, that’s very cool. I mean I know at least for us, that Karen and I couldn’t run our very tiny, tiny podcasting empire without Slack every day. So, seriously, glad you’re here. But I’d love to hear a little bit about why this redesign happened. And maybe more specifically, in some of the early days, when you’re actually starting to plan for redesign Slack.com, were there any challenges that were seen or were there any considerations given to responsive design as a methodology? Were any questions coming up around that?

Arquay:

Definitely, and I can go into my involvement with the redesign and how it got started. So, I literally started this project a week after working at Slack. I was a new manager there and I went through the website and I did what I call an IA walkthrough—information architecture walkthrough—and I very non-judgmentally documented some of the issues with the site, be it things around SEO or performance and things like that. And then one of the really great things about Slack is it’s a very bottoms-up kind of company, where if you have a really great idea, it’s pretty easy to get buy-in on that idea. Meritocracy rules the day, I would say.

So, I created the presentation, I showed it to someone, they were like, “This is really great. You’ve gotta show it to the VP of product.” The VP of product was like, “This is really great. You’ve gotta show it to Stewart.” And so I would say within about two weeks of me doing this presentation, and the presentation was essentially why we needed to redo Slack.com, what are the benefits of doing this, how this can affect things like conversion and performance, and responsiveness, that kind of thing… I would say within a two week period, I was in a room with Stewart Butterfield, the CEO, and Cal Henderson the CTO, and Michael Lopp, and all these people, and they were all like, “Yeah, this is great. What do we need to do to support you and make this happen?” So, essentially we just spent a lot of time researching. We worked with content strategists, design; it was a very long process. And then that’s essentially how the project got started.

Karen:

I’d love to know maybe a little bit more about how Slack talks about the difference between a mobile user and a desktop user. I think that sometimes we’ll talk with organizations that tend to think that people on mobile need different information, or sometimes less information, and that responsive design isn’t really the right approach. Was that something you ran into there? I bet it wasn’t.

Arquay:

[laughs] So, interestingly enough, a little bit before we launched the site, Luke Wroblewski came to talk—he’s, as you probably know, a big proponent of the mobile-first design methodology. And so when we were looking at the site, the prior version of the site I would say already was pretty responsive, at least as well as it could be considering the organic way in which it was created. And so I think in that regard, when we first started doing the design system, we did do it from a mobile-first technique. So, we started looking at breakpoints and looking at them on kind of the smallest screen and increasing from there.

And then in terms of treating the users differently, I think it was more like if this content is extraneous on mobile, or if it’s causing a performance issue on mobile, then do we really need it on the desktop site? Is this information that’s really critical in conveying our message? And so I think that it was really, all along the way, keeping those things in mind as we developed the site.

Karen:

I love it. So you got executive buy-in for this. How did you figure out how to plan and scope this work? Did you have to go back to the executive team and give them some sense about how long this was going to take, and maybe how much it would cost, or who would have to be involved? And was there anything that was different or challenging about that because the site was going to be responsive?

Arquay:

So, we had some challenges along the way on this project—no one’s fault, just kind of “life” things that happen, and so that’s why there was probably a good year between when it first started and when we actually launched it. I would not say there were a lot of challenges in terms of getting people’s buy-in because it was responsive, it was more just being able to make a compelling case for why that was important. Because in addition to making the site responsive, we also had a goal of making the site accessibility compliant and making sure that we paid attention to all of the things that were important to our users.

Sometimes when stakeholders look at a project, you have a tendency to get myopic and be like, “Well, we have this goal, and we care about conversion, and that’s the most important thing, and how can we very quickly get the site out?” But being able to make the case that, “No, this is part of the craftsmanship, and this is part of our brand. This is why this is important,” and we want to make sure that we have craftsmanship not just in our product but in our website, and that we don’t want to cut corners where that is concerned. But I wouldn’t say that anyone put up any resistance or anything towards that. I think it was really just like, “Oh, this is—yeah, of course, this is totally what we want to do. This is totally on-brand and this is very important to our company and to our users.”

Ethan:

You mentioned craftsmanship a few times, Arquay, and I’d love to hear a little bit more about how responsive design as a consideration might have shaped the actual visual design process. When you were thinking not necessarily about mobile versus desktop, did that change the way that you partnered with designers at Slack to sort of figure out what this new design was going to look like?

Arquay:

Yeah, that’s a really good question. I think one of the things that Slack is known for is our brand and the playfulness of it. It’s very serious; it’s an enterprise software company, but we also have a very specific tone of voice and a very specific visual brand, and we are very known for that. And so we wanted to make a site visually that did a good job of capturing and illustrating all the benefits of Slack, but that also stayed true to those fundamental principles. And so when working with the designers, I think the challenge there was how do we make it so that the website is effective but also not just a wall of text, or how do we make the site playful but not silly.

And so there was a lot of design exploration, even in terms of things like how do we convey the very common iconography, how do you convey these really complex concepts of the site. Because Slack, in and of itself, is not just a one word thing that you can describe. It’s not just chat, or it’s not email killer—it’s not anything like that. It’s a very nuanced description that you have to have when talking about the product. I think in that regard, we were successful in being able to do that, and I think that the key there is just making sure that all the right people are in the room and part of the conversation, whether it’s our accessibility compliance program manager, who is keeping us on task and making sure that we’re not doing colors that are not accessible, and making sure that our copywriters are involved throughout the process, and that the dev team is in the room and thinking about ways that we can build this and make it responsive. So I think having this really collaborative approach really served us well.

Ethan:

That is wonderful. Maybe I could follow up on that, because I know a lot of organizations that we’ve spoken with have actually said that they’ve found that responsive design actually brings design and implementation much closer together internally, so that, let’s say, designers and front-end developers are working together more closely, maybe they’re doing more prototyping. Did you find that over the course of this redesign, or did you find that you were following a fairly traditional workflow?

Arquay:

No, I think that’s absolutely true, and that’s something that we discovered. At one point during the project we went up to Vancouver, which we have a very large office there, and we all did this kind of summit where all the designers and devs were all in one room together. That was really transformative for the project, because our designers work very closely with our developers, to the point where they would be sitting next to them. And also, by the way, a couple of our designers have a technical background, so they can suggest things, like, “Oh, what if we did this with the CSS,” or, “What if we kind of did this as we hit this breakpoint?” and so there were a lot of literally people sitting right next to each other, almost pair programming to get things just quite right.

I think that the other thing is having people being really collaborative in that way yielded a better product, because what happened was it wasn’t this environment where designers were just designing things and then throwing it over the fence and then having engineers code it. It was very much a designer would have an idea and then they’d run it past the dev, and the dev might actually give some input to ways that we could make it better, or refine it, or make it easier to build, as it were. And then it would just be a continual back and forth throughout the project.

Karen:

Let me ask about how you collaborated with the marketing people or the content people that were responsible for the messaging and the actual words that were going to appear on the site. Sometimes I find that teams really run into some challenges with figuring out how content is going to reflow at smaller screen sizes, or across all of the different sizes of screens. Did you run into any issues with that collaboration?

Arquay:

Yes and no. Speaking of earlier, when I mentioned the craftsmanship and how important that is to the Slack brand, getting the tone was very challenging for us certainly in this project, and so there was a lot of iteration on the copy, getting that messaging just right. I will say that in terms of responsiveness, one of the things that we did hit was, during this process, a couple days ago we just launched the international version of our site, and so thinking about responsiveness, when we were designing these things, for instance, “How is this h1 going to look when we translate it to German?” when you have very long characters that don’t necessarily have a line break. And what will happen to these buttons when we have French accents over them, and things like that. So that was, in some ways, a bit of a challenge because you also have to have the conversation with stakeholders that we are not making a magazine on the web.

Web design is meant to be responsive and fluid and meant to convey the information dependent upon the settings and circumstances of the user. So when you have things like, Oh, this is like an orphan, or Can we make this two lines instead of three? and just having to explain that if someone has their browser set to 150% zoom level, it’s totally up to them what they see. So, I think really just explaining that and putting it in context and educating and providing rationale for why something had to be one way or the other, again, not in a negative way, more in just a spirit of information kind of way.

Ethan:

Arquay, I might have just stood up and saluted. That was fantastic.

Arquay:

[laughs]

Ethan:

[laughs] No, that was beautifully said. But one thing I would love to hear a little bit about is when you’re making a case for how to design effectively for the web, I know you mentioned performance earlier—how did you actually plan for designing a new responsive site that was as fast as possible. Tell me a bit about how you managed that process.

Arquay:

Yeah, throughout this whole process I was very intent on documenting everything along the way. So, we used some kind of third party libraries to do before and after shots. We also catalogued what the both perceived and actual performance was of the site. We looked at page load and all these things, and the idea was I wanted to—sometimes when you’re making this case to stakeholders, it’s hard to show both qualitative and quantitative improvement. Qualitative is a very subjective thing, and how do you prove that the site is actually better? So for me, in order to bolster this conversation, I wanted to at least be able to show that there’s quantitative, measurable impact and improvement.

To your point, I think we had a lot of goals where I would say that the website redesign was probably thirty percent visual and seventy percent technical, and a lot of our goals did have to do with making the site more responsive and also more extendable. Because we were in a situation where we because the site had grown very organically, if we wanted to do something like change an h1 or adjust a thing on mobile or anything like that, it would be a very difficult process because the CSS was so specific and the code was in ten different places. So, I think it was this combination of making the site more performant, more responsive, more accessible, and also visually different.

Karen:

Let me ask more broadly about how you measure the success of the site overall. Given that there probably are some specific goals for marketing, or acquisition, or for providing customer support, how do you know if the site’s working?

Arquay:

Yeah, so I think any time you do a website like this for a corporate company, there are usually marketing goals that you have. So for us, it’s either things like conversion, or sometimes it’s page views. It depends on what the particular page is and whether or not we have performance marketing, drivers that are coming to the site. And so for us it was kind of a combination of those things, but one of the most important things that we were looking at in doing this was we didn’t want this to have a negative impact on sign-ups and/or conversion. Because usually we take a very data-driven approach to any changes that we do, we do a lot of experimentation, a lot of A/B tests, and so you can really incrementally measure the changes that you make to the site. But we did not do that here; we did a massive redesign change, we changed a lot of things at once, and in doing that it would be very difficult to tell what had a negative impact. Was it the font? Was it the color? What causes detrimental effect?

And so for us, I think we worked with our analytics department; before we launched the site, we made sure we had proper baselines. We did a rolling rollout, where we did like ten percent, fifty percent… We tried to wait until we could get enough traffic to see whether or not there was a positive or negative effect. And then once we felt pretty secure, we rolled it out to a hundred percent, gradually. I think it really just comes down to being really cautious, having a plan, understanding what the before and after is, and making sure that you have a plan B, because there’s a potential that we would have had to roll things back. So, making sure there’s a contingency plan if things aren’t going well.

Ethan:

Okay Arquay, I’ve got one last question for you, which is you have just launched this really beautiful, new redesign for Slack.com, at the end of a fairly good-sized redesign process. Do you have any advice for our listeners that you might have picked up along the way that you’d like to share with them? Let’s say somebody out there is about to start their own responsive project. What are one or two things that you think might be helpful to them?

Arquay:

I think any large-scale project like this that I’ve ever done, it’s always the things that come up at the end that you can’t anticipate. So, I would say that it’s hard to say, “Oh, you need to do a lot of pre-planning, you need to do this…” because it’s always that kind of thing that happens in the nth hour that you didn’t plan for. But I would say, though, that when you’re thinking about responsiveness in general, it’s important to think about what your goals are. Is your goal to make something that is as fast as possible? Is it to make something that is as easy to navigate as possible? Is it conversion? And so going into the project with that in mind I think helps shape the project. Because it’s easy to think, Oh, I just want to make something that works on iPads, and every device, and mobile, and all of these things. But often those goals can be very disparate. So, I think just keeping your eye on the prize and understanding what your goal is and what is most important to you and that particular project is very important.

And then I think, just in general, it’s always good advice to try to be really collaborative and make sure that all parties are involved every step of the way. In addition to this, we had talked earlier about getting stakeholder buy-in, and I think that having frequent check-ins and making sure that every person is represented and supported and feels that they can make substantive contributions to the project is very important.

It’s hard to give advice though, because it’s like are there things I’d do differently? Probably. That’s always the case with a project. But, hindsight, so.

Karen:

Well Arquay, I don’t think I’ve ever appreciated Slack more than the time that Ethan and I have spent backchanneling on it, saying how great this has been. This was a wonderful interview. Thank you so much for taking the time to come and chat with us today.

Arquay:

Thank you so very, very much for having me. It was great.

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.

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.