Episode Transcript
- Karen:
-
Hi, this is a responsive web design podcast where we interview the people who make responsive designs happen. I’m your host Karen McGrane.
- Ethan:
-
And I’m your other host Ethan Marcotte.
- Karen:
-
And this week we’re delighted to have Livia Labate as our guest on the show. Hi Liv.
- Livia:
-
Hi, thanks for having me.
- Karen:
-
We’re really happy to have you here.
- Ethan:
-
Before we dive in and start talking about what you’ve been doing at Marriott, I think we should take a minute to mention our sponsor Campaign Monitor, who is fantastic. If you guys need an email newsletter you should definitely check them out.
- Karen:
-
They have this awesome new email builder that they call Canvas.
- Ethan:
-
Canvas, you say?
- Karen:
-
Yeah! And I think it’s really cool. What it does is it gives you—near and dear to my heart—rather than forcing people into using particular templates they give you a library of styles that you can use can apply to your content.
- Ethan:
-
A library of styles. A pattern library of styles, if you will. That sounds pretty fantastic. I have friends who rave about how easy it is to use the wizard, this drag and drop functionality I’ve been hearing about. I’ve always respected Campaign Monitor because they’ve always published these great resources about delivering and designing email newsletters. So I’m really excited to check out Canvas.
- Karen:
-
So, it would be great if you could start off just by introducing yourself, what your role at Marriott is. And, tell us a little bit about the responsive design you have going on.
- Livia:
-
Great! I am senior director of experience design with Marriott Digital Group. Marriott International, as you probably know, is an international hotel company. We have 4,000 hotels worldwide. And, as you might expect, we have a pretty vast digital footprint. So, responsive web design has been on our minds a lot over the past year. And I have initiated and have been leading our responsive program which is seeking to make our web experiences responsive.
This working group said: you know what, if we really want to move forward and start working a different way, we need to do a set of things. It’s not just about writing code differently. We need to educate the organization about these different new practices.
- Karen:
-
Say a little bit more about that. I think I’m really interested in hearing how did you convince people that Marriott needed to go responsive? How did you get support for that from your stakeholders and executives?
- Livia:
-
It was really a combination of different factors. It wasn’t really one particular driver. There were a few of us that were discussing the downsides of having a forked experience for users. We have a “mobile-optimized” site and our “full site” is what we call it. There are some challenges with that including the burden of maintaining these separate experiences. We were also looking at our metrics and seeing a very impressive growth in our smartphone and tablet traffic. And, there were questions at the time and so—this was about a year and a half ago—there were some questions also about our ability as an organization to adopt more modern practices, such as HTML5 capabilities or CSS3 capabilities. We put together a little work group to demonstrate the prototypes, what could be done. The reason that we weren’t doing certain things was not because we couldn’t do it. It was just because we weren’t. All of these things were happening around the same time and as we were demonstrating these little prototypes, this working group said: you know what, if we really want to move forward and start working a different way, we need to do a set of things. It’s not just about writing code differently. We need to educate the organization about these different new practices including responsive web design. We need to have a different work environment that’s more conducive to collaboration. This became a little brainstorm and we made some recommendations about things that we needed to do as an organization. One of the recommendations was: we really should consider making our web experience responsive. So, it started that way and then we presented that to a number of different people and eventually had articulated the business case for it coming from how our traffic was growing, the cost of maintenance, and things like that, and there was enormous potential there. So it was very well received. There were obviously a lot of questions because the whole concept of responsive was very new. So there was a lot of explaining what that meant but eventually the business case was strong enough that people said “yeah, let’s make this happen.”
What we did was we created a distributed model. We created this responsive program and we had a team that was steering and facilitating it. But, it was really on the product teams, they already had responsibility over parts of our site, to take it on and make them responsible for responsive. I’ll say that was probably the harder way to do it. It took the road less traveled.
- Ethan:
-
So Livia, you got the green light for this first big responsive project. How did you start to get your arms around it, how did you scope it out?
- Livia:
-
We realized early on that we have many different paths that we could take and making a decision about how to do it was really something we didn’t take lightly right away. We said okay, we could, for example, redesign the entire site and just take the whole thing, but we have a pretty broad web experience. It’s vast. We have multiple sites, any language. We also have this mobile site that has different features than the main site. Redesigning was a massive undertaking that we felt would actually derail us from the objective of just making it responsive. We shied away from that at first, no redesign. But then we also looked about how do we even organize ourselves to take this on? We said we can have one team that’s the responsive team and this team just goes on and makes the site responsive. Then we thought, okay we’re going to be done and the organization would have learned nothing from this exercise. Because we have so many people today that are contributing to these sites, how are we going to get to a place where they feel equipped to do that? That was actually part of the original recommendations that we made was: how do we make this organization more empowered to make these changes and adopt better practices. That drove our approach. What we did was we created a distributed model. We created this responsive program and we had a team that was steering and facilitating it. But, it was really on the product teams, they already had responsibility over parts of our site, to take it on and make them responsible for responsive. I’ll say that was probably the harder way to do it. It took the road less traveled. Coming out of this process now, we definitely see an organization that has embraced the process and embraced the approach and really now understands what it means. And it becomes just the way we do work. It really allowed us to bring on the transformation at a level that we were hoping for. Rather than just, at the end of the day, getting a responsive site. It’s much more than just the site itself.
- Karen:
-
One of the things that I often hear people talk about is the difference between what they think a mobile user wants and needs versus a desktop user. And, I think in many industries, my point of view is that there isn’t much difference. But one of the industries where there really does tend to be different needs for mobile and desktop is the travel industry. Can you talk about how people within Marriott think about the difference between a mobile user and a desktop user? And, how that intersects with your responsive design strategy or your app strategy or any other touch points that you might offer.
It is important to assume that most activities are universal. And there may be specific needs within that are potentially device-specific. But if we satisfy the main things across the board then we can do a better job at the specifics. By having the web experience unified through a responsive approach, we cover most of the base scenarios. So that we can now really enrich the specific situations.
- Livia:
-
Sure, that’s a really fantastic question because it’s the question we have to re-address every time we have a conversation. Because, I think in a summary way, it is important to assume that most activities are universal. And there may be specific needs within that are potentially device-specific. But getting the organization to embrace the idea that, if we satisfy the main things across the board then we can do a better job at the specifics. Since our intention as a digital group is to support the guest throughout their travel experience, from the moment that they’re booking all the way through post-stay, there are many situations that are different depending on where you’re interacting with us. Like I said, our digital ecosystem is pretty vast. And since we’re supporting it across this whole journey, users are going to interact with our website, they’re going to interact with our mobile app, they’re also going to interact with in-hotel kiosks, in-room experiences, et cetera, et cetera. So, yes, there are differences because they’re interacting at different moments with different device combinations. But, at the end of the day, if we don’t allow some level of continuity across the strings, and we don’t connect all these things together, it falls apart. It feels like it’s a broken-down experience and has been created and designed by different people. By having the web experience unified through a responsive approach, we cover most of the base scenarios. So that we can now really enrich the specific situations. So, we know, for example, last minute bookings, you’re much more likely to do that from your phone because you just got stuck in some airport and you just need to find a room for the night. You’re very likely to do that from your phone. But the engine that allows you to do the booking is going to be the same whether you’re doing that or you’re planning your vacation three months from now. That’s what I mean about creating that foundation, it just needs to exist across the board. Then you can start enhancing specific things. So potentially, the homepage of your smallest viewport on your site could offer certain things that are more about… okay last minute bookings, here, do that. Prioritizing content I think maybe is the era in which we can enhance the specifics of certain kinds of users for certain moments in their experience. But to me, the responsive approach created a baseline that created a new infrastructure and allows us to now do a better job at the specifics.
- Ethan:
-
Well that’s fantastic, Livia. One follow up question from that is, you mentioned prioritization. When you’re designing a new screen or thinking about a new flow, how do you make those decisions about what to prioritize?
- Livia:
-
I think I would give a different answer if I was starting something fresh versus how we approached our responsive program. Let me talk a little bit about that.
- Ethan:
-
Okay.
- Livia:
-
Like I said, we chose not to redesign so we weren’t able to say “okay let’s do a mobile-first approach, et cetera, et cetera.” We wanted to bring all those sentiments but our approach was we have the site that is a locked-width grid, and we’re going to start that as our starting point, and we’re just going to make it work for users across any device to the smallest breakpoint that we find useful. So it was really a content re-flow exercise starting from our current state.
- Ethan:
-
Sure, sort of a responsive retrofit.
- Livia:
-
Exactly. And that made sense for us because we had too much to cover and also, like I said, the organization wasn’t well-versed yet in how to do these things, so that was a helpful way to go about it. So what that meant was people were working with already established layout and design, and we offered tools. So at the same time we were doing this program I had introduced a set of new standards through a design system, so people were adopting a more cohesive design system throughout our products. So that helped them make some decisions about how to lay things out differently, but the exercise was really a content-focus exercise.
Let’s just say we have this page that we’re just going to make work in smaller sizes. Is the content relevant? And is this in an order that makes sense? Do we need to make any adjustments to make that work at smaller sizes? So some teams found that they needed to do very little. And it was really just re-flowing, making sure things were fluid, that the media was flexible. And other teams found that, “oh, you know what? We actually have content problems that are going to get in our way, let’s address those.” So there were some exercises depending on the teams in cleaning up content or eliminating content or converging content. But that wasn’t our starting assumption, because we really just wanted to just focus on making it responsive. And I’m speaking to that issue, it would be interesting to mention also that because we took this approach of not a centralized team doing this, but really facilitating and helping each team do this, each team took a slightly different approach. So some teams prototyped everything, other teams had a lot of comps because they weren’t that comfortable with the level of prototyping other teams were, so it wasn’t sort of a universal approach across the board. But I’d say primarily, rationalizing that content was the first step, however people chose to do it.
- Ethan:
-
That’s fantastic. I guess one of things I’m really curious about is that steering committee interacting with many of the product management teams. How do you… If team A discovers that the need to extend the design system or revise it, how do you communicate that change across all the different product teams?
- Livia:
-
So we identified things that are foundational to this program and then the tracks of work for each team. So the things that were foundational were things that we identified early on that we said “you know what, everyone is going to have to deal with it.” Responsive images. Don’t just let each team figure this out on its own because it’s so messy. How can we help them get to a better place? So we did training with every team with about, okay, here’s the situation with responsive images today. There’s thirty ways to do it, let’s make a decision as a team about how we want to do it now and let’s all do it like this so that when it changes in the future, and we know it will, we can all adopt that broadly. So we did try to identify things that were shared that could benefit from the centralized team to take on and then provide that as a service to the others versus things that were specific to a product and those teams could take those things on. So we did training but also we brought external experts in certain areas to help us with these things. Anything that would help any of the teams figure out what they need to do.
- Karen:
-
Can you talk a little bit more about the content process, the content re-flowing, and how well did that work starting with your existing desktop content? In what situations did you come to the conclusion that you might need to adapt the content, change the content even though you were really just trying to do a retrofit?
On the flip side, the responsive program was also a fantastic excuse to fix stuff. That was actually one of the greatest benefits of it.
- Livia:
-
I think one thing that’s important to think about it is when we’re taking this responsive intention of making our site responsive, that’s not the only thing we’re doing, right? As a company we’re doing like a hundred other things at the same time. And that’s important because while we were doing this and we’re talking about rationalizing the content, we’re also saying “hey you know, we’re also considering enhancements to our CMS, or even considering a different CMS altogether.” And all these conversations sort of start overlapping each other. So we knew we wanted to clean up some of the content as we made decisions about priority. But we weren’t significantly going to make changes to our CMS and how we were serving content and how the content was structured. So we had to make some decisions about how far will we go with certain things in the interest of making it responsive. So there were some situations in which it was just—we had some paragraphs that were just too wordy and the content was not doing its job, it could be more concise, and that would not only make it easier to make it responsive but it would actually be better for the user. But at that time we could not change that content because it was content, it was structured content coming from a different source, that it was a CMS challenge they were having, so we had to defer that. So does it work responsively? Yes. Is it great? No. But it was a worthwhile tradeoff because now when we’re talking about enhancements to our CMS and changes to our content and re-evaluating our content modeling, now’s the time to have those conversations. And it was very hard at the time to say which ones are the things that are really important for right now and the things we can defer to later, because we have other efforts that are going to help with that. I think what helped us make that happen was I guess trust in the organization that these other things were going to get solved, but also not skimping on things. Really it was getting in the way of making the site responsive, let’s address that.
Standards and a design system, these were things that we needed historically. But how can you make a business case to unify your visual identity? That’s incredibly hard, especially as you’re stacked against those hundred other initiatives. But doing that in the interest of making it easier to code and making it easier to freshen up our front-end as we make it responsive, those are very much more meaningful cases to make.
So it was sort of, depending on the situation, we decide those things but it was good to be able to identify the need for other efforts to happen in concert but not as a dependency of the responsive program. And I know that sounds a little fuzzy, but on the flip side, the responsive program was also a fantastic excuse to fix stuff. That was actually one of the greatest benefits of it. I mentioned a little bit: standards and a design system, these were things that we needed historically. But how can you make a business case to unify your visual identity? That’s incredibly hard, especially as you’re stacked against those hundred other initiatives. But doing that in the interest of making it easier to code and making it easier to freshen up our front-end as we make it responsive, those are very much more meaningful cases to make in that context. So things like that were absolutely possible in the context of making the site responsive. So it was a tradeoff between things that we are going to let go so that we can make it happen but also things that we’re going to just squeeze in because this is a good time to do it. Does that make sense?
- Karen:
-
Great explanation. Can you tell me a little bit more about what, what have you learned from this responsive redesign process that would inform future changes you might make to your CMS? Or maybe another way to ask that is, what advice might you have for people who might be going through something similar and are trying to make decisions about what they do with the responsive design and what they have to change in their CMS later?
- Livia:
-
Do not migrate to a different CMS while you’re doing it. That would be my first thing. We made that decision and I’m so glad that we did that because now that we’re starting to talk about evolving our content, we realize just how complex that is to understand and to decide what to do. And that would have gotten in our way of making the site responsive. But the process of having to consider the content priority at a page level was already helpful in saying, you know what, maybe there’s a content quality problem on this page but then there may be also content display opportunity or we could do this better and more efficiently. Or performance would be better if it was served in a different way, and things like that. So there are some things that just emerge as part of the conversation that became requirements for the conversations that are happening now about our CMS and content modeling. For example, in our existing CMS, the content type definitions or the structure that says this is how the content is structured, and the UI for that particular structure are together, they’re coupled. That’s how the CMS is put together and that’s what made sense when we did that many many years ago. Today, because we might reuse that content differently, we’re not just publishing on the web, we may be publishing elsewhere. We may have different UI showing the same thing. That coupling really gets in our way. So through the process of making the site responsive, we realized just how limiting that was. So now that we’re talking about new needs for CMS, we’re saying it absolutely must be de-coupled. I can give you more examples like that, but that’s a really significant one. That’s absolutely a lesson from having gone through this responsive exercise, that’s really going to help move things forward in a different way from a CMS standpoint.
- Ethan:
-
Livia, I’d love to hear a little bit about the design process that you and some of the other product teams adopted when you were doing this big responsive redesign. Has this changed over the course of this project?
Make sure you start by prioritizing your content, and then start working on making the layout work for that content priority, and then address all the technical challenges that you’re going to find out. That’s pretty much the level of prescriptive process that we provided as a program.
- Livia:
-
Yeah. And it was intentional, right? We said we really wanted to help the organization adopt more modern practices. But we did not want to be prescriptive. So there was definitely a lot of requests from different parts of the organization saying “hey, can you guys lay out the process by which change should make things responsive?” And I explicitly refused to do that. I said “I don’t know better, no one knows better.” This was a year and a half ago, everyone was trying to figure this out. But even apart from that, different teams are dealing with different problems, different stakeholders, different situations. They each have to find what’s the best approach to take on their particular challenges. So what I offered was overall guidance on: make sure you start by prioritizing your content, and then start working on making the layout work for that content priority, and then address all the technical challenges that you’re going to find out. That’s pretty much the level of prescriptive process that we provided as a program.
But then the specific teams took very different approaches in how to do it. So for example, some teams were super in love with the concept of mobile first. So they just looked at the current site, they did their content modeling exercise, and they basically started laying things down mobile first. And through comps, right? So interesting combination there. Other teams started actually prototyping but started prototyping at the largest breakpoint, and then started breaking down to the smaller sizes. So that level of difference there as people are working through making the page layouts work, and identifying how to use the media queries, and how to bring photography in a way that made sense, those are very specific choices by each of these teams, and every team came back with, “oh, here’s what we learned through this process,” which was very enriching for the whole organization. And because there were so many teams working in parallel, and some starting later than others, they were able to benefit from some of the lessons. So we had a few sessions where teams that were further along said, “hey, this is how we’ve done it so far, this is what’s worked, and this is what has been painful and we don’t recommend.” So teams were able to adjust as they could.
I run a team called Standards and Practices, and that team offers a lot of starting points for people to just get work done. So one thing that we did, for example, is we created a PSD file that had the smallest breakpoint, a middle breakpoint, and the largest breakpoint that we had all agreed to use. And that allowed just any teams that were creating comps, they could just start with that, so just get them going faster. So we created a few artifacts like that, or just some base code that people could start prototyping with that would help get them going, but we weren’t very strict about how they should do it. And I think people felt that was painful because they had to figure out a lot of things. But after some time, I started getting a lot of feedback that people were really excited by the opportunity to figure it out, because they felt like they were learning faster because they had to figure it out themselves. So that was an interesting piece of feedback that I got over time. They also really appreciated having a central team to go to for questions. And it’s not because we had all the answers, but because we committed to figuring out with them if they came for help, we would sit down with them and help figure it out. So we had design clinics, critique sessions, some assisting with prototyping and things like that. So we really tried to satisfy the need as it emerged rather than being prescriptive about it, and it worked really well. We had such a variety of individuals and skillsets that we really tried to respond to whatever was the need at the time. And I’d say, from my point of view, it has been a successful process.
- Ethan:
-
Livia, that’s fantastic. I’d be interested to hear, I really like how you’re designing a culture for these different teams to interact with and share lessons learned. Over time, have you noticed any interesting trends emerge? Are more teams adopting prototypes, for example, earlier in the design process? Or any other sort of workflow things that have gotten adopted on a significant scale.
- Livia:
-
Mh-hm, I think the organization has shed some bad habits. So internally, it used to be an internal services group and it was run almost like an agency, and this was many, many years ago, but there are some legacy practices. So for example, printing screens to show people. I would look at these printed screens and I’m like “what is this? We work in the digital space.” And so things like that have almost disappeared—which is amazing because when I started, every single meeting that I went to there was stuff printed on the table. So now everyone is bringing their computer or has stuff on the display and just really embracing the medium. And I think that is the larger benefit here. So that’s one thing. The second thing is the prototype thing. Interestingly at the same time this was happening I was also looking at our prototyping practices. When I started there, there was a mandate to use a particular tool that had been introduced many years prior to my arrival. The team was so unhappy with this prototyping tool—it was like a super overkill tool—that was not what they needed. The tool did not really support media queries so I said “great excuse, let’s stop using this tool.” And so what I tell the team is, I’m not going to say “use this other tool,” but let’s take this year and figure out what’s your preferred prototype approach. So among the team who had more familiarity and experience in prototyping HTML, other people used tools like Axure, et cetera. Other folks love their sketching and paper prototyping, so we have the whole spectrum. So over the past year different folks have experimented with different things and really found a different, new level of comfort.
The prototype has so much power across the organization, especially outside of the people who have the technical knowledge. So not the people who are doing all this work but the people who are tangential business partners, like customer care, et cetera. Those guys are not in the day-to-day of making this stuff but seeing the prototype and actually understanding right away how the user is going to interact with something has been incredibly powerful.
So I think after a year we’re now getting to a place where we’re seeing some patterns. But we definitely have two camps, the people who are comfortable writing HTML and CSS, and the people who are not. And I feel like that’s where we’re going to work on next because it becomes a haves and have-nots, because if you know how to do it you get so much further faster now that we have all the building blocks in place, now that people can prototype responsively with the things that we created. And the folks that don’t have it are kind of lagging behind or are dependent on the folks who have. That’s definitely a pattern I’ve seen emerge, so next we’re going to work on how to do we address that? Is it training? Is everyone going to embrace writing code as a method to a prototype, or can we move forward with multiple approaches? So that’s a conversation that is happening now. I have definitely seen a decrease in use of comps in PSD. I think it’s used at certain points in a project to illustrate the overall look and feel and how things are going to come together, but I am seeing a lot more decisions about visual design, for example, happening through the prototype. Not that the visual designers themselves are necessarily going directly to the prototype and changing things—some of them are, as the minority—but the conversation about and the discussion about, let’s try this out and see how it works, has definitely migrated towards using the prototype as a focal point.
Similarly, another pattern is, the prototype has so much power across the organization, especially outside of the people who have the technical knowledge. So not the people who are doing all this work but the people who are tangential business partners, like customer care, et cetera. Those guys are not in the day-to-day of making this stuff but seeing the prototype and actually understanding right away how the user is going to interact with something has been incredibly powerful. I’ve been really amazed at how people have responded to prototypes. Because we have taken this approach of multiple teams doing different things, we did a crazy hack that ended up being fantastic. We did a call for prototypes, so every team sent out what they had, so some people had HTML prototypes, some people had some comps and we stitched it together, kind of a Frankenstein prototype, and that became the illustration of what things are going to look like once we’re done. It’s been incredibly powerful; we’ve been taking it to our leadership team, to the continents, we have people worldwide who really need to understand how things are going to change. We said, this is for illustration purposes but it’s kind of wonky and not everything works exactly as it’s going to be, but it gives you a really good sense of how users are going to flow throughout the whole experience. It doesn’t actually feel like there are several, several teams touching all of that, because it allowed sort of a unified way to demonstrate that. So I think from a process standpoint, I would never have said we’re going to intentionally put all of these prototypes together because that’s a lot of effort. But because we did, I think we’re better for it. And, we did it knowing that it would have a very short life. The moment of launch, that prototype was no longer necessary because then you have the live site doing that job. But, interestingly, we’re launching tomorrow, so, this is very timely. Today’s basically the last day of that prototype. Because right now, if anyone has any questions about how the users do X, Y or Z, they look at that prototype. It’s immensely powerful and people can look at it anytime. They don’t need me or another expert in the program or in responsive to explain how things are going to work. They can just look at it, play with it, and they’ll understand.
- Karen:
-
Kind of following up on that, how did the stakeholder review and feedback process change? I would imagine that going from an organization that was responding to printed documents and going to something where people are reviewing prototypes, the way people give feedback must be different.
- Livia:
-
Yes, definitely. Again, we left that at the hands of the team so everyone has done it slightly different. Because they were doing it through the prototypes, the thing I’m most proud of is that it forced the people who were actually doing the work, being the ones showcasing it, it wasn’t some third PM removed from the project talking to some other executive. It was the person who was actually hands-on. That is, I think, fantastic because it really removes layers that are unnecessary from the conversation and allows the feedback to be much more direct. So that’s one thing. And because you have the direct access, you also have quicker turn around. So, even sometimes we were in some sessions getting feedback and if it was someone who was comfortable with the code, they had written it themselves, they would just open something up and change it on the fly and say “is this what you meant?” That is light years away from a conversation on a printed piece of paper that gets sent back, and et cetera, et cetera. I think that is very transformative. I don’t think people necessarily realize that they will change because it’s just how we’re working now. It’s kind of a non-issue. I think it definitely changed the level of the conversation. The conversation’s a lot more focused on the specific things that are happening. Not looking at a status screen and describing the behavior. It’s too abstracted from the reality. I think it really allowed people to come together and more specifically give feedback on specific things.
At the same time, one of the things I was coaching the team on is how to get feedback. It’s not, you know, “hey here it is, what do you think?” Right? Which some teams have done that in the past. But you come in and you say, “this is what we intended with this particular prototype, these are the areas that we’re focusing on, I would like your feedback on X, Y, Z.” That was the prescriptive part. I wanted people to start getting feedback in this particular manner. I think those two things together have really strengthened that model. And now it’s very rare that you have someone who has not been involved in the conversations like another stakeholder that maybe wasn’t active in the project come in at the eleventh hour with some feedback because the prototype was always available. Anyone has the opportunity to go check it out anytime. Feedback can come earlier, it doesn’t have to wait for the bureaucracy to make it happen.
- Ethan:
-
Kind of related to that, as you guys are closing these feedback loops, has the QA process changed. Are you testing these prototypes as you’re designing them? I’d be interested to hear a little bit more about that.
- Livia:
-
Our QA process, I wouldn’t say has changed in a significant way, but we have definitely reviewed what we’re testing on and the priority of testing. What are all the devices we’re going to test? And the order of scenarios that are most important. That’s really just sort of a regular revision that happens. In parallel to having this program, I had started this Standards and Practices effort. We have a little working group called “The Level of Support” working group, which looks at our level of support for operating systems, browsers, and devices. That team is always looking at our metrics on a periodic basis and saying this is what we need to support as an organization. That is always helping the QA team identify what to test on and how. In addition to that, when we’re prototyping we said we don’t need to have the same level of scrutiny in prototyping as we do for production code. We have a much smaller subset of things that we tasked on. As long as it worked in Firefox and Chrome, the prototype was good enough. If people are sending me issues that they saw in IE, I’m going to say, “excuse me, open another browser and try again.” It’s just not worth the effort to try and get that level of coverage so early on. The point of the prototype is to get you further, faster. So we made that distinction there. The level of QA on the prototyping is part of doing the work, part of writing the code. It’s not a separate effort. We definitely don’t have a special process for that. We did adopt using GitHub as our prototyping repo which helped a lot because you can tackle all the issues there. Everyone can always download it and try to play with it, which was also part of making things a little more easy to adopt and understand. I hope that answers your question.
- Ethan:
-
Yeah, perfectly so.
- Karen:
-
Once you go live, how are you going to evaluate the success of this responsive design? Do you, when you’re looking at the responsive website versus other channels like apps or even the call center, are you pitting them against each other? Or do you just evaluate success in terms of people being able to use whatever channel they want to use?
Historically people were asking “oh so is this site for desktop and now it’s going to be for mobile?” I said “don’t even use these terms because they don’t mean anything.” There was definitely a lot of discussion about language as we started evolving these practices and getting rid of this “mobile versus desktop” mentality is definitely one that was slow because I was so gung ho on it. Now that we’re there I feel like the organization has stopped using these terms in the way they were using them before.
- Livia:
-
We definitely take a position that we would like our guests to work with us however is most appropriate for them. We definitely want to try to favor our web experience as a way to unify and have people work with us directly. But, we don’t want to have an expectation that we really need to drive people to the app instead of the site. We already have metrics for all of these things. Dashboards that tell us performance across the board. Nothing there is significantly different in terms of how we’re going to monitor going forward. The only difference is that maybe, historically, we have looked separately at metrics for mobile versus non-mobile and now we’ve already unified that. Even ahead of having the site be totally responsive, to just start thinking that way. Historically people were asking “oh so is this site for desktop and now it’s going to be for mobile?” I said “don’t even use these terms because they don’t mean anything.” We’re just looking at our data across the board in three main section categories: smartphones, tablets, and everything else, basically. That’s just from a reporting standpoint. When we’re talking about design, we don’t even use that language. We talk breakpoints because that level of granularity makes sense there. There was definitely a lot of discussion about language as we started evolving these practices and getting rid of this “mobile versus desktop” mentality is definitely one that was slow because I was so gung ho on it. Now that we’re there I feel like the organization has stopped using these terms in the way they were using them before.
- Karen:
-
With that I don’t think there would be a better note to end this conversation on. Liv, thank you so much for talking to us about this. I hope you won’t mind if you see quotes from you liberally sprinkled through every presentation I ever give.
- Livia:
-
Thank you, I really appreciate your guys’ time. I guess you can ask me again in a little while how this is working out because we’re going live tomorrow. I’d be happy to follow up questions any one has.
- Ethan:
-
Thanks to everyone for listening to this episode of a responsive web design podcast.
- Karen:
-
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.
- Ethan:
-
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.
- Karen:
-
Thanks again to our sponsor, Campaign Monitor, and we’ll be back next week.