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, I’m somersaulting with joy in my tiny little office because we have today Una Kravets and Zach Schnackel, who are coming to us from DigitalOcean. Una, Zach, thanks so much for joining us.

Una:

Thank you for having us.

Zach:

Thanks.

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 into DigitalOcean’s redesign, maybe the two of you could just introduce yourselves, tell us a little bit about what you do at DigitalOcean? Una, do you want to go first?

Una:

Sure. So, Zach and I are both UI engineers. We’re both remote, so I’m currently broadcasting out of Baltimore, Maryland. The day-to-day is essentially to build prototypes, make the web, in our little realm or spectrum of what that web is, a little bit faster, more accessible, and as performant as we can. So, just building out the UIs that our designers create and work with all of them to deliver those.

Zach:

My name is Zach Schnackel, I’m a software engineer or UI engineer at DigitalOcean, living in Charleston, South Carolina. I’m part of the community and creative team which supports the main website, the community platform, and any other brand initiatives that we have. I’ve been involved in the web community for about fifteen years, so probably when Geocities was at the height of its popularity. And since then I’ve been exposed to agency and product life, and I feel that DO is a unique culmination of the two of those that really speaks to my interests and helps my efforts reach an entirely new audience.

Ethan:

That’s fantastic, folks. For those who might be listening to the interview right now who don’t know what DigitalOcean is, would one of you be able to give a quick summary of what the company is and what its products are?

Una:

Basically DigitalOcean provides server space, that’s the easiest way to say it. It’s a cloud infrastructure company with a really great UI for getting your app up and running. So yeah, it’s cloud infrastructure; we provide a few different products that are coming out now. But yeah, if you need some server space, like you were kind of telling us before this podcast started that ResponsiveWebDesign.com is hosted on DigitalOcean, which is kind of exciting… I’ve personally used it for years before I started working here, so I can attest that it’s a nice, easy product for developers and DevOps people.

Ethan:

Yeah, Karen and I both love DigitalOcean, but the main reason we were excited to have you on was because of this wonderful new responsive redesign y’all just launched. So, I think we’d like to hear a little bit more about how that redesign happened and specifically why DigitalOcean decided to go responsive. What were the drivers behind the responsive redesign? And maybe more interestingly, did your stakeholders or team members have any concerns or questions about responsive design and how to actually implement it?

Zach:

When I came on in January, we certainly had a lot of upcoming things we wanted DigitalOcean to tackle, and obviously some new product offerings. When we took state of what our current website was—and certainly what our current website was was what first brought me to DigitalOcean, I was a fan of it—it was clear that, not to overshadow any of the efforts that were done in the past, but there were obviously some things that were bolted on over time. We felt that with where DigitalOcean was and where we wanted to go, this was a perfect time to reset and really make sure that we had mobile at the forefront—not just a candidate, but really a first class citizen of DigitalOcean. DigitalOcean’s always been very forthcoming in being accessible and available to anyone in the world with all of its products, and this felt like a really good point to make sure that message was spread across more of our product. So when it came to responsive design, we have some incredibly designers and illustrators, and I think that what helped this process go a little bit smoother was making sure that we, at the forefront, made sure that mobile was designed first and that we didn’t just scale down but that we scaled up for a lot of our interactions and our designs. That really helped make things move a lot faster.

Karen:

I’d be curious to hear a little bit more about that mobile-first approach. One of the things that some guests have told us is that there’s some concern around using a mobile-first approach for what is seen as enterprise software, where many users are likely to be coming in from a desktop. Can you talk about how the needs of mobile users and desktop users might have played into your rationale?

Una:

I think the idea that people aren’t going to use this product on a mobile website is sort of a problem that has two root causes. The first one is that if something is not designed well for a mobile experience, people are going to be less likely to use it on a mobile device, so that there alone decreases your mobile members when you’re looking at the data. The second is the fact that this user is a different individual, this user is someone else who’s on mobile versus who’s on desktop—it’s the same user and they’re expecting that same experience. So the idea is to definitely provide a rich experience across contexts. Right now, different screen sizes might be what mobile, what responsive is, but maybe in the future that leaves screens—what if that’s now going to be VR? What if we design responsively for various devices? What about the Apple Watch? So I think that just looking at this in terms of mobile and desktop is something that we, as a design and development community are driving away from, and that alone I think is one of the most exciting parts of responsive design in the future.

Zach:

Yeah, and just to add something to that, I think that when we ask these questions that may across all-encompassing, because I think that when it comes to browser support or screen size support, it’s always based on the use case primarily. We obviously, at DigitalOcean, have a wide product offering and lots of different people accessing our product, but we want to make sure that we’re focusing on what our company needs are, and for us we knew that mobile-first was a very important factor. I don’t know if that speaks to every single company based on how their product works or who it reaches, but it’s something that we knew fit our use case well.

Una:

The other little benefit of designing for mobile first is the content that you’re putting into your website. You ensure that the content you’re providing is relevant, and it prevents adding additional bloat to the website that might not necessarily be relevant to your product.

Ethan:

Couldn’t have said it better myself. One thing I’d like to hear a little bit more is how you folks scoped and structured this responsive redesign. Specifically since DigitalOcean does have many other product offerings, was the way you approached this redesign dramatically different than other redesign projects you’ve done in the past?

Una:

Scope is always a difficult topic to sort out. And in this project specifically, the scope was to essentially showcase all the other product offerings. In previous companies—I used to work at IBM, where, again, we redesigned a lot of the products to be responsive. That was a big change in corporate software, where it wasn’t available in that way because of, I don’t want to say old thinking, but sort of the more traditional thinking where, “Okay, here’s a desktop. People are going to use this on a desktop.” We found that to be changing. Demographics of mobile use itself are changing, so if you go in with these statistics, it’s a lot easier to make a use case for instigating that change.

I feel like that was a lot more relevant at previous employers than it is at DigitalOcean because our stakeholders, for the most part, believe in the importance of responsive design. So that was scoped in the project from the beginning, and it was just a part of building out this pattern library, which is called Float, that is responsive, that is mobile-first, that we were then able to use the components from this framework to build out the website in a really fast and efficient way.

Karen:

I have to take the opportunity to follow up on your comment about content. So, did you change the editorial direction of the site, what content you were actually creating, because the site was now responsive? And did that have an impact on how the people who published the site worked?

Zach:

I think one of the things you always have to keep in mind when you’re creating a site that’s more of a marketing piece for your company is you always want the messaging to be very concise. Certainly nobody wants to read a feature overview that’s three paragraphs long. So I think that DigitalOcean’s always strived to be clear. Not just simple in terms of its offerings, but more or less clear and defined in its message. That actually translated over very well to making sure that the type of content and the amount of content that we had for our website fit very nicely alongside the screen real estate you had. And certainly as it scaled up, it allowed us to have really striking visuals that helped tell our story even more.

Una:

Yeah, that’s a great way to put it. Just the whole idea of our core identity is simple, concise, easy to use. So, designing from a mobile-first standpoint sort of worked really well with that in mind.

Ethan:

I’d love to hear a little bit more about the design process that brought about the new responsive DigitalOcean. Specifically, you mentioned the Float pattern library that I think was a big part of it. Can you tell me a little bit about how that component library got created and what some of the goals of it were?

Zach:

When I started in January, like I mentioned, we took state of the current site and we knew that we had some bigger things coming down the pipeline. I’ve worked at companies in the past where we kind of bolted on and used frameworks like Bootstrap or Foundation or UIKit. And certainly there’s nothing wrong with using those, those are fantastic frameworks. But as I started to work more closely with the designers to figure out what our goals were for the site, it quickly became apparent that we needed something that could scale with those offerings and not slide against it.

The Float framework—I think Una actually was a big help in naming that, which I think is pretty cool—that was created, and Una and I had worked on that together since I kind of started it off, to be something that can really help grow with DigitalOcean. If you look at the source code, there’s lots of immutable classes that we can use to create these very dynamic interfaces, and what that does is it allows us to keep our style sheets small. Pretty much every aspect of the framework is written for modern browsers, but we’re using things like Polyfill.io, which is a polyfill service that allows us to backfill a lot of the functionality that certain browsers don’t have natively without us having to do any of the heavy lifting, which has been a big help for us. So, Float is something that we do have aspirations to open source, and hopefully that will be a benefit to anybody else that wants to kind of see how we do things at DO, and hopefully can be used in their projects.

Una:

Yeah, Float, just to add on to that, is very extensible. So we do have these utility classes, but on top of that we are able to extend any of our core components. So if we have a button and we want to create a new type of button, we have a hook system that allows you to add additional code on top of it. So Float right now is based on the redesign of the DigitalOcean.com website, but we recently used it in the launch of the Hacktoberfest website, which is our initiative in October to sort of get more people contributing to open source, and that’s at Hacktoberfest.DigitalOcean.com. It has a completely different look and feel. Colors are changed, a few of the components are changed, but it’s still using that same core framework, so we didn’t have to create these modules and components from scratch, we just reused what we had already implemented in the website.

Ethan:

That’s awesome, first of all. But one thing I’d like to hear a little bit more about is how designers and developers might have collaborated on the Float framework. Talking to both of you as UI engineers, I can hear a lot of the technical benefits. As you’ve adopted this more component-driven design system, do you find that less technical folks are able to contribute to the patterns as well? Tell me a little bit more about how folks are working with the new redesign.

Zach:

Well, I can say from a design perspective we worked very closely with the designers to help set up these base components and styles, and in turn what that did is as we added new pages or changed around layouts, not only were we able to reference the documentation that we’ve created for it, but designers were also able to reference that to help update Sketch files and help tweak these ideas of what we wanted to create on the website. So, it’s actually made our development and design process quite a lot simpler, but in the same breath it also helps us be more creative because we know the breadth of what Float can do, and it’s a great foundation for what we know we will continue to do.

Una:

And it seems to be sort of empowering our designers to write code because we are providing all of the documentation for these components. Recently we needed a layout done for a new initiative, and one of the designers presented a web prototype, and I was just blown away by this because it was just a few minutes of getting Float set up and then the next day there was a whole prototype there. So, that was really cool to see the designers getting more involved in the code. Like Zach said, since that initial base component design, it’s sort of been the design of the new features sort of speaking to the components that already exist and building on top of them, so that’s sort of how that feedback process loop works.

Zach:

And we’re making sure that Float is also still very flexible. So if there’s things that we didn’t get right the first time, we’re using Float as a platform to help continue it to grow and help define it. So if designers come up with a new component or maybe have a change that we want to make across the board, we’ve created Float in a way that it can expand across all of where it’s implemented and still be a solid foundation.

Karen:

I’d like to follow up on that and ask if this framework and being able to prototype more quickly made it easier for you to review work in progress with the rest of the organization. If I know anything about marketing sites, you probably have a lot of stakeholders and contributors that care a lot about what the new website is gonna be. So, how did you manage those broader reviews?

Una:

I think it definitely helped in both speed of design and prototyping because it allowed for a lot of the extraneous questions to be solved. What typeface do we use? What size? What line spacing? What is the base style of this button? All those things can be changed and edited if needed for any particular situation, but if there didn’t need to be a change, it was really easy to make those decisions, and there’s a lot of them when it comes to web design. So, it was much faster to get the prototypes up and then iterate on those, which is really important in terms of getting content out there for stakeholders to use. So I think it’s definitely improved speed of initiation of projects to completion because we have this pattern library that we can build off of.

Zach:

And I think that review and pull request just between developers became expedited in ways that I think really helped keep the project on track. Certainly when you have something to reference and you’re not recreating the wheel each time, it just creates an environment that’s very inclusive of making sure we stick to these patterns and having the support of everybody that’s been involved in that project to help you along the way.

Una:

And just quickly to add onto that: code style was a big part of it. There’s just a ton of different ways to name things and apply styles, and having something like a pattern library unifies that for both development and design—design visually, but development in terms of how we’re writing that style and that code.

Ethan:

So, the reason we reached out to the two of you was because the title of the blog entry announcing the redesign was “Faster and More Accessible: The New DigitalOcean.com.” I want to hone in on that “faster” word for a second, because, Una, I think you mentioned it in your introduction, that making things as performant as possible was really important in this redesign. Can you tell me a little bit about how you talked about page speed and performance in the context of this redesign? How did you know you were going to be successful going into this?

Una:

We really took the initial codebase and skimmed it down. We started completely over with a rebuild, which meant that a lot of the cruft from the previous iterations, things that were built on top of the website over the years, were gone. That was a huge, huge benefit. I feel like we’re very lucky to have been given that go-ahead to do that. But on top of that, we made sure to make all of our images very accessible; they’re SVG, so it’s a very small file size, we minified those. There was a lot of different things that we did, everything from the typeface that we tried to make as performant as possible, to the big GIF on the home page—that was staying, but I ended up taking that GIF into Photoshop, editing it frame by frame, removing redundant frames, making some of them longer so it was a smaller GIF, working with the dithering, things like that, which eventually decreased the size of the website by almost half. So we weren’t just sending half of what we were before, but we were making that website just load so much faster for users. That’s what I meant by it’s more performant. On top of that, the other part of the title was the accessibility aspect, and we went through and audited all of our pages through a couple of different tools to make sure that it was following current accessibility standards so that it was usable by anybody through the keyboard or with screen readers.

Karen:

I’d like to talk about how you measure the success, or the performance maybe, of the site, but more broadly. So, as you’re looking at your goals for having a marketing website and maybe tracking inbound leads or other measures that will help you know that the site is doing its job—do you look at that data across mobile and tablet and desktop? How does a responsive site fit with your analytics and metrics?

Una:

The way that we currently measured it was through this tool called WebPageTest, and there are a few different measurement tools there. But WebPageTest allows you to take initial metrics, which we did, and then we took metrics after the new site was launched. WebPageTest has a few different settings. So, you can throttle your WiFi speed—we used 3G for our measurements. There’s also different ways to measure on certain browsers and devices. So, it’s a really robust measurement tool. The example that we gave in this blog post was just 3G on Chrome, and you can also change where you’re testing from, like location-wise, so you can see how the site feels in Australia vs. I think ours was in Virginia, and then we can compare those results and get the data, statistics. I don’t know about you, but I really love seeing measurable results, so it was really exciting to get the data back and to see how much of an impact this redesign made on our existing website.

Zach:

Yeah, and in terms of performance as far as just making sure we’re meeting our initiatives as far as sign-ups and having people having an enjoyable experience on the site, we do have some very talented digital marketers that work along with us and we do use things like Google Analytics, and we have error reporting on the site to make sure that those types of things are down. And certainly we wanted to treat this redesign of the site as not an entire re-think, but something that is going to be a platform for doing much bigger things. So we knew that if we changed around too much, it would be difficult to kind of measure the success of the core pages that we have, so we kept some things a little more familiar that people may be used to on the old site, but we’re slowly making changes that we know we wanted to make, but we wanted to create them in a more stepped approach.

Ethan:

Una, Zach, this has been a fantastic chat, and I know I’ve learned a lot from the two of you. One thing I’d like to know though is if you might have any advice for any folks who might be listening to this interview or reading this interview’s transcript, what’s one or two things you learned in the context of this redesign that you’d like to share with our listeners?

Una:

I would say if you do have stakeholders that you need to convince about making something more performant or accessible, data is your friend. Take metrics before, maybe do a few iterations or explorations, and show them how much of an improvement that can make. There are so many statistics on mobile and desktop usage and how that is impacted by load time. So, I think it’s a really solid improvement to any product, is when you’re focusing on performance, and also when you’re focusing on accessibility, making sure that your product is useful by anyone, making sure that data can come across. Because people are consuming data in various different ways, and not just by looking at the text on the screen in this day and age.

Zach:

Yeah, and I would like to add that just teamwork is ever more important nowadays, especially when you’re part of a company that’s closer to 300 people now, at DigitalOcean. We certainly have a lot of people that helped us along the way here, and it was just a fantastic experience to have the confidence of those around you to help do our job. So, it’s something that I think is important and helped make this project be as successful as it has been.

Una:

That’s a great one. [laughs]

Zach:

[laughs]

Karen:

Well, I have to say I agree. Una, Zach, Ethan and I were both really excited when we saw your blog post come out and I knew that this would be a great conversation, and it certainly was. So, thank you for coming on the show today.

Una:

Thank you! It’s been so nice to chat.

Zach:

Thank you. It’s been great.

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.