Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well, we’re ready for liftoff because we have two wonderful guests. We have Frank de Boer and Jan Willem Kluivers from KLM. Frank, Jan Willem, thank you so much for joining us.

Jan Willem:

You’re more than welcome.

Karen:

But before we get started, I’d like to say a few words about our sponsor, Media Temple. If you’re a web designer or developer, you need solid hosting with great customer support. Media Temple focuses on the needs of the design community, and is constantly improving their products to make hosting simple for you. That’s why they have one of the highest customer loyalty rates in the industry, with the average customer sticking around for years. If you’re looking for WordPress hosting, shared hosting, virtual private server hosting, or just want something better than a crappy $5 a month hosting plan, you want Media Temple. Go to mediatemple.net and learn about their hosting services and award winning support team.

Ethan:

So I have to say, there aren’t too many responsive airline sites that I’m aware of, and KLM is definitely one of the prettiest ones that I’ve seen out there, airline industry or not. I’d love to hear a little bit more about the design over the course of the interview, but first maybe you both could introduce yourselves and tell us a little bit more about what you do at KLM. Frank, why don’t you go first?

Frank:

Yes, okay. Thank you, Ethan, for having us. As you said, my name is Frank and I’m responsible for content development and user insight at KLM.com.

Jan Willem:

Hi, I’m Jan Willem Kluivers. I’m currently working on the on-board portal and I’ve previously headed the responsive design program within KLM.

It was the basic strength of CSS and JavaScript that put us on the path of responsive design.

Ethan:

Well, once again, thank you so much for joining us. I guess before we dive into the nitty gritty of the redesign, I’d love to hear a little bit more about the origin story—you know, how KLM made the decision to go responsive. And specifically, I’d love to hear how you actually managed to convince your stakeholders and your executives that responsive design was the right way to go. And the other part of that question would be, in those discussions, were there any concerns or questions that were raised about responsive design as to whether it was actually the right approach or not.

Jan Willem:

I think I can say something about that. So, what you basically see is that within KLM we became aware of the fact that we needed to serve our mobile customers pretty early in the process. Most of the customers that buy a ticket end up in an aircraft, as you can imagine, and being there to support them getting in that aircraft is very important.

So, we had a mobile website very early on when mobile came up, so to say, and that mobile website actually screen scraped, and maybe this is really old school, but it looked at the dot-com website and it just reused the components in there, the content in there, and it reformatted it to a mobile website. As you can imagine, using a website that is managed by about eighty people, constantly improving it, also creates a lot of problems with links that break if you copy that via a third-party. So this mobile solution we had that also powered the native app via web views really created maintainability issues.

We had to look for alternatives, and it was the basic strength of CSS and JavaScript that put us on the path of responsive design. So, after some desktop research and a proof of concept with the arrivals and departures page, we actually created a business case together with UX, the design agency, and our information services solution, our department, to see if we could migrate the website to a responsive design setup. And basically together with the moment that we had our solution, Google also said that responsive was the way to go, so it was like literally one day before we presented it, and I think that’s what prevailed the choice.

The next step up would be adaptive, where we would actually adapt the content that we serve, not only give the content that’s really relevant first, but also adapt it into a more personalized offer.

Karen:

As we were prepping for this call, you brought up a topic that is really near and dear to my heart, which is the question of whether you should go responsive or maybe adaptive was a better solution. Can you talk a little bit about how you defined responsive versus adaptive and why you settled on responsive as the right approach?

Jan Willem:

So what you see is, as we said, there is a whole discussion between responsive and adaptive, and I think we staged the development. So what we said is first let’s make our website respond to the device that our customers are using at that particular moment when they visit the site. And as I said, we had a lot of link-breaking and stuff going wrong when people visited—landing pages, for instance, when they got in via Google. And the first step was to make sure that the page just worked on a certain device, and the next step up would be adaptive, where we would actually say, okay, let’s adapt the content that we serve, not only give the content that’s really relevant first, but also adapt it into a more personalized offer. And I think we can say that we staged it like that, but still I think there is sort of a theoretical discussion going on of one or the other, etc.

What we see is that they actually are the same users but are in a different phase of their customer journey, so that information is need-based.

Ethan:

One thing I’d like to hear a little bit more about as kind of an extension of that is how KLM talks about mobile users versus desktop users. I mean especially in the travel industry, this is sort of like this stereotypical mobile user who needs a slimmed down, refined experience custom to that device, whereas desktop users kind of can sift through more information, they have a little bit more time to work with. Does KLM divide users into device-specific camps or do they really just feel that all users need more or less the same information? How did that inform the responsive design?

Frank:

I think I can answer that question. What we see is that they actually are the same users but are in a different phase of their customer journey, so that information is need-based, and which phase of the customer journey are customers are in, based on that knowledge, we can focus and present information showing on desktop or on a smartphone. For example, most bookings are still made on the desktop while trip preparation has a large share of mobile users.

This enabled us to migrate about twenty applications, each at their own time, reusing responsive components that we created.

Karen:

I’d be curious to know, as you sat down and started planning this project, how did you scope it to identify how long it was going to take, how much it was going to cost? Sometimes people that Ethan and I talk to say that there’s this reputation in the industry that responsive design has to take longer and has to cost more than previous projects. Did you find that?

Jan Willem:

Well first, we started with a pilot on the arrivals and departures page. I would advise you to go there today, you will see the split personality of the application. You have the moving map where you can see all the aircraft and have fun if you’re on your desktop and you have some time to kill, but you can also see the efficiency if you’re on your mobile and you’re at the airport and you want to pick up a relative. Having this proof of concept clearly shows the technical strength of the solution, so the integrativeness within the total platform was the way to go.

Based on the results, we created a program that actually envisioned converging the entire KLM.com. And you might say that’s something that’s really difficult to do, especially if you have about ten teams all having their own application and building responsively, but what we did is we reused components from within each application and put it in sort of a Bootstrap. And since the main page on KLM.com wasn’t changed, so the home page wasn’t, the frame where everything was in wasn’t responsive, and the application itself wasn’t responsive until we unlocked that main page. This enabled us to migrate about twenty applications, each at their own time, reusing responsive components that we created, and then unleashing the responsive power all at once and killing the mobile site while doing that. I think that was really helpful because you don’t have this “switching users” experience where you have to redirect people to one application, to the mobile site, and then back to the other, et cetera, because that would have been killing. So having a solution on one end in place for mobile users, having your desktop just serve as a regular desktop because it’s responsive and it shows desktop users what it shows today, and then having the ability to switch it all at once really helped to scope and to execute on it.

With the responsive component library we created together with the design agency, we kind of naturally grew our responsive assets.

Karen:

If I could just follow up on that, how did you plan that rollout process as you were working with all your various stakeholders or all the different lines of business? How did you decide to start with the arrivals and departures page and then how did you plan out how you were going to work with all of the other groups that you had to work with?

Jan Willem:

So I work within the strategy department and we touch applications on a platform-wide basis, so basically we touch every application in the landscape. So we requested a budget to fund all the application owners in building it and we just plotted it on their roadmaps and said, “Okay, you have to do this, so give me your timelines,” and then we scheduled it all back. We started with the most difficult ones because they had additional time to tinker while the others were catching up, and I think that was a very natural process. So they didn’t have to hassle for money, we just funded their development, and with the responsive component library we created together with the design agency, we kind of naturally grew our responsive assets and they were reused with a less popular application, so to say.

Frank:

I want to add to that, is the results from the first responsive application, the departures and arrivals application, we saw the positive effect on users and customers, and that gave a drive for the other application owners that this was really the way to go and that we benefit clearly from changing to responsive.

We had to change from making a pixel-perfect design to the content-first principle, and actually that was the biggest change we had to make.

Ethan:

One thing I’d like to hear a little bit more about is that system of components that you both talked about, and specifically the design process for creating it. As you’re transitioning from a separate m-dot experience and a desktop website into a more multi-device holistic one, how did your design process change when you were thinking about this more component-driven design methodology?

Frank:

We had to change from making a pixel-perfect design to the content-first principle, and actually that was the biggest change we had to make. We had to start thinking about what are the user needs of our customers and which user needs have the highest priority, and from there it became natural to start with a content first principle, which it has the priority on the small screen, and then make it bigger and add things.

Photoshop is a very forgiving tool if you’re a designer, but it’s not as forgiving if you’re a builder, right? If you have to create actual working web pages, it doesn’t always look as good in your browser as it does in Photoshop.

Ethan:

You can’t see me because this is in audio format, but I was raising my fist excitedly in the air; that sounds really exciting. The other thing I’d like to hear a little bit more about is the applications and tools you used for that. Was it sort of more traditional design applications like Photoshop and Illustrator? Was there some prototyping involved to start talking about these components as you were designing them? Tell me a little bit more about the actual programs and tools you were using.

Frank:

We used many tools, but what I found out was that by just first writing down what your most important thoughts for the customers are, just on a plain sheet of paper, was the most powerful. Hang it up on the wall and always refer back to it, “These are the reasons for making this design.” The next step would be interaction design, and also sketches, and eventually for the big aggregations we would make prototypes. So, we used several methods, but mainly the sketching and just writing down what is the most important to our customers, or the most helpful.

We actually forced them to reuse those components to create two things: the first one is consistency for our user, and the second one is agility and speed of development.

Jan Willem:

I would like to add one thing to that. I think if you’re talking about tools, I heard you say Photoshop. So Photoshop is a very forgiving tool if you’re a designer, but it’s not as forgiving if you’re a builder, right? If you have to create actual working web pages, it doesn’t always look as good in your browser as it does in Photoshop.

What we tried to create with the Bootstrap is actually three things. So first, we decided upon a design, and the design is always made in Photoshop, and we created three versions of it. We looked at the certain breakpoints and we said, “Okay, give us a design for each breakpoint.” And then we said, “Okay, this particular component,” let’s call it, for instance, a carousel, “what does it do and when do you use it?” So, “When do you use this carousel and when do you use that carousel? When do you use this button and when do you use that button?” And then we had IT, our information systems service provider create the component in a responsive format, so you can actually see it in all breakpoint variations.

And as I said, since we have a lot of people working on the website, have a lot of applications with their own owners, we actually forced them to reuse those components to create two things: the first one is consistency for our user, and the second one is agility and speed of development. If you don’t have to design every page over and over again, that really helps to speed up the build process. And then with the components that you could just throw in your application and they worked out of the box, and they’re checked with the team that actually ensures new browsers are compatible with it and then if something breaks they fix the nitty gritty, that, as a toolset to create a component or a style element so to say, I think is the ideal mix.

We didn’t change our CMS, we changed the way of working.

Karen:

Maybe you could talk a little bit about content changes that you made as part of going responsive. So, did you have to write things differently or prioritize things differently? Did you have to make changes to your content management system to support this?

Frank:

At the same time we started to do responsive design, we also started with an agile way of working, and that especially had a big impact on the whole organization but also on content relation, because having a finished website where you just have to fill in the labels, now the content editors are co-creating with developers and learning together… So, the process change for our CMS, we use SDL Tridion, and we have our own content group that made all the templating responsive. So we didn’t change our CMS, we changed the way of working.

Karen:

Talk a little bit about how going responsive might have changed the way that you review work in progress with the rest of the organization. Did you have to show various stakeholders something different, like prototypes on the server or show work in context of different devices?

Frank:

Absolutely we did, because everybody was very excited and more in a positive spirit. “Okay, you tell us that it works, you showed us with the arrivals and departures application that our customers are becoming more satisfied.” So, they were demanding and wanted to see always the mobile designs, prototypes, but also the components we made. And of course, in the whole support part of our development, we added a new mobile testing facility.

We made the choice to throw in graceful degradation, to accept the fact that not every browser is as powerful as the newest and latest and greatest.

Ethan:

Frank, your timing couldn’t be better to mention mobile testing because that was, in fact, going to be my next question. I would love to hear a little bit more about how KLM talks about device support. What does your testing suite look like? If you could talk broadly about the kinds of devices you’re really targeting with your responsive design, just talk a little bit more about how you decide what you’re actually supporting with a new device agnostic experience.

Jan Willem:

Maybe I could say something about that. So, let’s talk IE7. I think the main question is what do you want to do? Are you going to tailor your organization around IE7 and make sure that it works on that browser and then have all the other ones wait until the late majority also migrates to a new browser? I think we made the choice to throw in graceful degradation, to accept the fact that not every browser is as powerful as the newest and latest and greatest. So, we put in graceful degradation to make sure that at least the most basic of basic sites works on your browser—that was back in the days when we started this. I think for now we can see that we mostly tailor to the more modern browsers.

We also see in our Webtrends reports that those are the ones that are heavily using our offers. And as for testing, as Frank already mentioned, we have a live device test lab, so we have a bunch of devices based on what we see in Webtrends tagging are used most, and we have those devices in-house to make sure that they work on those devices. The difficulty of course is when you have various versions. I would say that the iOS orientated flavors are a bit easier, but still, we tend to test on all of those. And then we have automated test reads where at least everything is unit tested and ensured that it works as it should. I don’t know, Frank, do you have anything to add to that?

Frank:

We decided is we couldn’t test and validate every screen size available, so we had our predefined breakpoints on those devices and those screens we do best, and on other screens it will adapt to the screen by the device itself. That’s a little bit how we could manage the vast array of all the devices that are available.

In the beginning we talked about device sniffing and device recognition and redirecting and I don’t know what, but in the end now it works like a charm. You don’t have to do all those difficult things.

Jan Willem:

Yeah, I would like to add that you have to trust the technology, right? And I think if you trust styling in general, then you can trust that it will work as you envisioned it. In the beginning we talked about device sniffing and device recognition and redirecting and I don’t know what, but in the end now it works like a charm. You don’t have to do all those difficult things. You can just rely on the fact that browsers will interpret your code well. It doesn’t mean that you don’t have to test—you definitely have to test it, of course. But yeah, I think not sticking with IE7, as it should work on IE7, really helped us to break through and move on.

Frank:

I still remember, Jan Willem, the device recognition tooling. We had so many lengthy discussions… In the end, we had so many discussions that we just went live and we said, “We’ll figure it out along the way.” Actually, it appeared that we didn’t really need it until now, so that was also, for me, some kind of epiphany. “Okay, just do it, and trust in the technology,” especially nowadays, and you can go a long way.

Jan Willem:

And I would like to add one more thing, and that is, of course, as I said with Webtrends—so, we have huge amounts of traffic on our website and if there is a particular device that really has its fair share in our landscape, or browser, and it doesn’t work, we’ll notice pretty quickly and then you can always find out. In the end, I think having the actual device, especially in the beginning, is really important, because using emulators is not going to bring you anywhere close to the real experience, especially if you want to feel how it works. You really need to have the device. Even with the iPhone 6+, again you see that you need it to experience it.

Running KLM.com on a mobile device on board of an aircraft is still really challenging.

Ethan:

I think that’s a really great point. Sort of the other side of that coin though, I’d love to hear a little bit more about how KLM talks about performance. Talking about testing for not just different screen sizes but maybe for different network connections. Is this something that was part of the redesign process?

Frank:

No, we took it into consideration at a later stage. Of course you want to watch how big the visuals are that you put on your website. And actually right after the release of the website, we added functionality in our CDN to detect the bandwidth and device type to scale down the quality of the website to a more acceptable level, and that seems to work fine in faraway countries like China.

Jan Willem:

Yeah, and I’m going to be honest here, so as I said in my introduction, I’m working on the on-board portal. Basically it’s mobile to a new level because you’re flying at 800 MPH and you have a satellite you have to connect to, so the amount of bandwidth you have together with the latency is really killing. So I see that, running KLM.com on a mobile device on board of an aircraft is still really challenging. I think in the end, looking at performance, I would’ve hoped that we would have made an even bigger achievement there, but there’s always room to improve.

Frank:

I agree with that.

We don’t measure in a different way. What we measure and what we want to know is from every visitor of KLM.com, regardless of which device, is what’s their intention, what is their behavior, and what is their perception?

Karen:

Well speaking of room for improvement, can you talk about how you measure the success of this responsive redesign? And are you looking at your analytics data any differently now that you’re looking across device types, or do you measure the performance of the site in some different way?

Frank:

No, we don’t measure in a different way. What we measure and what we want to know is from every visitor of KLM.com, regardless of which device, is what’s their intention, what is their behavior, and what is their perception? And what we see by measuring those three characteristics, we can really determine how a certain channel or touchpoint is doing.

If you’re a listener and you have a big website like we have, making web responsive components, to me, makes a lot of sense. Just do it, create a component library, and speed up your overall development.

Ethan:

Well, that’s great. As we come to the end of our time together, I’d love to hear from both of you: was there anything that you learned over the course of this responsive redesign for KLM that you’d like to share with our listeners? Specifically, there might be some people in the audience that are starting a responsive redesign today. What’s one or two things you’d like to share with them? Jan Willem, if you’d like to go first.

Jan Willem:

So, my advice would be, if you want to, you can start small and just take a part of the website and make it responsive and then see how that works with visitors. Of course, if you have a separate mobile website, that makes it a bit more difficult. But if you want to dip your toe in the water, you could do that. In the end, I would say just do it, it makes total sense.

And from my point of view, if you’re a listener and you have a big website like we have, making web responsive components, to me, makes a lot of sense. Having your design agency and your IT organization and your business owners all come together in one platform where you have the components, the building blocks, the legal, so to speak, to build your application really helps them to understand what you mean with it, and it eases the pain of building it. So yeah, just do it, create a component library, and speed up your overall development.

Your customer satisfaction is going to go through the roof. People are expecting it nowadays to access your website on a mobile device for that inspiration, for the preparation.

Frank:

And if I may add to that—actually, I could add a lot to that—but the only thing I want to add is consider your customer satisfaction. Maybe your conversion levels are not going up on your mobile touchpoint, but your customer satisfaction is going to go through the roof. People are expecting it nowadays to access your website on a mobile device for that inspiration, for the preparation. And they will make the sale, they will make the conversion in a later stage, maybe on a desktop, but for now the inspiration/preparation phase is extremely important.

Karen:

Well Frank, Jan Willem, this has really been a pleasure listening to you. I’m always so impressed by large-scale airline website redesigns because I understand how complex it is for you to pull off, and you have done a fantastic job. So, I appreciate your sharing of a little of the story with us on behalf of our listeners, so thank you.

Jan Willem:

You’re more than welcome. Thank you for having us.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast. Thanks also to our sponsor, Media Temple. Go to mediatemple.net for easy to use hosting and 24/7 customer support.

If your company wants to go responsive but you need help getting started, Ethan and I offer a two-day onsite workshop to help you make it happen. Visit responsivewebdesign.com/workshop to find out more and let us know your company is 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 for listening, and we’ll be back next week.