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:

This week we are impossibly, nay, incredibly excited to speak with Lincoln Mongillo, who happens to be the web category manager at Starbucks. Lincoln, thanks so much for making some time for us.

Lincoln:

No. Thank you, Ethan and Karen. Thank you for having me on. I’m humbled to be invited.

Ethan:

No kidding. I first came across your work a couple of years ago at AEA Seattle and I think you guys had just launched a responsive Starbucks.com at that point. I’d love to hear a little bit more about what you’ve been up to since then and how responsive design has been used at Starbucks.

Lincoln:

Sure. Going back a little bit, I think we at Starbucks attended the AEA event in Seattle when you unveiled the responsive design talk. I think that was also the same session that we had the first content strategy discussion too. It’s highly topical that these two themes are really relevant around responsive design. A couple of years later we launched our first version of responsive web across Starbucks.com properties and since then we’ve been really focusing on improving the overall design aesthetic and making the site much more relevant for users across a wide range of devices.

Ethan:

That’s fantastic. Another really great thing is our sponsor, Campaign Monitor. I’m really glad they’re involved with the podcast because they have this new email builder they wanted us to tell you about, called Canvas. It’s based on styles, not canned templates that you have to choose from. What I like about the sound of that is that your content actually drives the design instead of the other way around. You’re not necessarily constrained into these little uncomfortable boxes to silo your information into. Now while they do have several preset pattern layouts to choose from, they also have this really well-executed drag-and-drop functionality that’s core to the tool. I’ve been a big fan of Campaign Monitor for years, they’ve been really great and generous about giving back to the community, in terms of publishing resources to make CSS-driven email much more approachable. Generally speaking, their software is built on top of a decade’s worth of tricks and hacks to make your emails just work across all the millions of email clients out there. Which is another reason I’m really excited they’re part of a Responsive Web Design Podcast.

I know for me at least, when I think of Starbucks I think about this fairly broad digital strategy that you guys have: native apps, obviously an online web presence. Can you talk a little bit, even in broad terms, about how responsive design fits into that landscape?

Lincoln:

Absolutely. I think for us, and I’m sure it’s not unique to Starbucks at all, but for Starbucks really we consider mobile to be the first customer touchpoint. We have a retail environment that customers come into all throughout the day and we need to be relevant for them as they participate in that store environment. For us that means all of our web properties need to be designed to work across as many devices as possible, again. As part of our larger digital strategy it works as an ecosystem of mobile apps, social media, in-store digital technology, and the web is the connective tissue we feel to bridge the gap between all these experiences.

The value proposition for us with responsive web design was really garnered around the notion of there being only one web.

Karen:

Can you talk a little bit about how you communicated the value of responsive design to the stakeholders and executives that needed to sign off on it?

Lincoln:

Absolutely. Basically the way that we pitched responsive design as a concept internally is after the AEA event in Seattle we did a couple of prototypes. In fact, we had a hack day that we rolled out a couple of years ago, and as part of that hack day we had a fantastic developer, a gentleman by the name of Curtis Jurgensen, who took a couple of pages on Starbucks.com and built a very quick prototype of what that might look like. What was fairly interesting at the time is that we already had a mobile-optimized web presence. We were using some adaptive technology that would take our site and reshape it to work on mobile devices. But the value proposition for us with responsive web design was really garnered around the notion of there being only one web. It had a couple of tangible benefits to that. One, we didn’t have to manage a couple sets of codebases. Two, it had some business benefit in that we weren’t creating sub-domain strategies, or anything along those lines, so it had benefits of SEO.

Following soon after that hack day presentation where we developed a fairly quick prototype, we sold that concept into senior leaders that it would be more cost-efficient for us to develop, certainly easier to test. Then finally, the broad range of devices that we could reach using a technique like this was unparalleled. It became a fairly simple concept to convince senior leadership that this was the right direction. Ever since that point all digital properties, all web properties that we’ve been embarking on have really had a focus on using responsive design as the technique, as a starting point.

We created the Starbucks style guide, which was atomic elements or content modules that we thought were perfect ways to express responsive at Starbucks. It created a common language for us to rally around as a design team and a development team.

Ethan:

That’s fantastic. Lincoln, I’d be really interested to hear, once you’ve actually got this prototype working, how did you guys begin scoping this as a real live project? When you’re thinking about responsive Starbucks.com, what do those early meetings look like?

Lincoln:

It was a lot of collaboration between our information architects, our front-end development team and as well, our design team. As part of that we created a framework first. So we created a very simple adaptive, essentially sort of like a Bootstrap-esque framework called FRWD that Curtis then put together, that allowed us to take a grid layout and adapt it to what was then an existing desktop design. From that, we were able to showcase how the desktop design would be able to flow into various different breakpoints depending on what content we felt was the most appropriate for that breakpoint. As well as part of that, we created, at the time, the Starbucks style guide, which was atomic elements or content modules that we thought were perfect ways to express responsive at Starbucks. It created a common language for us to rally around as a design team and a development team. We certainly weren’t the first company to implement a style guide by any means. For us, it really just allowed us to have lingua franca for design.

Customers really value relevant features and functionality that improve or simplify their lives. What I think our mission is moving forward as a company is to really improve all of our digital ecosystem.

Karen:

Lincoln, Starbucks makes a lot of money off of me with that “pay with your phone” thing. I love the idea that you are thinking about your customers as essentially being mobile first. Can you talk a little bit about how you set priorities for what makes sense on which platforms? For example, sometimes we talk to people who have very strong opinions about what a mobile user needs versus what a desktop user needs. There may be opinions about what’s appropriate for web versus app, for example. Can you talk about how you made those decisions?

Lincoln:

Sure, and I must admit these are questions that will plague us as the industry moves forward. It’s certainly been an interesting discussion at Starbucks. What we found is that customers really value relevant features and functionality that improve or simplify their lives. Not to be said that Starbucks doesn’t add a bunch of relevancy on the main website, but certainly the app is something that customers find useful, timely, it gets the job done. What I think our mission is moving forward as a company is to really improve all of our digital ecosystem. To make the very simple fact of coming in to Starbucks much more easy and painless. Things like paying with your mobile phone is something that we want to be able to do as broadly as possible.

As well, there’s other jobs that need to be done. You might need to check your stars in our loyalty program. You might need to be able to buy something online. All of these things are being re-thought in now this new world that we live in with these mobile devices. And now, it’s beyond even mobile devices themselves. It could be any number of things, an auto display. So for us, it’s a constant evolution of thinking through that customer journey and at each touchpoint providing them with really relevant and useful functionality.

Ethan:

Lincoln, a couple of things you said earlier kind of stuck out at me. Moving from a prototype to working closely with the IA team to kind of refine it to the wonderful Starbucks style guide, which is one of the best public examples of a style guide I think I’ve ever seen. One thing I didn’t hear come up though, was comps. Any sort of visual, in Photoshop, prototyping? Was that part of the process at all? I’m kind of curious to see if stakeholders were working from the prototype for the most part.

Lincoln:

Yeah, great question. For us, we really had an opportunity to take a current desktop design and reshape it for mobile devices using responsive design techniques. We didn’t get an opportunity, and this is probably a good thing and a bad thing, at the time, now this is several years ago, we didn’t get a chance to overhaul the design. What we did was design in the browser. We created content blocks, or content areas, that we wanted to see flow in, and used the designer’s eye to help assist the front-end development team and the information architects on making design decisions in the browser essentially. It was all based on pre-existing comps on the desktop design.

We’ve gone from a world of which we were creating Photoshop comps that were fairly complete to now moving into the browser to really see how the behavior might affect the design in the browser itself.

Ethan:

That’s very cool. Were stakeholders pretty comfortable reviewing the prototypes? How did that process work?

Lincoln:

Yeah, we take a very analog approach to reviewing work. What we’ve done is really present things either in screenshots, or more and more we’re seeing things previewed actually in device. We might actually take a mobile phone to an executive—who themselves probably read a bunch of information throughout the day on a mobile device or a tablet device—and showcase it to them there so they can see what it might look like in situ. We’ve gone from a world of which we were creating Photoshop comps that were fairly complete to now moving into the browser to really see how the behavior might affect the design in the browser itself.

We spent a lot of time working with them on things like content modeling, figuring out which content is most appropriate as it lays out on the screen.

Karen:

You mentioned that this process involved having to have your designers and your developers collaborate around how to make decisions with the existing desktop layouts and the existing desktop content. Can you talk a little bit more about how your team worked together and collaborated? For example, how did you work with the marketing people or anybody who is creating the content for the site and communicate to them how that might work in the new responsive framework?

Lincoln:

Sure. I must say that it was a highly collaborative working space. Really good for the team to sort through these design challenges. You probably aren’t surprised to find that Starbucks isn’t a very large design and development firm. We really had a small group working on this who was basically working each day to showcase the work that they were doing to date and informing stakeholders via editors, content authors, about how their content might show up in this new layout. By all means we tried to keep as much attention to content parity as possible. We really tried to not see content be removed in this, at least, first pass of responsive design.

That being said, I think moving forward as a company, what we’ve done is really started every design discussion around what’s really appropriate on the smallest screen possible. By that I mean, it might not even be a mobile phone. It could be something much smaller than that. It could be a feature phone. Using techniques like progressive enhancement, we might bring in folks from our content and editorial team to preview what that new information architecture might look like, at least in a grey-box wireframe. And then, finally, evolve that in the design phase through visual design and then finally into the browser. Showcasing how the page is rendering their content in the most fluid, flexible manner possible. We spent a lot of time working with them on things like content modeling, figuring out which content is most appropriate as it lays out on the screen.

It can’t really be understated about how much of a new world we live in nowadays when we have old designs, old desktop designs, and we’re challenged with how do we re-interpret that in mobile devices.

Karen:

We talked to a couple of people from another company that started from a very similar approach, where they took the existing desktop framework and did a responsive redesign on top of it. One of the things they said came out of that was an increasing recognition within the company when the content wasn’t working. It sort of surfaced issues with the content that people might have previously been able to ignore. Did that happen to you guys and can you talk a little bit about what you did in response?

Lincoln:

Absolutely. It can’t really be understated about how much of a new world we live in nowadays when we have old designs, old desktop designs, and we’re challenged with how do we re-interpret that in mobile devices. I think what we found is that, we’re really trying to present a lot of information when probably we needed only more snack-able bits of information. We really focused on kind of microinteractions or microcopy versus long text that might not be as relevant on a mobile device. That really informed a lot of new design direction that we’re headed on.

So I think what you see right now is a moment in time, a snapshot, of where we’re at with the web. Some of the things that we’re working on are much more forward-leaning or forward-relevant in terms of where the industry is heading and where our customers are at. I’m excited to see some of the work that we’ve had in the hopper here for a while see the light of day.

Ethan:

You mentioned new design directions popping up. Do you think that the tools and applications your designers are using has changed as you’ve been doing more responsive work?

Lincoln:

Absolutely, yeah. Tooling wise, we’ve had a quite a lot of challenges with static-based presentation tools via Photoshop—which is a great raster-based image program. We’ve been moving off toward more vector-based lab presentation tools, like Sketch, is something that we’ve been playing around with quite a bit recently. We’ve also been looking at more and more Illustrator designs and using that as a vector tool is really fantastic to solve some of the Retina, resolution-independent-based screen challenges. Finally, from a UX perspective, our information architects and UX designers have been looking at things like Edge Reflow as a tool.

We haven’t really struck gold on any of these things. It’s always been a trial-and-error scenario for all of our teams as to what tool is the right tool at the right time. At the end of the day, it’s almost always some sort of wireframing tool that allows us to quickly get concepts in front of executives, that gets the buy-in. Then moving into a visual design phase that allows us to quickly and rapidly get things presented. Then into an applicable coding environment, that really showcases what that’s all going to look like when it gets close to the metal, when it gets close to the raw HTML, CSS and JavaScript data, is the front-end presentation.

Ethan:

Nice. I’d be interested to hear, because we talked a little bit about prototyping as an actual design deliverable. Has the Forward framework changed a lot since the initial dot com release?

Lincoln:

Quite honestly, probably not all that much. We’ve probably made a couple tweaks to it just to improve some of the fluidity as we’ve manipulated our grid. Beyond that, it was a very simple tool that allowed us to create base grids and nested grids. As a layout tool, it was at the time really unparalleled, at least for us. There wasn’t really anything that we found out there in the industry that we could easily plug-and-play. We had to create something from scratch. The team has really rallied around that. From ongoing page design or iterations, it’s been fairly flexible for us to make minor modifications to it, but the guts of what was originally created is still largely applicable today.

When you’ve got a minimum screen width, you’re really forced to make tough decisions. That alone was one of the secret weapons that allowed us to get buy-in across the organization about what’s really important.

Karen:

You mentioned something earlier that I’m always interested in, which is executive buy-in. As you were presenting—whether it was comps or prototype—how did you get your stakeholders to understand the ways that responsive is different? Was there any issues, for example, with them wanting their “thing” in a particular place, or being worried about the fold, or typical questions that might come up when they’re reviewing desktop comps?

Lincoln:

Yeah, it’s been a big challenge within the industry to make that shift, that mental shift that all people must go through when casting a light on new design techniques such as responsive design. I think what we’ve seen with executives is that they were hungry for change. The leadership that we’ve had in the digital space has been very accepting of pushing the envelope forward on mobile, particularly, and see techniques like responsive web design not only dominate the landscape within the industry, but also create a seismic shift in how designers are thinking of the web. And so the buy-in process here was more showcasing how things might lay out to get alignment and agreement on what that might do to the current website.

This could be Starbucks.com or any of the websites that we operate. Essentially, it allowed us to think of what was really important and relevant on mobile devices first. And then even push the envelope in some cases and really think about content first, or offline first, as a starting point. And then building the discussion up from that point allowed us to really get buy-in across senior leaders about what we’re trying to do. It could be communicating a message as a top priority. It could be performing a task, such as reloading a card. Those are the things that really allowed us to have a solid foundation to build arguments based off of, when you’ve got limited screen real estate. It makes decision-making skills much more rigorous versus a desktop design, which is a lot more open to interpretation. When you’ve got a minimum screen width, you’re really forced to make tough decisions. That alone was one of the secret weapons that allowed us to get buy-in across the organization about what’s really important.

It cannot be understated, it’s been probably one of the biggest challenges that we’ve had to overcome as an organization around testing.

Ethan:

That is fantastic, Lincoln. You’ve said a couple of things that I’ve been biting my tongue, wanting to ask about devices. How has testing been incorporated into the design process?

Lincoln:

This has been one of the biggest challenges for us is, back in the day, front-end developers would get a comp, they’d mock it up in HTML, CSS and JavaScript and hand it over to QA and QA would maybe perform a battery of tests on a small subset of browsers. Now it’s become exponential in terms of the device proliferation. Because of that, the QA department has really had to ramp up their toolsets and also testing procedures to ensure that they’ve blanketed, or at least tested, the entire codebase across all these different devices.

What we’ve done is come to an agreement about device browser capabilities and created a grade sheet for each device and each browser within the device, because some devices have different browsers and different capabilities. Using that technique, we’ve been able to have some tooling at our disposal that allows us to test those in automated fashions. Also, we’ve got a growing device lab here of A and B and C graded devices that our testing team and even development team can really push the envelope and see what the effect of these design changes are and functionality changes are to these devices. But, Ethan, it cannot be understated, it’s been probably one of the biggest challenges that we’ve had to overcome as an organization around testing.

We try to be inclusive in as much as possible to ensure that any customer on any device has a really appropriate experience, i.e., it should look good, it should be on brand, it should be functional, they should be able to achieve whatever they’re trying to achieve.

Ethan:

Sure, would you say, you mentioned lower-end devices earlier, has that been redefining the way you think about support in general as a concept?

Lincoln:

Yes and no, I suppose. We try to be inclusive in as much as possible to ensure that any customer on any device has a really appropriate experience, i.e., it should look good, it should be on brand, it should be functional, they should be able to achieve whatever they’re trying to achieve. I think what we’ve seen is that in some instances, there’s browser capabilities that are really hampering that experience. We’ve had to make decisions as an organization about what we support.

Support really means, how much time we spend on testing or developing to ensure that that feature is fully functional. Or QA. We do try to support a wide range of devices that are out there. And do full passes on those. Because of that, it really has challenged us in terms of redefining support in that we can’t cover everything. We do have to make statements about where we’re, as a team not going to go in to, in terms of spending our time and energy.

We put a lot of time and energy in things like video, early on, and what we found is that on a mobile device, it doesn’t get as much traction as we thought it would, at least for us. We’ve had to really rethink our content strategy around what’s appropriate for users.

Karen:

Can you talk a little bit about what type of usability testing you did? And, perhaps how that insight from watching users fed back in to the design process?

Lincoln:

Sure. There’s nothing more valuable to anybody that works in digital than usability and really understanding how customers are using your products. For us, what our usability tests showed us is certainly what was working. We were able to find that they were able to do things that we thought were going to be a little bit more difficult, like navigate. We found issues that were clear no-brainers, but we missed it. We had to own up to it and customers thought it was weird that it worked a certain way or laid out a certain way. One of the classic examples that I can think of is that we have a typical two-column layout with a right hand column and there’s important things that we found in the right hand column that weren’t laying out correctly. We had to make some adjustments to that. And users, usability showed us that. We’ve had to make modifications on the fly to that.

As well, things like content that we thought was really important on mobile devices aren’t really as relevant. We put a lot of time and energy in things like video, early on, this is three, four, five years ago now, maybe three years ago now, and what we found is that on a mobile device, it doesn’t get as much traction as we thought it would, at least for us. We’ve had to really rethink our content strategy around what’s appropriate for users.

If there’s three things that every project has at Starbucks at its core, it’s performance, security, and accessibility.

Ethan:

Lincoln, I’d be curious to know, is performance a concept that comes up in discussions at all? Is that a focus for Starbucks at all?

Lincoln:

Oh, everyday, yeah. In fact, if there’s three things that every project has at Starbucks at its core, it’s: performance is a key priority for us, security, of course is another one, and accessibility. Particularly on performance, I think our team has really been challenged with coming up with front-end development and even back-end, server-side improvements to our code base that allows it to be a little bit more optimal. What we’ve done is created a benchmark profile for us to see how we’re performing. Granted, our site is probably not the most screaming fast on earth, but we do test against page speed and wise load to see what our scores are and try to make benchmark improvements to that based on projects that we have in the pipeline. As well, our front end development team is always constantly putting things in the product backlog of things that they know that we want to do to make the site overall more performant for our end user.

Are they bouncing? Are they completing a task? Are they abandoning at a certain point? We pay close attention to all of that data to inform design decisions as we move forward.

Karen:

Lincoln, can you talk a little about how you measure the effectiveness of your responsive designs, or of the web strategy? How do you know if this is working?

Lincoln:

Sure, so for that what we really do is focus on clear goals and objectives. Each page that we have should be designed with a particular purpose in mind. From that we develop a series of KPIs. Those KPIs might be something as nebulous as an impression or gleaning of information. Or it could be something as hard-hitting as an ability to reload your card. Those are more conversion-focused experiences. Then as well, we focus on flow and ease of use as a primary goal for the customer. Things like abandonment rate or as part of usability studies we might ask, “how easy is this to use?”

A lot of that is tracked in one of our analytic platforms. We take a look now at some of the analytics capabilities that are out there and we’re able to see how customer’s journey is affected when they’re on a mobile device. Are they bouncing? Are they completing a task? Are they abandoning at a certain point? We pay close attention to all of that data to inform design decisions as we move forward. It’s been an evolutionary process for us, it’s one in which we keep a constant eye on.

It’s something that we look at holistically, as to how digital is effecting that entire customer journey. In many ways, they should be complementary in many organizations and certainly that’s what we’re striving for here.

Karen:

I’ve talked to some companies, especially those that, like Starbucks, have a wide ecosystem of different devices and platforms and touchpoints that they want to attract customers on. Some of those companies have told me that there’s sort of an internal competition between web and app. One of the metrics that they have in place is how many people download the app and too many people using the web is seen as preventing them from getting more app downloads. Is that an issue for you internally, web versus app? Do you measure them separately?

Lincoln:

Currently they’re really apples and oranges when we consider what we’re doing with each of these particular digital products. I think that there’s a natural healthy competition, I’m sure, in all organizations around this. But right now, they’re serving a couple of different purposes. One’s more for discovery and performing a task, that’s largely what the web is about. The app is a very focused experience. It’s really about that in-store experience and the things that a customer has to do in that store to feel like they’re being successful. It could be paying with your mobile phone to speed up the line, or seeing the star earned from a product that you purchased using your phone as part of our loyalty program. In our minds it’s really not the same experiences that we’re after.

Because of that, there’s not a lot of competition in that space. But it’s something that we look at holistically, as to how digital is effecting that entire customer journey. We might have a customer come on to our website and register a card and then only after that, after several times of using the card, download the mobile app. In many ways, they should be complementary in many organizations and certainly that’s what we’re striving for here.

Ethan:

Lincoln, we have been looking forward to chatting with you for weeks. Thank you so much for taking the time to hang out with us and talk about responsive design, it’s been great.

Lincoln:

Thank you, Ethan and Karen. I couldn’t be more excited to chat with you guys. I’m certainly big fans of you guys’s work. You should know that I’m always interested to hear about everything that you guys are thinking about. So please keep up the great work yourself.

Karen:

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

Ethan:

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.

Karen:

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.

Ethan:

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.