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’re really excited to speak with Monika Piotrowicz from Shopify. Monika, thanks so much for joining us.

Monika:

Thank you so much for having me.

Ethan:

Why don’t you introduce yourself and tell us a little bit about what you’ve been working on lately?

Monika:

Sure. My name is Monika and I work at Shopify, I’m a front end dev lead for our marketing and growth team. Shopify, if anyone is unfamiliar, is a commerce app that allows users to run their businesses online, in store, and on mobile. I help lead the front end dev team out of Toronto, and we’re focused on the growth and marketing branch of Shopify. So, I work really closely with the team that builds out our merchant themes, a lot of our growth initiatives, but most closely I work with the team that builds Shopify.com and some of our other sister marketing sites. About six months ago now, we actually launched a responsive redesign of Shopify.com that we’ve been working on ever since.

With the purpose of the site being to introduce users to Shopify and get people excited to sign up, we knew that to have the biggest reach, it was a no-brainer to start responsive.

Ethan:

Yeah, and it looks fantastic. How was the decision made to go responsive at Shopify? Were there any discussions or questions that came up with those first discussions with stakeholders about responsive design as a methodology?

Monika:

With the dot-com redesign specifically, parts of the design were already actually responsive. So, we had a handful of the top level pages that had some responsive behavior built in after the initial design had been launched, but when we were looking at updating the look and feel last year, it was a no-brainer that we would bake responsiveness in from the get-go. With the purpose of the site being to introduce users to Shopify and get people excited to sign up, we knew that to have the biggest reach, it was a no-brainer to start responsive and really catch up to what the standard is, or that we feel it is, for a site like Shopify.com.

I don’t think that users on different devices are going to have fundamentally different needs, requirements, or experiences.

Karen:

How does your company see the difference between a mobile user and a desktop user? Do you think they have basically the same needs? Or do you think that mobile users are this strange breed of human that need something different?

Monika:

I think that’s something that a lot of us really think about, but generally we don’t make any wide assumptions about it either. I don’t think that users on different devices are going to have fundamentally different needs, requirements, or experiences. Broadly speaking, we might think that a mobile experience might be better if it’s a little simpler and a little more linear than on a desktop. But generally what’s much more important to us is to look at pages and the specific goals any user may have on that type of page. For example, a login screen will have a different set of goals than a blog page or a feature listing page, and so what’s more valuable to us is to think about, specifically within those contexts, what a user may require rather than starting that conversation with “Is the user on a mobile or a desktop device?”

We didn’t want to start at a really granular level because you may miss some of that context of exactly what a user is trying to do.

Ethan:

As Shopify was starting to approach its responsive redesign of the dot-com site or of its themes, how did you make decisions about what to keep and what to get rid of? When you were thinking about building a responsive layout, how did you make decisions about what to prioritize on each screen?

Monika:

When we were starting down this process, we wanted to take a step back from looking at it screen-by-screen or component-by-component. We wanted to start with a good sense of who exactly our users were and what their goals would be across the site not only as they visited a part of it but as they navigated across different sections of the site and different sections of a page. So, we didn’t want to start at a really granular level because you may miss some of that context of exactly what a user is trying to do.

We didn’t necessarily approach it as “Is this content relevant to a mobile experience versus a desktop experience?” It was more “Is this piece of content relevant at all?”

Once we got a better sense, at a really high level, of what exactly our goals were and what we were trying to help our users accomplish, we started to take a look at the initial pages that we were going to be building to see what kind of content is already there and how it maps onto the goals that we had identified for our users. We really tried to simplify things a lot; we didn’t necessarily approach it as “Is this content relevant to a mobile experience versus a desktop experience?” It was more “Is this piece of content relevant at all?” If it’s going to be useful in one context, it’s likely going to be useful in another as well. So again, not taking the different devices as the main way to decide how to look at our content but rather through the goals of our user. That’s really how we tried to prioritize the content, making sure that everything on the page was actually useful and would provide value to our users.

We wanted to start with these top-level pages, get them out, and see how we could improve based on those initial assumptions and bring back those learnings to the rest of the site as we kept iterating from there.

Karen:

How did you decide how to roll this out across the entire dot-com? You mentioned earlier that some of the pieces you probably had some bits of the site that were responsive originally. Did you do this all at once? Was it a whole “big bang”? Did you roll it out in pieces? And how did you make those decisions?

Monika:

There was a bit of back and forth around that because we have a very big site, we have a lot of different pages, and we had a bit of an inconsistent experience where some of our pages, as I mentioned, were responsive and others weren’t. As we were starting down this redesign, we wanted to make sure that, first and foremost, we could get something out to our users as quickly as possible to improve on the experience that we were already providing.

With that top goal in mind, we started evaluating our pages and we picked the ones that we felt would make the greatest impact from the beginning and we started there. As we looked at these top-level pages, we identified the ones that we could create really strong patterns for. After auditing that content, we started thinking a little bit more concretely—“This is the bucket of content that we have, these are the pages that are going to have the biggest impact. Let’s start here,” so that we could make this update as quickly as possible and start making progress, iterating on this new design.

With so much of responsive design and development happening within a prototype, working in a browser directly and resizing and tweaking a lot of things as you go, that really creates a lot of opportunities to collaborate with designers and other front end developers.

The alternative could have been “Okay, we’re going to redesign everything and wait until everything is done before releasing it live,” but the challenge there is the sheer amount of updates that would need to be made, that sheer amount of different screens that would need to be designed. That would also mean we would be optimizing for a really big site without getting any feedback from our users—that’s a lot of assumptions to be making up front and would be putting all of your eggs in that one basket. We wanted to start with these top-level pages, get them out, and see how we could improve based on those initial assumptions and bring back those learnings to the rest of the site as we kept iterating from there.

Ethan:

I’d love to hear from your perspective as a front end development lead about how you collaborate with the other parts of the organization. Do you find that the way that designers and developers work together has changed as you do more multi-device work?

Monika:

The opportunity that responsive design gives us is to actually work a lot more closely with design. At Shopify, we have a dedicated design team and a dedicated front end development team, but it’s really a continuum between all of them because we have our core disciplines, which means there’s ownership over those particular areas. So, designers will own the design, front end developers will own the HTML, the CSS, and the JavaScript, but both disciplines work really closely together under a UX umbrella. With so much of responsive design and development happening within a prototype, working in a browser directly and resizing and tweaking a lot of things as you go, that really creates a lot of opportunities to collaborate with designers and other front end developers.

By having two distinct disciplines, we can focus on our areas of expertise, and that means that we can raise the bar for those disciplines, but we’re constantly communicating and collaborating with each other throughout the dev and design process because I don’t think you could really execute on a responsive site in any other way. If you move into a waterfall where teams are just passing things off to one another, then you’re making a lot of assumptions and you’re not necessarily solving the right kinds of problems. By working really closely together, we also make sure that we’re challenging those assumptions and together we’re finding the right opportunities to solve our users’ problems and to create great experiences.

There isn’t any different specific process for reviews with stakeholders. It’s all very open and we’re all used to the same toolset, which makes things really easy.

Karen:

How did this responsive project change the way that the design and development team related to the rest of the organization? For example, if you’re doing reviews with stakeholders or executives, did prototyping or other interactive frameworks change the way that those conversations happened?

Monika:

In terms of stakeholder reviews, what I think is unique to our team is our stakeholders are actually fairly comfortable working in the same types of tools that designers and developers work in. For example, in early design phases, our designers will start with a static mockup that the full team can then provide comments on, and our stakeholders will use the exact same tools as we do to provide that direct feedback. Once things start moving into prototype, the same kind of thing applies—developers will be working on this prototype and they’ll invite a designer to sit with them, and they’ll invite other senior stakeholders to sit with them as well. So, there isn’t any different specific process for reviews with stakeholders. It’s all very open and we’re all used to the same toolset, which makes things really easy because that means communication is very open and we don’t need to do anything outside of our day-to-day to get other team members and other stakeholders involved in those discussions and decisions.

It was a little bit unexpected, but the responsive redesign actually brought the front end and the designers a lot closer to our back end engineers as well.

Another interesting relationship is while design and front end development have been working really closely together in executing on this responsive redesign, it was also an opportunity for the front end developers to work very closely with our Rails engineers. We have large team of Rails developers here at Shopify, and we discovered that between the front end and back end teams, we also needed to be working closely together because we found that it was only through having really solid back end architecture that we could execute on the front end very well. By having a system that allows for the creation of really modular and extensible HTML, that allowed us to build out the responsive designs and create the really strong conventions that we needed to build, and that’s something that we needed to collaborate on really closely with our back end team to help set up that kind of architecture. It was a little bit unexpected, but the responsive redesign actually brought the front end and the designers a lot closer to our back end engineers as well.

We’ll definitely have device-specific behaviors insofar as there’s a general view of what’s mobile, what’s a tablet, and what’s a desktop experience, but those are more rough buckets rather than actual experiences built for specific devices.

Ethan:

I’d love to hear about how Shopify talks about one of my favorite words: support. How do you talk about browser support internally and has your QA process changed much since Shopify.com went live?

Monika:

Absolutely. In the broadest sense, support means it works across any screen size and any screen resolution. That’s always something that we’re going to be striving for in a responsive design. We’ll definitely have device-specific behaviors insofar as there’s a general view of what’s mobile, what’s a tablet, and what’s a desktop experience, but those are more rough buckets rather than actual experiences built for specific devices. What that means is we try and be as flexible as we can, but we still have a rough idea of what mobile versus tablet versus desktop really is.

Practically speaking, there are obviously a core set of desktop browsers that we support and that we actively test in, and we do have a mobile lab of some of the common mobile devices—and some of the maybe less common but commonly finicky mobile devices as well—that we can test on that we feel is a good representation of the overall landscape. But you can’t have every device under the sun. Between that rough group of devices and our browser testing, that’s how we try to be proactive as we can.

We really rely on the full team to help with design and functional QA. While the dev team is implementing the designs, it’s really important that the whole team has a chance to actually go through those built pages.

When it comes down to before our release, we literally have checklists just to make sure “Have we actually covered all of our bases in the following browsers?” It’s something that we do throughout development anyways, making sure that we’re testing constantly, but it’s been really helpful to just have that final check right before going live, that we’ve made sure to cover everything. The other thing that I’d say is that we really rely on the full team to help with design and functional QA. While the dev team is implementing the designs, it’s really important that the whole team has a chance to actually go through those built pages and make sure that we’ve either caught any surprising bugs or if we maybe need to change something. Things are always different when you look at them in a browser, you might find opportunities to refine and add extra polish. That tail end of QA is something that we share with the whole team because everyone wants to make sure that we’re releasing something of high quality.

There are champions within the team who really think about performance, so we’re doing a lot to try and educate the whole team.

Ethan:

Performance has obviously been entering the central part of the responsive design conversation over the last year or two and some of the most vocal people talking about the benefits of front end performance have been in the e-commerce space. How do you guys think and test for a performant front end at Shopify?

Monika:

It definitely is something that is coming more and more into the forefront, as you mentioned, particularly for e-commerce sites. There’s a lot of studies that link performance directly to conversion and e-commerce performance from a business sense, so it’s something that we are thinking about more and more, especially as more tooling becomes available and accessible to the average developer. It’s no longer something that’s really hard to get at—to get these metrics and to think of ways that you can improve. It’s something that very recently we’ve started taking a more serious look at.

Data is obviously going to provide a lot of really valuable information but it’s also admittedly very new to a lot of developers in general, so we’re also transparent. There are champions within the team who really think about performance, so we’re doing a lot to try and educate the whole team, both from a front end but also from a design perspective, to make sure that we everyone understands the implications of how something was built or how some of their design decisions will have an impact on performance.

Especially on mobile—it’s easy to think about that best case scenario where your connection is really great, but what happens if you’re not on a great connection? We want to make sure that we’re still providing a great experience for users.

So, educating the team and talking a lot about some of the tradeoffs is really important so that it doesn’t become something that we think about last minute or that we try and retrofit into the site after it’s already been launched. We’re learning and teaching a lot about it, and we’re really trying to understand the implications of how we build and design things because at the end of the day we want to make sure that we are providing a performant site and we don’t want to penalize our users for a decision that didn’t take performance into account. Especially on mobile—it’s easy to think about that best case scenario where your connection is really great, but what happens if you’re not on a great connection? We want to make sure that we’re still providing a great experience for users.

If the goal is to just build a responsive site, that can be done very easily by throwing in a couple media queries and then there you go, you’re done. But is that site actually going to be valuable to your users?

Karen:

One of the things that I personally find most valuable in talking with people like you is to hear a little bit of advice on what you learned in going through this process. Do you have any guidance that you could offer to other organizations that are themselves undertaking a responsive redesign?

Monika:

It’s important for everyone on the team, especially those who are on the production side—people that are actually going to be implementing the designs and thinking about them—it’s important for that whole team to really understand the challenges that you’re trying to solve. If the goal is to just build a responsive site, that can be done very easily by throwing in a couple media queries and then there you go, you’re done. But is that site actually going to be valuable to your users? What are your users trying to do when they visit your site? So, really setting that baseline understanding of what exactly the goals are is important.

Finally, recognizing that responsive redesigns should never really be complete. The second that you stop iterating on a design and stop working on it, stop perfecting your code and perfecting those experiences, that’s when the site is going to fail.

If the team that’s building it is multidisciplinary such as ours, where we’ve got front end developers, back end developers, designers—really understanding the needs of the disciplines and the different concerns that a discipline will have—if you’ve got a lot of different types of opinion in a room, it can be easy to stall. If you don’t understand each other’s perspectives, that can also be challenging because that’s just going to lead to conflict. The more that a team is open with the challenges that they’re facing and always keeping in mind those base goals that hopefully everyone is starting off with, that will lead to a lot less second-guessing, a lot fewer assumptions, and just better focus on those real goals that you’re trying to accomplish.

Finally, recognizing that responsive redesigns should never really be complete. The second that you stop iterating on a design and stop working on it, stop perfecting your code and perfecting those experiences, that’s when the site is going to fail because that means you’re no longer learning, questioning, or improving. It might be a little bit scary to think that you’re never going to be done, but in our eyes it’s opportunity because that means you can always be improving and building something that’s going to be better and better for your users.

Get some real devices that you can test on because it’s never fun to learn the hard way that something that you thought would work doesn’t work. That’s something that I definitely recommend as well.

Karen:

With that, I think that’s a fantastic way to end the episode. Monika, thank you so much for taking the time to talk with us today. I’ve learned a lot from listening to you and I hope everyone else has as well. Thank you.

Monika:

Thank you so much for having me!

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’re also planning to offer these workshops to the public, so please go to responsivewebdesign.com and let us know that you’re interested.

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 again to our sponsor, Campaign Monitor. Be sure to visit campaignmonitor.com and check out their email editor, Canvas. Thanks for listening, and we’ll be back next week.