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 are so excited, it is like our stock is going through the roof. We are here with Gadi Lahav from the Financial Times. Thank you so much for joining us.

Gadi:

Good to be here.

Ethan:

But before we dive in, I’d like to take a moment to mention our sponsor, Gather Content dot com. GatherContent is a wonderful content collaboration platform that helps teams plan, organize and produce all of their web content in one place. And on December 8th, they’re offering a free online master class—that’s right, free! And online! Regardless of whether you’re part of an in-house team or working at an agency, this class will help you with your content strategy and delivery.

Gather Content’s free online class will take place on Thursday December 8th, at 4pm UK time. If that sounds like it’s up your alley, visit gathercontent.com/masterclass to register, and thanks again to them for sponsoring.

Karen:

So, I’m thrilled that you decided to come on our show, and I’m especially thrilled because the relaunch of FT.com is spectacular, it’s a beautiful piece of responsive design. So, I would love it if you could just start out, give us a little bit of background about you, your role at the Financial Times, and perhaps even for our listeners who might not be familiar, a little bit about the product itself.

Gadi:

Yes, sure. So, I’m the head of product for FT.com. FT.com is a program within the Financial Times that is in charge of the different platforms through which users interact with our content and with the articles that they want to read. It includes the FT.com website—the new website that we are about to discuss today; the web app, one of our known products; and other platforms that people interact with, for example Google AMP and Facebook Instant Articles. And we call it one program because we look at it from a user point of view. The user, when they read an article, or they want to read anything on the Financial Times, they don’t really know and they don’t really care whether it’s a website, or an app, or a distributed platform as well call it, as Google AMP… For them, it’s one experience. This is how we want to look at it, and see it from their point of view, because this is the best way that we can see through them.

FT.com, the new website, is replacing the old FT.com, which was a little bit of a legacy website. It took a little bit more than a year to release it, continuously releasing it throughout the year, and the reason was we just wanted to have better technology and a better designed product to meet the user’s needs. That’s basically what the logic was behind that, that led us to start this project, basically.

Karen:

Let me follow up on that just a little bit and ask if there were any debates or questions or concerns about launching FT.com as a responsive website. I’ll follow up on that just by saying I think, in the publisher space in particular, there is a lot of question or experimentation around perhaps developing mobile-only products or believing perhaps that products like Google AMP and Facebook Instant Articles portend the death of the open web. Did you discuss those issues at all as you were thinking about launching a responsive site?

Gadi:

We’re discussing these issues all the time. Maybe it is important to say for the people that don’t know the Financial Times, it’s paid-for digital publisher and we are behind a strict paywall, so you can’t really read even one article without even going on a free trial, which is very different than most publishers, and even with the publishers that are behind a paywall, like the New York Times, they have a metered paywall where you can read a little bit before you commit to and pay monthly or annually. This dictates basically our strategy, because what we want is to find the best way to address our user’s needs while they pay us for this. When they approach it from different platforms, we need to think all the time whether this platform makes sense for us to work with or it doesn’t. So for example, if you work with a third-party like Google or Facebook, we need to ask ourselves are we addressing also our business needs and if we are able to make our customers happy within the business model of a paid-for newspaper, paid-for digital publisher.

We had a solution for mobile, but we had a non-responsive website, and when we discussed this, basically there was a clear separation between those two products, which we think isn’t good in the long term. We want to have a consistent experience across all of our devices, and this means that, besides having a web app, you need to also have a responsive site that will allow people to approach your site when they’re using different browsers, when they’re using different devices, whether the web app is not installed or they didn’t download the icon that allows them to use the web app. So yes, it was part of the thing that eventually led us to decide to do that.

The other thing was that the website was a little bit dated, both in design and technology, and we just felt that we had to do that. And the idea of having a responsive site was, I wouldn’t say a no-brainer, but this was the default, and we didn’t see any reason to not do that.

Ethan:

Gadi, you said something about providing a consistent experience across devices, so maybe this answers my next question, but when you’re beginning the planning of the responsive FT.com specifically, how did you talk about the needs of mobile users and desktop users? Did you see them as slightly different user groups that needed slightly different information at different touchpoints, or did they basically need access to the same content regardless of the size of their screen?

Gadi:

That’s a very interesting question because there’s no one simple answer to this, and actually it’s a continuous discussion here of how we’re going to do that, and what we know now we didn’t know a year ago. So, I’ll give you an example. Basically we split our audience into two groups. There are more segments, but let’s say two groups: one are our subscribers, people that pay us monthly and they use our website and our different platforms. The other audience, the other group, is what we call the anonymous users, people that come to the site through links, sometimes they come to us directly, and they are our prospect, they may become eventually our subscribers. Their behavior is completely different, because the first group can approach and read every article, and the other group basically cannot read most of it. We do have some initiatives where we allow people, for example, coming from Facebook to read one article per day, we allow some users from Google to read an article, and then kind of experience our content. So, their needs are very, very different, and basically our product vision, one of the elements, is to provide the most relevant information for each individual without obscuring the FT view, and this means that for anonymous users and for subscribers, it’s a little bit different.

So if you look at mobile and desktop, I can tell you already what we learned over time is that anonymous are more likely to come on mobile through search to an article page. And if you think about it, it makes a lot of sense because that’s how they get to the site; somebody’s sending them a link, or they see something on Facebook, or on Twitter. And the subscribers are more likely to use multiple devices, not only mobile, and they are using either the home page of the web app or the home page of the site. So they have very, very different needs, and we try to address those needs separately.

Just to be honest, we launched the site throughout the year and now is the time for us to start addressing each one of them differently, to move away from what we call “one site fits all,” and to start thinking about each one of them separately. So maybe to answer it in a bit more of a concise way: we look at mobile and desktop through these lenses of anonymous and subscribers, and not as just core mobile and core desktop. Among the subscribers, we see a growing cohort of people that are using more than one device, and this is why I think the responsive design is really, really crucial, and our next step would be also to align the web app and the website to be more consistent together.

Karen:

I’d love to hear a little bit about how you planned and scoped a project of this magnitude. How did you anticipate how long the project would take, or how much it would cost, or what would be done when? And in particular, I’d be interested to know how you planned your rollout. So, were you testing this with users; did you launch in a public beta before you actually made it the official FT.com?

Gadi:

We took the opportunity of launching the new website to basically rethink everything that we do and make it better, and we are very happy with where we are. So, I’ll try to walk you through what we did. We started in a very “start-up” way. We had a few people in the room—very few, less than ten—and they came up with less than an MVP but something that we could go out and put in front of people very, very quickly. The whole idea was to get information and data and feedback as quickly as possible. This was done before we even had a product vision, and the whole idea was to put it there and get information so our product vision would be influenced not only by our thoughts but also by what people say and tell us and what they do on the site. Of course in the beginning we had the early adopters, but over time we’ve just adjusted when more people were joining the site.

We had several principles that we worked according to. From a technological and design point of view, we said the concept of the site was to build it from different bricks. Instead of just like, “Hey, let’s do a home page, let’s do an article page,” we have different things that we called N Cards, because the internal name of the project was Next, the Next FT. So we called them N Cards, and from these bricks we build different pages. So, of course eventually you have an article page and you have a home page, but they are built from these bricks.

The whole content, all the articles are linked through what we call Topics, it’s a very flat structure. Each article has three, four, five topics, and each topic is extended on, there’s a connection between them, it allows us to make recommendations and allows people to follow what they want and what they’re interested in.

We started very small, and some of the principles that we had were we don’t work by dates, we work by achieving our goals, and we don’t work by features, we work by user journeys. We identified the user journeys over time, we made them better, and we improved our goals. What we said is as soon as we see that we are addressing the needs of users and we make the site better for them according to the goals that we set for ourselves, and we also provide better business results for the business, this is when we’re going to make it live. So if you would have asked me nine months ago, we wouldn’t have been able to say exactly when we were going to launch it. We decided around April that we were in good shape and that now we would take six months to groom everything to make it sharper and then go live. I think this approach is something that we’re going to carry on and do, and not work anymore by any kind of date and promise, anything like that. We’ll just say, “We want to improve in that area.”

I think some examples of the goals that we had, the main was, of course, engagement. We measure engagement in the FT with a formula that we call RFV: R is for Recency, F is for Frequency, and V is for Volume. Frequency means the number of visits, Volume is the number of articles that you read, and we have a formula that eventually gives you a number. This number has a clear correlation with your likelihood of renewing your subscription. So if we make this number higher for everyone, we just increase the retention of our site. We were able to see, throughout time this year, that people that moved to the new site were between twenty and thirty percent more engaged, and this was consistent, month after month; the new people that came, month after month they were more engaged.

So when we looked at this throughout the year, every time we had more people, depending on if we had less early adopters than everyone choosing the main stream, and every time they had different needs, we created a very rich environment of both data—so, for example, we have our own analytic tool, we built our own MVP, A/B test tool, and we ran a lot of tests, and we also invited customers on a weekly basis to the FT. So every person on the team met customers at least once, usually much more than that, and every time we said, “Okay, what do we want to speak about right now? Is it the problems that we see on the home page? Is it something on the article page? Is it about the navigation?” Those ideas came from the feedback that people left us on the site. It was always around what people wanted. We say that if we address the needs, then the business goals will follow, not the other way around. So, eventually we did it within a little bit more than a year, it was a little bit faster than we expected, and the results were a little bit better, and we’re very happy with the results.

Ethan:

Gadi, I was struck listening to you talk about that more modular, more brick-focused design process, which I think is really interesting because a lot of organizations are still very much focused on this idea of the page, that we have to create these specific pages and then sort of implement them accordingly. Was that a shift for the designers on your team, adopting that more brick-focused model? Were they working more with prototypes on this project than they might have in the past? Tell me a little bit about that design process.

Gadi:

I don’t know if it was a shift, because I think a lot of people, including myself, joined the FT—I joined like a year and a half ago. I think it’s a shift for the organization and I think it is very exciting to work in that way. There is a challenge in which you look at each component separately, but then you need to look at it holistically, also. But I think the advantage of the flexibility is really, really good. I can give one example where we built a component for Brexit, or back then it was the UK/EU referendum, and the component was built in a way that very quickly we could adjust it and fix it and change it according to the news agenda. And the news agenda, it was the most important event in UK news this year, probably in this decade, and it was a milestone here and a very exciting moment at the FT, and we could respond very quickly to that. I think this is where, for example, some people that were a little bit skeptical about this found that this approach and this site was really addressing their needs.

Another thing that we are doing which is related to this kind of brick philosophy is that we’re using something that we call Feature Flags. So we build a feature and we put it behind a flag so that nobody can actually see that, and then we decide how many people are going to see this feature, and release it slowly. So it can be we show it only to people in the building, just to see how they react. And then we show it to people that come here to see that. Then we say we can show it only to people that have this RFV score. And then we eventually release it either to everyone or we show it to some people and don’t show it to other people because they don’t really need that. So at the moment, because the site was just launched, we strived to get to a version of MVP—it’s more than MVP, but something that we can actually make live for everyone and make a different site of the FT very quickly.

But from now on, again, we’ll move away from one site fits all, we’re able to use this kind of brick philosophy not only to have different bricks to build a page but also to have different page versions for each person. As an example, if you’re coming from the home page to an article page, you’re in the middle of a journey that we call the home page journey, you look through all the headlines on the home page. So at the bottom of the article, you may need very, very different links than somebody who’s coming to the same article from a google search or from an email. The brick component and the brick philosophy helps us to actually address needs for different people in different ways.

Karen:

Let me ask about potential changes that you might have made to your content management system and your overall publishing workflow. I know Ethan and I have talked to some teams that say doing a major redesign like this is also an opportunity to reevaluate the publishing system and honestly really look at the entire process for how journalists are going to participate and work within the CMS. Other teams are like we just want to focus on a front-end redesign, we’re not going to touch anything on the back-end. How did you handle that?

Gadi:

I think you’re right, it’s a really good opportunity to examine things and make things better. To be honest, in our case, we have decided to split it. The CMS is a different system, a different platform, so we didn’t do a lot of changes over there. But what we are going to do right now is align them together. It was more important for us to address the problems that we had with design and with UX because the site was not responsive, and we tried to—because we work in a lean way, in continuous deployment all the time, so we said it’s better for us to focus on that than to align or do those two things together and make this project a little bit more complicated at this stage. But we are looking at this in the near future.

So for example, right now we are starting an initiative. Part of the product vision, as I said before, one is to provide a consistent experience, the other element is to provide the most relevant information for each individual. Another element is to bring clarity to news so we can, by better presentation of information, we help people make better decisions. Because we are a financial newspaper read by a lot of people actually using it as a working tool, so you want to make things very clear to them. So this initiative will allow us to work with the CMS, of what kind of tools we want to provide our journalists, and what kind of presentation do we want to show on the front-end? For those two things to work together and both help journalists become more productive or help them—they provide us with excellent content, which is why people want to subscribe to the FT, they don’t come here for the product, they come here for the content, and we want to provide them the best tools for the full potential of this content. So on the front-end, we’ll be able to optimize the user experience, so people will spend less time and less effort in understanding the news.

There’s another element to that by the way, which is metadata. So besides working together, aligning the CMS and the front-end, we also have an API program where all the content is going through a metadata process, and then we can make the right connections and put things in context. So it means if you’re reading about one topic, we’ll be able to show you relevant topics, or in the near future, if you’re reading about something and there are people similar to you and we see the connections based on this metadata, we’re able to provide you relevant information for you based on your history or based on the content that you’re reading.

Ethan:

You mentioned the phrase “optimizing the user experience,” and it made me think of all the great page speed and performance work that’s been coming out of the FT and the FT Labs specifically over the last few years. Can you tell me a little bit if performance was something that was a design priority for FT.com, and how did your team actually talk about performance while you were building this responsive site?

Gadi:

Actually, this is one of our key achievements and key elements in our process. I’ll start from scratch, because we said the site must be super fast. Everybody wants their site to be super fast, right? And then there’s a difference between what you say and what you do. Our question was, to ourselves, how much do we really want to invest in performance? Is it an overarching element? Is it more important than anything else? And since we are in a data-informed and user feedback-rich environment, we said let’s test that and let’s see what the results are.

So very, very early, something like a year ago when the site had less than five percent of our users, we did an A/B test. The site was already three seconds faster than our old site—and now it’s faster by more than three seconds. And what we did is we split the people that joined the site at that time into four groups: the first group got a site that is as fast as the old FT.com, so we didn’t hurt their user experience, basically they got the same user experience; the second group got the site that was one second faster; the third group two seconds faster; and the fourth group, three seconds faster. And then we looked at their engagement over time.

It took more than a month, and we looked at their total consumption not on a specific visit, not on a specific day, but throughout the full period, which was a little bit more than a month, and then we looked at the results. They were staggering and very, very clear: that every second that we made our site faster equals around a five percent increase in engagement. We quantified this, we took this and we translated that into retention rates and ad revenues, the numbers were in the seven digits. This is where we decided, based on the data and based on the user experience, that the page load time or performance is basically at the top of our list for everything we do.

And ever since, we work according to that, so our site is the fastest in the industry right now, loads very fast both on mobile and on desktop. We monitor it on a daily basis. Every time that we develop something—and we have six different things working in parallel—every time they do something, they know that part of the criteria is to see how this is influencing performance. And every now and then, we do a tech debt exercise where we clean the site to make sure that we keep and maintain that, because it’s not easy to get to a very fast site, but it’s far easier over time to just add stuff and eventually dilute your speed. I think this is maybe one of the things that we’re most proud of, the way that we did this, and the results, and we are very, very excited about this.

Karen:

I would imagine that, overall throughout the redesign and then looking to the future, you look at a lot of data to evaluate how well the site is doing and whether it’s actually reaching your intended goals. Can you talk about what sort of data or analytics you’re looking at to identify whether you might need to make changes in the future?

Gadi:

We’d probably need more than an hour for this, because we looked at a lot of data, and the challenge is usually to find the right measurement, the right metric to look at, because otherwise you may just drown in too many details. So again, we set up four goals and we work according to these overarching goals.

The first one was engagement, and I explained already about RFV. The other one was to increase the conversion rate of anonymous users. The third one was to increase ad viewability and ad inventory, and the fourth one was to increase the satisfaction of users. These are the business goals. Because we work based on user journeys and based on user needs, we don’t look and say, “What can I do in order to increase RFV?” We say, “What’s the problem of these users? Well, what is their journey? Here’s the problem. Here’s the problem that, if we solve it, what do we think is going to change?” And then we say, “Okay, we believe the change is going to happen to their behavior,” and then we say, “How is it going to be translated?” So if we give speed as an example, if we make the site faster, we believe that people are not going to drop off their journey as quickly as before that. Then we said, “Okay, if we do that, what do we expect them to do?” We expect them to read more articles eventually over time, and this is exactly what happened.

A different example: we developed a feature with My FT that is highly successful. We said, “What was the problem?” The problem was that people told us, “I’m coming to your home page and I’m really interested in what your editorial team decides is important right now, but I’m also working in the oil industry and I need to read everything about not only oil, but oil in Venezuela, or about this specific company. I’m invested in that company, I’m invested in Facebook, and I want to read about that.” So you can’t put everything on the home page, so we said, “Okay, let’s create another element that is more personalized,” and instead of doing something very sophisticated, which eventually we’ll probably go and do, what we did is told people, “You can just start following things, different topics on site.” And when they did that, they created the right mix for them. We were looking at the data to see how this is influencing their behavior. Again, we started with the user problem and we found the solution for them. The first thing was to speak with people that started using it and they said, “I think we really like it and it helps me find what I’m looking for.” Since we have a very large B2B thing that sells subscription packages to companies, we were able to also get to these people, to our B2B subscribers and kind of train them using My FT, or present them with this option, and see how they reacted. There was a qualitative information gather that showed feedback, gather that showed that people are very happy with My FT. And in addition, we did an analysis where we looked at people and we said, “Here are 100 people that have, more or less, the same engagement score. Here are fifty people of them that started using My FT in October, and fifty people that did not use My FT in October. Let’s wait a couple of months and see what happens to the engagement score of both groups.” After two or three months, we found out that the average increase of engagement was thirty-five percent. So, this is how we, on one hand, address user needs, but on the other hand, measure it in business goals and business metrics.

Ethan:

Gadi, I’d love to hear if you have any advice for our listeners who might be starting their own responsive redesign today. Are there one or two things you’ve learned rebuilding FT.com that you’d like to share with them?

Gadi:

I’ve learned a lot of things, and I must say, first of all, we have a fantastic team here. I’m the one here interviewing right now, but we have a fantastic team led by our director of product, Bede McCarthy, who unfortunately couldn’t join us today because he’s sick. But I think the most important thing that we learned is the way that you work dictates and influences the final outcome more than anything else. Everybody speaks about the lean approach and working in agile. What we learned is that if you have a team, you empower them, you give them an assignment and say, “Here is the cohort that you’re working on. Here is the problem. Go and fix this problem.” You empower them, and you put the right people there—there’s a UXer and a designer, and the product manager, and the developers, and they work together, they own the problem. Usually the outcome will exceed what it would with a top-down approach or any other approach.

The other thing is to work in small steps. Again, it’s the lean approach, but you say, “I think we can do five things. Let’s look at the combination of how easy it is to do that and what’s the potential impact, let’s do the first one and see where we are.” They are hypothesis-led, we have one hypothesis, we built something, we look at what happens after that, and if it’s successful, we continue that, if it’s unsuccessful, we try something else. With this combination of empowered things plus small steps instead of big chunks of work, it’s the most efficient and most exciting and fun way of working. Because if you feel that you own your problem and what you do has impact and you’re not just being told what to do, most people will just make things much better than what would happen if you told them what to do.

Karen:

Well Gadi, this has been spectacular. I think this has been such a thorough and interesting case study of a really great product relaunch. So thank you so much for taking the time to talk with us about it.

Gadi:

Thank you very much. Maybe I would just say something else in the end, which is a little unusual, but I think a lot of credit should come to the board of the FT, because this is a corporation, and within the corporation they allowed this project to grow as a start-up, they empowered the whole team, they gave us a lot of freedom to fail every now and then. I think this is very unusual for a company to do something like that, a project that actually is around the main product of the company, it’s not a sidekick. I think it’s really, really essential and unusual and remarkable. It was important for me to say that.

Karen:

Well, I think that’s great. Thank you so much.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, GatherContent. Go to gathercontent.com and take control of your content production process today.

If your company wants to go responsive but you need a little help getting started, Karen and I offer a two-day onsite workshop to help you make your responsive design happen. Visit responsivewebdesign.com/workshop to drop us a line—we’d love to hear from you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every episode at responsivewebdesign.com.

Thanks so much for listening, and we’ll be back next week.

Thanks for listening, and we’ll be back next week.