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 are impossibly excited to be speaking with Joyce Leung and Jeremy Taylor from Realtor.com. Joyce, Jeremy, thank you so much for joining us.

Jeremy:

Thank you for having us.

Joyce:

Hi, thanks.

Karen:

But before we dive in, I need y’all to listen up. If you’re planning a large-scale website redesign, you’ve probably already realized that the content production process is going to be one of your biggest challenges. GatherContent has a free masterclass on March 17th called “Content Strategy for the Website Redesign Process.” That sounds great, right? That sounds like a really awesome thing for you to check out. So, if you’re an in-house team in particular and you need some coping strategies to keep your content production process on track, and you want to know how focusing on the content can help you make better design decisions, this masterclass is the thing for you to check out! So on March 17th, you should plan to attend this free masterclass sponsored by GatherContent. Go to GatherContent.com and find out more about this masterclass and about their fantastic tool that can help you along the way.

Ethan:

Maybe before we dive into questions, could you just both introduce yourselves to our listeners and tell us a little bit about what you do at Realtor.com?

Jeremy:

Sure. My name is Jeremy Taylor and I am the manager for UX development at Realtor.com. Our parent company is Move, and we have a number of brands we work on, but Realtor.com is our flagship product. So, the main thing that we focus on within our department is making sure that the UI interface is actually working correctly and is built right.

Joyce:

And my name is Joyce. I’m a UI developer working under my great leader, Jeremy. I work mainly on Realtor.com products and I was one of the core contributors on the UI development part of the responsive redesign of Realtor.com.

Originally the request to go responsive actually came from the upper-level of management. We wanted to be able to move in that direction.

Ethan:

Well, like I said before, we are incredibly excited to have the two of you on. Maybe you could tell us a little bit more about the decision to take Realtor.com responsive. Tell us about some of those early days. Specifically, I’d love to hear if there were any discussions with your stakeholders and executives about why this was an important step to take, and specifically were there any questions that came up or difficult discussions around responsive design specifically?

Jeremy:

So, that’s a great question. Originally the request to go responsive actually came from the upper-level of management. We wanted to be able to move in that direction. What we found though was that getting everybody to have agreement within a large company obviously takes a little bit of effort, so what we had to do was try and find a way of showing everybody within the company what we had in mind so that we could actually get them to be on board as well.

As you can imagine, Realtor.com has a large revenue and we wanted to make sure that, first of all, if we were going to update our interface, that we were going to be providing a way of reaching parity with what we had so far. So, we wanted to improve the experience for our mobile users, but we didn’t want to affect the baseline of where the company was at that present time.

Joyce:

And we looked at actually a few different frameworks at the time and we chose to adopt Bootstrap 3 as our framework to move on, and this provided us with enough flexibility to morph into what we need. So with this, we were able to build a prototype of the core search experience pretty quickly, and because of this, leadership was able to see the value in responsive. They saw how much quicker it was to develop features on a single codebase compared to building on separate platforms like we did with an m-dot versus the desktop.

Jeremy:

And as well is that it would improve our search engine optimization, obviously. We wanted to find ways of making things quicker to develop so we could move quickly, keep ahead of the competition, and have a robust framework. So we found that by approaching everybody with the idea of going responsive, we were able to tackle lots of things that we wanted to achieve in one rebuild of the site.

With such data-heavy content to work with, we had to be really strategic with how we present this information on different devices.

Karen:

Sometimes when Ethan and I talk to organizations, some companies say that they really struggle with the question of whether mobile users and desktop users need different information or different services. I have to say that it seems like the organizations that really struggle the most with these types of questions are either travel companies or companies that are doing truly localized information. So, for Realtor.com, given that you have what I would imagine is actually a pretty strong mobile use case for people on smartphones, can you talk about how you worked through the question of whether mobile users or desktop users needed enough of the same information so that you could go responsive?

Jeremy:

Well, obviously being a company that is focused primarily on providing users with information about real estate, you get people in lots of different scenarios of using the site. So, some people may be at home using the site and they might want to have some sort of map experience and some sort of listing experience that they can go through and they can drill down and find greater information about a particular property, and then other people might be actually on the road and they may just need to have the information that they want quickly whilst they’re in that particular location about a particular property. So, we needed to be able to find a way to actually provide different data sets to different user scenarios, and we found that having a robust mobile experience would allow us to be able to do that.

Joyce:

And like Jeremy mentioned, Realtor.com is a real estate search engine and it has a lot of useful information, but with such data-heavy content to work with, we had to be really strategic with how we present this information on different devices. So in general, the desktop experience would have more functionality and more content where our users can drill down more and find out more information and get into the details. However on the mobile device, we often abbreviate this version.

An example would be like the property details page. This is the page that people land on when they click on a property they wish to see. On the desktop experience, we would have a full breakdown of tax records throughout the years for the user to view. However, on the mobile experience, instead of showing the full breakdown, we may only show just the recent tax assessment just for the last few years. So, I feel like we’re still learning and discovering how we can further specify our content for desktop and mobile users, and with the responsive site we have now, we’re actually able to learn even more and we will revise this experience even better.

We now receive a lot of concept mocks and low-fidelity type wireframes. What we found by doing this is that it’s actually sped up production.

Ethan:

Has your design process changed as you’ve started doing more device-agnostic work? As you’ve started working more responsively, how does that change the way you think about prioritizing information across different breakpoints?

Jeremy:

So, there’s been a lot more collaboration in terms of sitting with the designers at the time of putting together the layouts. We now receive a lot of concept mocks and low-fidelity type wireframes, which will demonstrate breakpoints. So, what we would expect from a designer in this new scenario is that we usually are provided with a detailed layout which may just be for the desktop experience, but all the other things that we need are given to us in a slightly different way, they’re given to us as more of a story of how the page is going to work. What we found by doing this is that it’s actually sped up production. Because we’re able to tell the story a little bit better of what we want and that the designers are able to not just provide detailed mocks, we’re able to work with the framework, the wireframe which sets the rules already for the style, and we’re able to put together the pages based on that information.

Joyce:

And I think especially in the beginning of the project, there was a lot of times where I sat beside the designer for hours at a time and we would just hack at little things together. We knew that if we could come up with a core component or a core library that we could use, it would make our lives a lot easier later on. And also I would create prototypes of page layouts and structures for the designers so they would have a chance to play on it with different screen sizes and maybe re-size on the browser to further revise and adapt their designs for the actual experience. I feel this wasn’t something that we did as often before the responsive project, and from this experience I actually got to know my fellow designer team a lot better.

Karen:

I’m always curious how organizations scope a redesign of this magnitude and perhaps plan a long-term rollout process. So, picking particular pieces of it or starting with a particular section, can you talk about how the scoping process worked for something of this magnitude? And did you have to pick and choose which pieces you were going to start with or roll out first?

Jeremy:

Yeah, that’s a really good question. Because this actually came as a request from the high levels of management, what we decided to do was to build the prototype first. So, it actually was an overview of the entire site, so excluding the landing home page, we built the search experience, the main search results page, and then we also rebuilt the details page of a property. We also recreated a lot of the content, such as graphs and charts and information that we would provide to a user, and we did that all within the responsive framework, and with that, that helped us to set expectations of what we would be building overall. So, we were able to break down different functions of the website and also create a mind map of what we wanted to build.

One of the things that we mentioned was to not bite off too much at once, because what we found was we tried to do too much at once and launch it all together.

Ethan:

Something you mentioned earlier was continuing to learn from this responsive design, and now that Realtor.com has launched, I’d be curious, have there been any elements of the design that you’ve reworked because you’ve actually learned something about how people are actually using the site?

Joyce:

For sure. I mean, we’ve definitely learned a lot this time around. We actually had a small retrospective yesterday regarding some of the staff that we got in January after the rollout, and we actually learned a lot of new things about how our visitors are visiting, what kind of engagement went up and what kind of engagement could be done better. And one of the things that we mentioned was to not bite off too much at once, because what we found was we tried to do too much at once and launch it all together, and instead, next revision, what we would be definitely revising is scale down the sections we’ve rolled out, that way we can get more feedback and then be able to revise better before we kind of push out the full experience to people.

We would also give feedback to our designers about the responsive flow and other components, where we try to find a balance between creativity and also the actual code weight and complexity.

Karen:

When you’re working across what you acknowledged earlier is a very large organization with lots of stakeholders, how did you review work in progress with the team? Given that the team members were reviewing a prototype, did that change the way that they gave feedback?

Jeremy:

So, on a regular basis at the end of each sprint, we would have a sprint review where the team would get together. We also would conduct demonstrations of each new feature that was completed during the sprint, and we would share the overall look and direction of the site throughout multiple teams. So it wouldn’t just be our own team looking at this, it would be other teams, and that way we could get feedback from others about any other additional ideas that we could add to the site or to see where things weren’t quite working the way that we thought they would be.

Joyce:

And because things were happening on the fly, we had other new features coming out while we were doing this responsive process, there wasn’t a lot of time where we could do very formal reviews. So, other than the sprint reviews that we did, during our sprint planning when we are looking at mocks and just breaking down the tasks to do, we would also give feedback at that time to our designers about, let’s say, the responsive flow and other components, where we try to find a balance between creativity and also the actual code weight and complexity.

One of the main focuses from upper management was actually page speed. It has to pass a certain performance goal before our task could be marked finished or done.

Ethan:

You mentioned weight, so I’ve got to ask about performance. A lot of organizations really focus on the aesthetics and layout of these new device-agnostic responsive designs—you know, they do the “squishy” thing—but how does Realtor.com talk about performance, how quickly it loads or how fast it feels when it’s actually in someone’s hand?

Jeremy:

So, we actually have an in-house performance team who specialize in actually looking into this. The one thing they have is a speed index and they like to look at how quickly things render above the fold. So they will conduct tests, look to see how we’re performing—actually against competitors, as well. They’ll set a sprint goal to make sure that when we’re creating the interfaces, that we’re building them in a way that’s going to actually optimize the load time.

Joyce:

Yes, and our performance team was a specialized team pretty much helping us and supporting us through this entire process. One of the main focuses from upper management was actually page speed. So, for every story or every task that we had to do, it was assessed for performance as well. So, it has to pass a certain performance goal before our task could be marked finished or done. So, performance was definitely a big part of the entire progress.

Karen:

Let me ask more broadly, how do you measure the success of a responsive redesign like this? Like, what kind of metrics do you evaluate to look at how well the site is doing, and does that change now that the site is going to be evaluated across all these different device types?

Joyce:

So, we gathered a lot of statistics from basic measurements, like user engagement by unique users. We also did a lot of click tracking, and also there was lead conversions, lead form submissions, as well as the number of return visitors. Since we did have a m-dot experience before, we did get a benchmark of what form of measurements we needed to meet, and with this in mind, our goal was not only to hit that benchmark but also to ask ourselves how we can exceed and improve above that.

Ethan:

Joyce, Jeremy, this has been fantastic chatting with you both. Before we let you go, however, I would love to hear if you’ve learned anything as a result of this responsive redesign that you could maybe share with our listeners. So if anyone is out there about to undertake a responsive redesign, what are one or two things you could share with them?

Jeremy:

So, the number one thing obviously is that mobile-first is important, and that you want to think holistically and have a mind map about where you’re going to go with the build. Try and visualize the elements and functions early on. And for us, having a prototype was a good idea. It basically allowed us to identify the pitfalls and approaches that we wanted to take early on, and it helped us with getting full support from all the stakeholders before embarking on the project. It allowed us to visualize and get people excited about the idea.

Joyce:

And I think it’s so important to have a good kickoff, as in what Jeremy just mentioned, getting everyone excited, making sure everybody is aligned. And I think when people are excited, they do a much better job.

Jeremy:

So, the other approach that we took is that we wanted to inspect and adapt throughout the project, make sure that we kept the site uncluttered. The philosophy was that less is more; if we can provide the core functionality to the user in a responsive way, then we can actually create the core experience and then iterate and adapt from there.

Karen:

Well Joyce, Jeremy, I have to say thank you for taking the time to come on the show today. I think your site is beautiful and it works really well, and I can tell that’s because you really put a lot of thought into it, so thanks.

Joyce:

Thank you for having us today.

Jeremy:

Thank you so much for having us.

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.