Episode Transcript

Ethan:

Hi, this is a responsive web design podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week we are practically vibrating with joy because we have with us in the studio Jonathan Snook from Shopify. Jonathan, how are you doing today?

Jonathan:

I’m doing well. I loved that intro, that was nice.

Ethan:

Oh, thank you, thank you. I’ve been practicing all morning. So as folks in the audience know, this is the second part of a two part series with Shopify. Last week we got a chance to speak with Monika, and today Jonathan we’re going to be speaking with you about Shopify’s admin responsive redesign, is that right?

Jonathan:

Yes, that’s correct.

Ethan:

Awesome. Well Jonathan, why don’t you introduce yourself and tell us a little bit about what you do on a daily basis.

Jonathan:

Well, my name is Jonathan Snook. I am the lead front-end developer for Shopify admin. A lot of my time is spent working with the team, growing the team, and then making a lot of architectural decisions on how we build things.

Ethan:

That sounds fantastic. I’d love to hear more of the backstory about how Shopify decided that its admin interface needed to go responsive. What were those early days like? I’m especially interested to hear if there were any concerns or difficult discussions around going responsive as a methodology.

Jonathan:

It was kind of a surprisingly organic thing. Last year the CEO basically put the call out to the entire company, recognizing that nearly half of our storefront traffic was mobile and recognizing that this was really where the industry was going. So, a lot of the front-end stuff that I’m sure Monika talked about with regards to Shopify.com, the brochure stuff, and moving a lot of that stuff responsive was really primary and up front. Whereas with admin, we recognized that there were going to be some challenges and we weren’t really sure what the best approach for that was going to be. It’s really been over the last three to six months where we did some preparatory work leading up to it and then we did a huge push and managed to get everything out. So things went surprisingly well.

We have definitely tried to not make too many assumptions on context for mobile users. People are going to be using different devices in different situations, but ultimately we want them to have as much capability on any device as possible.

Karen:

How do you see the needs of mobile users and desktop users differing? We spoke to Airbnb a few weeks back and one of the things that they said was that they started out by doing a really impressive responsive redesign of the front end, but that for them most of their admin functions were still handled on the desktop because they saw that as a more complex task. How did you think about that process?

Jonathan:

For me and for a lot of the people in the company, we have definitely tried to not make too many assumptions on context for mobile users. People are going to be using different devices in different situations, but ultimately we want them to have as much capability on any device as possible. With that mindset, we went in and said “How do we accomplish everything on a small device, a medium device, a large device?” no matter if it’s mobile—we’re not making the assumption that this person is definitely on a bus or in a different country. They could be doing anything, and our goal was to be able to give them the access to do everything.

We knew we were heading to this. We didn’t have any sort of specific timeline or budget laid out. It was just “Okay, how do we imagine this eventually becoming responsive?”

Ethan:

Armed with some of those design assumptions, how did you guys begin to scope redesigning the admin interface? How did you get your arms around where to get started?

Jonathan:

We’ve been going through a bit of a redesign process over the course of six months and during that redesign process, recognizing that we needed to go towards mobile but didn’t really have a definitive plan on how to accomplish that, which I think was probably a little strange. In listening to some of the other podcasts that you’ve done, I recognized that people had budgets and needed to really put a justification behind a lot of the decisions that they were making. At Shopify, things were definitely a lot different in that we knew we were heading to this. We didn’t have any sort of specific timeline or budget laid out. It was just “Okay, how do we imagine this eventually becoming responsive?”

As each component got designed, we really tried to think of our admin as a system of components, and so we looked at things at a per-component level and thought “How is this going to work exactly? What happens when we start taking this desktop application and decomposing it down into a small device?” I know that goes against the mobile-first thinking, but the fact was that we had an established system. We’ve had an admin since the dawn of Shopify that has always been a desktop application, and so we had to really try to figure out how we were going to take these components. Actually, doing it in this way allowed us to build out a responsive piece on a per-component level, which made things go a lot smoother.

What we tried to do within our team was actually approach just as sort of this holistic thing across the board and then provide a toolset for individual teams to adjust and manage how they were going to prioritize things.

Karen:

I’d love to follow up on that just because anytime someone mentions components, my ears sort of perk up. Can you talk about the prioritization process and how you managed that with the different components that you have? We’ve talked to other organizations, such as Fidelity and Beatport, who have talked about redesigning a responsive application and looking at analytics data to understand which of their components were used most frequently, or whether there were things that should be placed higher up in the mix because they were more popular. How did you work through the prioritization of those components?

Jonathan:

I wish I could say that we had a very methodical approach. Unfortunately, we didn’t. We have product teams around individual parts of Shopify admin, and so there’s a lot of customer outreach that they’ll do on any given part of the product. But as far as the entire system, what we tried to do within our team was actually approach just as sort of this holistic thing across the board and then provide a toolset for individual teams to adjust and manage how they were going to prioritize things. It’s maybe not the most elegant approach, there’s definitely a lot of room for improvement in being able to figure how we’re going to arrange things. But for now, we just try to keep it simple so that we could get this out the door.

What we did at Shopify is actually establish a design systems team. That team is there to look at all of Shopify admin holistically to be able to discover what those patterns are and how they should work.

Ethan:

Following up on the components thread, how has your team’s design process changed as you you’ve been doing more device-agnostic work? I know there’s been a lot of discussion, as more and more designers and organizations opt into that more components-driven view of their interfaces. It’s a big shift for a lot of people, right? I know at least for me, I still need to have that holistic view of the entire interface and then think about the individual LEGO to actually compose it. How do you guys manage that process of thinking more modularly?

Jonathan:

It’s definitely been a bit of a struggle for some of the designers on the team. I think naturally when you do have someone that is focused on a particular silo, a particular chunk, they can often let the rest of it fade away and they just do what they need to do to make their page look the way they need to, and often that goes against the component-based approach across the board. What we did at Shopify is actually establish a design systems team. That team is there to look at all of Shopify admin holistically to be able to discover what those patterns are and how they should work and then distill those into specific components, and then the front-end team builds out those components, tries to understand some of the limitations with those and evolve them in a way that we know is going to work cross-device.

One of the problems that Shopify still needs to solve internally is getting a better prototyping environment in place so that we can get to code faster, so that we can test in multiple devices faster.

Ethan:

I love that idea of a design systems team. Talking more broadly about workflow, whether it’s the design systems team or other parts of the organization, have the applications and tools that your designers use changed over time? Are you creating mockups? Are you still very prototype or PSD-focused? How are you guys circulating the design internally?

Jonathan:

Right now, a lot of the stuff is unfortunately high-fidelity mockups. Having taken that approach, it’s hard to really understand the limitations or where designs are going to break and figure out how these things should be responsive. So when a designer comes in, they’ll design for the fixed width, and then it’s “Okay, well what about responsive?” and then they design for another fixed width, which is at a smaller or larger layout, but it doesn’t really manage the in-between.

There’s often a little bit of tension between the design and implementation phase to really work out those kinks. So, that’s a process that we’re still working on improving.

One of the problems that Shopify still needs to solve internally is getting a better prototyping environment in place so that we can get to code faster, so that we can test in multiple devices faster. We have taken some steps towards that. We actually have a pattern library that we use internally so as we build out components, we can visualize those, test those responsively. We can resize and adjust and see where things break and play with those in that way.

But it’s usually, unfortunately, more of a waterfall process where the designers will go through the design process and then we go through the implementation phase, where we start to figure out where things break. There’s often a little bit of tension between the design and implementation phase to really work out those kinks. So, that’s a process that we’re still working on improving.

The concern for me was I didn’t want responsive to be this piecemeal thing where each silo within Shopify was trying to solve their problem, and so you’d have one page that was responsive and one page that wasn’t.

Karen:

Let me follow up one more time on components. You can tell that this is our pet subject for the hour today. Can you talk about how you rolled out the responsive design? I hear from some organizations that they roll it out under the surface, like individual components get rolled out responsively and they test those components. Then I hear from other organizations that they do a “big bang” rip-off-the-bandaid, kind of “Let’s just launch it all at once.” How did you guys plan that?

Jonathan:

A little from column A and a little from column B. We went in with the former approach of taking a component, testing it, and evolving component by component under the hood. We removed some of the minimum width constraints that we had in place, we could test to see how things felt and worked cross-device and cross-platform.

And then—fortunately or unfortunately—we had a specific piece of Shopify that we were launching, the new Shopify home dashboard that we were working on, and the goal was to make that responsive out of the box so that when people came to their new dashboard, that they would be excited by the fact that they could access this on any device and have it look great. The concern for me was I didn’t want responsive to be this piecemeal thing where each silo within Shopify was trying to solve their problem, and so you’d have one page that was responsive and one page that wasn’t, then moving to another page that was responsive and then moving to another page that wasn’t. I didn’t feel like that was a good user experience for our customers.

We ended up ripping off the bandaid and just really getting the troops together to go through all the issues that we were running into, addressing all of the components that we hadn’t had a chance to get to yet, and doing all the device testing that we could to ensure that we had as good of an experience as possible. It wasn’t perfect. I still see areas that I would like to tweak and adjust. But it was good enough. It was to a point where the experience for ninety percent of our store owners can log in, they can process orders, they can manage products, they can manage the core pieces of their store elegantly, and that was the key thing that we needed to accomplish.

The process we’re going through right now is trying to find “How do we approach this if we’re actually looking at mobile-first—what does that look like?”

Ethan:

Since ripping off the bandaid, have there been any elements of the design or any individual components that have been reworked since launch, either by user feedback or by you guys identifying potential problem areas? If things did get revised, what was the driver there?

Jonathan:

We’ve definitely identified areas that need improvement. Tables is by the biggest one. It’s not something that we were really sure how to handle, and so we came up with a few approaches. One was just overflow the table and people can scroll, the most important information was off to the left and the secondary information was off to the right. So at least we presented the most important stuff on the screen, but at least all the information was still available.

The second approach that we made available was content priority. So, anybody designing a particular table could say “You know what, this stuff isn’t as important. We’re just going to hide those columns on smaller screens and then people can drill down on those particular elements to get access to the data they want. But neither of these solutions were ideal. The process we’re going through right now is trying to find “How do we approach this if we’re actually looking at mobile-first—what does that look like?” and we’re now going through that design process of reevaluating what our index views should look like. Our index views are the ones that essentially are table-based, like “Here’s a list of orders, here’s a list of products. What does that list look like in a way that makes sense on mobile and desktop?” So now we have to reevaluate a number of components to figure out the best approach.

Some of the microcontent areas are things that we’ve had to adjust, where like buttons were too long because they were just too wordy. So we’ve had to bring our content strategist in to take a look at how we can approach some of the micro pieces.

Karen:

Ethan just asked if the design elements changed at all, and I’d like to ask if you reworked any of the underlying content or underlying data as part of this redesign. I think NPR mentioned that for them the responsive redesign process was also a way for them to look at the core substance of what they had and make some changes to that. I’ve talked to others that say “No, the responsive redesign is really just about making it responsive.” Did you touch any of the underlying content?

Jonathan:

We didn’t. Going back to earlier, the important thing for us was to maintain that consistency between both mobile and desktop devices because we couldn’t make any assumptions yet on what people were actually trying to accomplish. If people were trying to fulfill orders or if they’re trying to contact customers, we didn’t necessarily want to rework that.

Some of the microcontent areas are things that we’ve had to adjust, where like buttons were too long because they were just too wordy. So we’ve had to bring our content strategist in to take a look at how we can approach some of the micro pieces. But on a grander scale, we’ve really tried to keep that consistency between all devices.

One of the things about Shopify just as an organization is that it’s fairly chaotic at times in the sense that there’s a lot of ownership that’s given to individual teams to design and ship pieces.

Ethan:

How did you review the work in progress with the rest of Shopify? We’ve talked to some organizations where things are still very waterfall-focused and still very much oriented around projecting comps upon the wall. We talk to others, like Virgin America, where in the very first meeting with their stakeholders, they were actually showing a responsive prototype. How did you circulate the design at large at Shopify?

Jonathan:

With the design team and with the design systems stuff, we do regular reviews twice a week. So, that design work is presented. But that design work is unfortunately well before the prototyping stage, and so there’s not that interactivity. There’s often a lot of questions that come up on what this eventually going to be implemented like. When it came to the actual responsive implementation, there really wasn’t a whole lot of review.

One of the things about Shopify just as an organization is that it’s fairly chaotic at times in the sense that there’s a lot of ownership that’s given to individual teams to design and ship pieces. Customers let you know right away if things didn’t work out. We’ll often do piecemeal rollouts of certain pieces to verify with customers that we’ve hit the mark but when it came to the responsive piece, for us it was really still a big unknown as far as whether or not this was going to be a useful thing for our customers. We know that people are using it on mobile, they’re making due with whatever interface that they had before, so we just wanted to try to improve that experience. Time will hopefully dictate whether or not we did a great job of that.

With how quickly we want to develop and considering our chaotic organizational approach to things, it has been easier to really lock down the devices and browsers that we test in to make sure that we deliver a quality product.

Ethan:

Now Jonathan, I know you’re a progressive enhancement guy from way back and I’d be interested to hear a little bit about how Shopify thinks about this word “support” when they’re thinking about a responsive redesign. Do less capable browsers still get some basic functionality? Do they get an enhanced experience? How do you guys define support at the end-user experience and how does that affect the QA process when you’re building this prototype?

Jonathan:

Because this is an admin tool, we’ve made the decision to, in some ways, lock out a lot of devices or rather a lot of browsers—a lot of older technology. For example, we are JavaScript only, so if you don’t have JavaScript you won’t be able to use the interface. If you use anything older than IE10—so we support IE 10 and 11, the latest Chrome, the latest Firefox, the latest Safari, the latest Android, the latest iOS—in that regard, we are in a very non-typical situation to what a lot of developers are in. Even non-typical to other parts of Shopify—people that have to work on the checkout or work on the brochure don’t have that luxury like we have. I know that that means that we don’t have this progressive interface, that we could definitely go with a more traditional model, but we felt that with how quickly we want to develop and considering our chaotic organizational approach to things, it has been easier to really lock down the devices and browsers that we test in to make sure that we deliver a quality product.

Two years ago, we had gone through not only a major redesign from a design perspective but also from an architectural perspective, and had gone to a single-page app. A lot of JavaScript, a lot of CSS. It was unusable on mobile devices.

Ethan:

And I think for a relatively closed experience, that seems to make sense. The other side of that would be performance. Is that something that was a design consideration at all when you were building a responsive prototype? How it actually feels and loads on different network conditions?

Jonathan:

Performance is one of those things that we know is important, but we’ve unfortunately have had a difficult time addressing the performance piece. Two years ago, we had gone through not only a major redesign from a design perspective but also from an architectural perspective, and had gone to a single-page app. A lot of JavaScript, a lot of CSS. It was unusable on mobile devices. As a result of that, again kind of recognizing where the industry was going, we went back to a more traditional model but just layering on enough JavaScript that could manage some of the binding system and interactivity that we needed, and then since we use Rails we also use Turbolinks, which does AJAX requests for page refreshes, so it just made everything feel a lot faster, our memory usage dropped considerably. So the app is now quite usable on mobile.

We had done some preliminary audits on our code and recognized that about ten percent of our CSS, for example, was completely unused.

But when it comes to slow connections, first time experience, we know that there is still a ton of room for improvement. A lot of it is still dealing with a lot of legacy code that we have. So we need to spend a lot more time still to clean out a lot of the old code that we have. We had done some preliminary audits on our code and recognized that about ten percent of our CSS, for example, was completely unused. That’s a huge chunk that you can just drop off and minimize and improve the experience just by getting rid of that stuff. We’ve tried to look at other ways that we can drop our initial page load, but like I said, we still have a ton of work to do and unfortunately not enough people to work on it. …So hey, Shopify’s hiring!

There’s a lot of assumptions we could make about the data, but ultimately the best way to know is to talk to customers.

Karen:

How do you broadly measure the success of this redesign or the success of the admin experience overall? Are you using the exact same KPIs? Have you changed the way you measure things? Does your analytics data report mobile/tablet/desktop, even though you might not be optimizing for those form factors in the design process?

Jonathan:

We measure things across different matrices, but not necessarily overlapping. In other words, we take a look at cross-device, what usage is like, and seeing things like, for example, tablet users spend twice as much time in admin as phone users, and whether or not that is necessarily a good thing or a bad thing. There’s a lot of assumptions we could make about the data, but ultimately the best way to know is to talk to customers. So we do a lot of outreach in talking to specific customers to say “Is this a good experience for you? Are you able to solve the problems that you’re able to solve?” For us, those are the best metrics that we want to rely on.

We at Shopify believe in this approach of constantly working on improving the pieces. If we find something that isn’t working, we’re going to rework it. Sometimes we get that right, sometimes we get that wrong. If we get that wrong, then we’re going to rework that piece. We’re going to continue to talk to customers, we’re going to continue to find the best experience for them, which I think is a little bit different than other organizations, where they do a lot of testing, a lot of A/B testing, a lot of analytics to verify that something is hitting the mark. Whereas for us, a lot of the decisions we make—yeah, we still test the stuff with customers, we still want to make sure that conversions are where they need to be, but at the end of the day what we want to make sure of is that people are able to get the stuff done that they need to get done.

Instead of taking a look at everything on a page-by-page basis, we figured out how individual components should work and how those individual components should work together. That was, by far, the best way to approach this design and development process.

Ethan:

Jonathan, I have immensely enjoyed speaking with you today and I’ve learned a lot in the last half hour. Before we let you go though, I’d love to know if you happen to have any advice for any people in our audience who might be starting on a responsive redesign today. What have you learned in redesigning Shopify’s admin interface and what would you like to share with them?

Jonathan:

I definitely feel that having taken a component-based approach simplified the way we did things. Instead of taking a look at everything on a page-by-page basis, we figured out how individual components should work and how those individual components should work together. That was, by far, the best way to approach this design and development process.

But further from that, I think with the idea of trying to go desktop-first and bringing it down, you end up with a lot of non-ideal scenarios. If I had to redo it again, there’s a lot of areas that I would have liked to have approached from a mobile-first approach. Thankfully a number of designers at Shopify are doing that, that they recognize that this is now a thing.

For a long time, our team had this idea that “Yeah, one day we’ll be responsive. But we’re not now, so I don’t have to worry about it.” By getting this out so quickly, it’s now like “Oh, I actually have to think about this now,” and it’s forcing our designers to think about mobile-first and then figuring out how to scale things up, which I think is a much easier process. So I think we’re going to see some huge gains over the next months.

Karen:

Jonathan, this has been spectacular. Honestly, I love all episodes equally, but this being the most recent one, it’s also my favorite. So thank you so much for coming on the show today. I really look forward to hearing more about what you guys are up to because it sounds like this is amazing. Thank you.

Jonathan:

Well thank you for having me on the show. It’s been a pleasure.

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.