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, I am like a little girl on Christmas morning. We have Maureen Sheehan and Paul Bellows from BC Transit. Welcome.

Paul:

Hi!

Maureen:

Hello.

Karen:

So, I’d love it if you two could both introduce yourselves, tell us a little bit about what you do. Maureen, why don’t you go first?

Maureen:

Hello Karen, hello Ethan, thank you for having me. My name is Maureen Sheehan and I’m the director of sales, marketing and communications here at BC Transit, and basically I’m responsible for the customer experience, including access to the web.

Paul:

And I’m Paul Bellows, and I am Maureen’s favorite vendor—at least when I’m in the room—and I’m one of the founders at Yellow Pencil.We’re a design and development firm that has partnered with BC Transit to help transform the digital experience. So, we created some of the design and the development for the website.

Karen:

We’re so happy that you’re here.

Ethan:

But before we dive in, I’d like to take a moment to mention our sponsor, Harvest. I’ve actually been using Harvest for years, so I was incredibly excited when they approached us about sponsoring the podcast. Harvest bills itself as a beautiful business tool for tracking time spent on client projects. I’ve worked with a number of teams who love it. They love how easy it is to track hours across projects, how beautiful and well-designed their reporting tools are, and I’ve heard from a lot of folks that I’ve worked with that Harvest really helps them stay on time and keeps their project under budget. Now, personally, just speaking for myself, I love its invoicing and expense management. I can update my projects in Harvest with my web browser, with my mobile device, and regardless of the size of the screen I have closest to me, it’s a real joy to use. So if you’re interested, you can check out Harvest at getharvest.com today. What’s more, after the free thirty-day trial, you can enter coupon code RESPONSIVE at checkout and save fifty percent off your first month.

From our perspective, responsive design was an assumption, not a request.

Karen:

So, I would love it if you could start off by giving us a little bit of background on the responsive work that you’ve been doing. Like, how did you decide to go responsive?

Paul:

Well, I think when BC Transit first made the request for the project, it wasn’t even really a question that mobile was the driver for everything because your customer is mobile, quite literally, in addition to how they interact. I think you’ve got, today, three quarters of your site visits are from a tablet or a smartphone-style device, and so that’s the dominant way that people are accessing, and the driver for the project was to go mobile and I don’t think you’d really considered anything but responsive.

Maureen:

That’s correct. So our customers are wide-ranging; we have a really wide customer base, from seniors that are used to using desktops to a lot of youth with new technology, and what mattered to us was creating a communication portal that was accessible anywhere, whether you’re in your living room, or whether you’re standing at the bus stop, or you’re at a restaurant wanting to know when the next bus would be. So from our perspective, responsive design was an assumption, not a request.

Ninety-five percent of your site visits are for one purpose and one purpose only. To a certain extent, there was no real difference between mobile or desktop, everyone was coming for the same reason.

Ethan:

I love that, Maureen. I’d love to hear a little bit more about that phrase you used, which was designing a website that was just going to work everywhere. When you’re looking at the needs of an audience that’s using a website in as many places as they currently were, how do you actually think about the needs of the mobile user and the desktop user when you’re starting to go responsive? Do they need access to similar information or did you find that their needs were actually kind of different depending on the device?

Maureen:

From our perspective, the main thing that matters is how do you get from A to B? So, we looked at designing the site in a priority method. So the main thing the customer wants to know is how to get from A to B, when to get from A to B, where should I start, what’s my route map? And then after that, there’s other priorities or uses that customers may have on the website, such as looking for corporate information or finding out about fares. So all these other pieces would be secondary in priority.

Paul:

In early research, we said ninety-five percent of your site visits are for one purpose and one purpose only. To a certain extent, there was no real difference between mobile or desktop, everyone was coming for the same reason. We needed to make sure we filled that primary driver first and foremost, on any device and for anybody.

Maureen:

That’s correct. The previous website had a lot of corporate information right off the bat, right in front of your face, and what we did with the new design was we moved all the corporate information into the footer. So when you arrive on site, the first thing you see is the trip planner, where is my schedule, the immediate needs of our customers who are planning a trip from A to B.

Because we’ve had to have some sort of a mobile site, this is actually less work for us because we’re just building one thing.

Karen:

Paul, I’d be curious to hear from you. How did you think about scoping a project like this, or a project of this magnitude? When you’re sitting down to plan a large-scale responsive redesign, is your scoping process different? Do you write a contract with your clients differently?

Paul:

Well, it’s interesting, I had a long chat with some of my team the other day, just saying, “In retrospect, we’ve done this. Let’s talk about responsive. From a cost perspective, what did it add?” It’s funny, because my back-end developers, the ones who did all the data transformation work to create the site, they said, “It didn’t change our work at all. We work in an MVC architecture, we do our back-end work. There’s absolutely no difference.”

And then I talked to the front-end developers, who said, “Well, you know, because we’ve had to have some sort of a mobile site, this is actually less work for us because we’re just building one thing.” I think the user experience team and content strategy team kind of felt like there was additional work. But again, not as much work as doing two separate sites, like building one site for mobile, doing all the design work, thinking about it in a whole separate site.

Thinking mobile-first kept us honest and didn’t let us cheat on the main site.

There was an additional load for our QA team, just because you’re testing; every time you make a small change, you have to test across everything. But again, at the end of the day, doing a responsive site costs less for the customer than doing a mobile site and a desktop site. We’re just doing more things.

The other thing that we loved is all of my team said thinking mobile-first kept us honest and didn’t let us cheat on the main site. So, thinking about smaller packets of data getting delivered, really optimizing JavaScript, just all the different little microtransactions that occur rendering a webpage. We started with mobile and then every other platform benefitted because we really thought about efficiency everywhere we went. Not only did it not cost more, but the whole product was better because we used responsive.

Ethan:

Paul, if you’ll just give me a minute, I’m going to try and get that entire answer on a t-shirt somehow.

Maureen:

[laughs]

We sketch fairly quickly to try and understand and try to build understanding with the client, and then we have to model and prototype as fast as possible to really validate those ideas.

Ethan:

That’s a wonderful way of thinking about it. And not to put you on the spot, but I’d love to hear a little bit more about the design process that you used to start actually fleshing out the look and feel for BCTransit.com. I know Yellow Pencil’s done a significant amount of responsive work in the past. How has that changed since you’ve started doing more multi-device work for the web?

Paul:

This one was interesting because there’s sort of two parts to the site: one is that it’s a content site, but also it’s sort of a rich Internet application, because littered throughout the site are all these functional trip-planning, wayfinding, and mapping interfaces. So it’s funny, when we started, Maureen said, “You think you understand transit, but you don’t understand transit.” I said, “How complex can it be?” She was right. Transit data is really complex, and there’s a lot of data, and what appears simple is never really simple.

Sketching rapidly and then going direct to prototype, that for us has been just the only way to work with responsive.

There were sort of two parts. There’s all our preliminary research and understanding and the work of content strategists, inventory and audit and message mapping and things. But really, I think what came together for us and where we’ve evolved, we sort of go sketch to code now really quickly. So, we sketch fairly quickly to try and understand and try to build understanding with the client, and then we have to model and prototype as fast as possible to really validate those ideas and so we can start to look at something and work together. So when we come back and workshop wireframes with Maureen and her team, we try and get in a room together, or at least online, and we really look at these functional prototypes and look at them at different breakpoints and just talk about how it’s going to work and what’s important, and what would the CEO think of it and then what are riders going to think of it, and all the different audiences.

Sketching rapidly and then going direct to prototype, that for us has been just the only way to work with responsive. Especially when we get into these more complex applications, we really needed to think about, “What can you see above fold and below fold? And will users see enough of the map to be able to navigate? And is there still content they need to see while they’re navigating through the map?” So, that really let us have the real conversations and really understand each other quickly. I don’t know if you’d agree with that, Maureen.

Maureen:

Absolutely.

We did our own session internally and came up with what we thought the content priority was. Then we came on-site and replayed the same exercise to hear what you thought.

Paul:

The other thing that we did that I thought was a really neat exercise is our UX and content folks, when we came to the content prioritization. Because BC Transit is government and we all know government can be political, we did our prioritization of planning on our own. Normally we say, “Yeah, we always collaborate” and everything, but we did our own session internally and came up with what we thought the content priority was. Then we came on-site and replayed the same exercise to hear what you thought, and then we compared notes to sort of say, “How does not-BC Transit see BC Transit?” so we could get a real nice comparison of what we outsiders think and then what do you think, within the world of government, being a Crown corporation. So that was really neat to be able to have that conversation and contrast and compare and just have those meaningful conversations about content priority.

How do you marry the needs of the customers with the requirements of a large government organization?

Maureen:

There’s a few things that you need to think about since we are a Crown corporation, so there’s government requirements that we have to have accessible on the web. But really we’re a transit company and our customers primarily are people riding or moving from A to B. So how do you marry the needs of the customers with the requirements of a large government organization? And what Paul and Paul’s team created for us with the quick trip planner when you arrive on the site and then moving the bulky content to the footer has worked perfectly.

We want to work using the cheapest possible products, because the more we put into production values at that point, the more we’re just slowing things down.

Ethan:

That is a wonderful overview. If it’s not too in the weeds, I’d love to hear a little bit more about that sketch to prototype transition, because I think that the one thing that I didn’t hear, which is something that I think a lot of organizations struggle with, is the role of more traditional design applications, like Photoshop or Illustrator. Paul, maybe you could tell me a little bit about the applications and tools your designers were using on this project to actually start thinking about the design of the site and when that actually sort of snapped into the prototyping process.

Paul:

Early on, we actually sketch with pencil and paper, and we just think it’s a really fast way to move, it’s low-fi, it lets us have conversations and share things. Sometimes that stuff will get bundled up into a slide deck, a PowerPoint, and then we get to have quick conversations with the client, really just sort of narrow into: what kind of conversation are we having here, what are some of the broad ideas. We want to work using the cheapest possible products, because the more we put into production values at that point, the more we’re just slowing things down.

Our secret technology weapon is reasonable conversations.

Then as soon as we have the shape of it and the baseline of the main interaction patterns, what’s possible, what’s not, “This is going to be a sticky issue, we can’t make this recommendation for whatever reason”—as soon as we’re past those initial hurdles, then usually we’re using Foundation. That’s sort of our team’s general tool of choice, and we’ll actually start prototyping in-browser wireframes immediately in Foundation so we can start to really look at how this thing is actually going to work and understand it.

Static wireframes are useful for documentation as an artifact, but they don’t really help you to make decisions as you move forward and they don’t really build understanding. Then I always say our secret technology weapon is reasonable conversations. So, it’s really us all looking at it, understanding the same thing, pointing at it, moving it bigger/smaller, and then just talking about it and really making a decision for what’s best.

We decided what the persona was and then we thought about which type of information they would be interested in having, what would that content look like.

Karen:

Paul, I want to follow up on something you alluded to earlier, which was how content strategy fits into your process. Can you, and Maureen as well, talk about how the content strategy, editing, revision, structuring process intersected with your responsive design and prototyping process?

Paul:

Do you want to start this one?

Maureen:

That’s a big question. When we first started the project, we had pages and pages and pages of content and we knew that we needed to make the website more accessible and quicker to use. How could we do that on a smaller screen or a larger screen? What was the best method to move forward? We worked with Paul’s team; Paul had a content strategist and I had a content strategist on my side that used user personas.

We decided what the persona was and then we thought about which type of information they would be interested in having, and how we would set up the screen or how they would like to be able to access the data, and what information they would like to access and what would that content look like. So we had these two folks create four, five different personas, one from Paul’s site’s team and one from my site’s team, and worked through the content that way.

Paul:

In terms of how it intersected with the actual interface design process, this is where knowing a little bit about how BC Transit actually works and how unusual they are is helpful. So they are in the province of BC, which is 1.5 million kilometers, or about a million miles—they govern transit across the entire region, and they work with operators in each region and they have about just over sixty transit systems, am I right?

A big part of what we had to think about was content author interface in the CMS. How are we going to make this site something that real humans can manage and that’s hard to break?

Maureen:

Correct.

Paul:

They basically run sixty separate transit systems. So the content authors for the site were going to be partly centralized staff working out of BC Transit but also city clerks, people doing work off the side of their desk, administrative staff, the transit authorities distributed across 130 small municipalities and large municipalities across the whole province.

A big part of what we had to think about was content author interface in the CMS. How are we going to make this site something that real humans can manage and that’s hard to break? Again, one of the secret weapons for us was content modeling. That’s really where the wireframe and the content structures really started to come together. We started early, prototyping the CMS and understanding how we were going to build this, thinking of how there’s a lot of content sharing across the site, so we had to think about what does that interface look like, how to make people successful.

There were a lot of conversations, so the design process started with the external side of the site, and then as we started getting to the actual functional build of it, rolled over into the CMS design to say, “Real people need to be able to manage this and need to understand the content structures.” It was really going from front-side, what we desire for design, and then really making sure it was tightly aligned to the actual content that was needed, and then all the way through to, “How is that content going to be managed through the life of the site?” Because if we’d have done that wrong, we would have launched something that would have looked nice but it quickly would’ve fallen apart, and that hasn’t happened.

What we started with was a very complex content requirement, and the work that we gave to Paul was, “How are you going to build this for us in a responsive way that works for our customers?”

Maureen:

Paul’s making a great point. Let me just add to that. You take our systems across the province—you’ve got Victoria, Nanaimo, Kelowna, Vernon, Fort St. John—just a number of cities in the province. In each of those cities, you have a transit organization that we’re responsible for. So you will have detours or bus breakdowns that happen in different cities all across the province, and in each of those transit authorities, someone will need to go into the content management system and upload an alert or something so the customer knows there’s been something changing to their transit route for the day. To be able to access that from a large corporate site, so you need to land on the BC Transit site and it will take you directly to your location, Fort St. John, and when you arrive there, if there’s an alert, you will see that immediately as well as have information about how to get to A to B. What we started with was a very complex content requirement, and the puzzle and the work that we gave to Paul was, How are you going to build this for us in a responsive way that works for our customers?” So, we gave him a big task.

Paul:

And then I gave it to Alaine and Phil, who actually solved the problem.

Maureen:

[laughs] So when you arrive on the site now, we have…

Geolocation. You can do that when you’re standing at the bus stop on your mobile phone or you can do that sitting at your desk.

Paul:

Geolocation aware.

Maureen:

Geolocation. We’ll find out which transit authority you want to get your schedule from and where you want to find your alerts, and you can do that when you’re standing at the bus stop on your mobile phone or you can do that sitting at your desk before you’re about to leave work today and decide which bus to catch.

We were quite successful with our steering committee, and this also helped us through the political process.

Ethan:

One thing I’d love to hear a little bit about is how you managed reviews of the site as it was being designed with the rest of the organization. I mean, especially given how prototype-focused the design process was, did you find that other people outside of the actual core design team were comfortable looking at this on different devices? How did you gather feedback? I’d love to hear a little bit more about that process and how it was structured.

Maureen:

Thanks Ethan, I’ll take that one. So, we had put together a large steering committee, which had a number of different people from across the province, from across the agencies, as well as outside organization—community members, members from social groups—would meet with us once a month, and Paul’s team would present where we were, they’d show us the artwork, they’d show us the design. We would have questions about which stage to move to now, how is this working from an accessibility perspective, and that feedback would then be admitted and go back to the project team.

We were quite successful with our steering committee, and this also helped us through the political process. So with, “Did you have buy-in? Have you communicated with your customers?” we had a member of the largest student union body there, from the largest university, sitting at the steering committee table, looking at the design, understanding why we were making decisions certain ways, and hearing about any types of limitations that could be coming from the back-end work we were doing.

Paul do you have something to add?

It’s hard to argue with: “Our users love it.”

Paul:

The only thing I’d say is I thought the steering committee approach was brilliant and your team managed that well, and that meant when we were sort of selling up the chain internally in the organization. It’s hard to argue with: “Our users love it,” and that was the way the message came. We listened to people we heard and that was, I think, really successful; I thought that was a really well-structured process.

Very few angry Tweets. People like to Tweet at transit authorities, and there was very little of that.

Karen:

Let me follow up on that and ask just sort of broadly, how do you know if this responsive redesign is working? How do you evaluate the success of the site? What sorts of research or data or metrics do you look at to see if it’s performing the way you expected it to perform?

Paul:

First of all, very few angry tweets. People like to tweet at transit authorities, and there was very little of that. I think the media actually said nice things.

Maureen:

Yeah. We did a—and it’s still ongoing right now—we have a survey that people can fill in, and of course we have questions about the web, or comments about the web, there’s a link that you can go to.

By the time it went to launch, there’d already been significant conversation that the new website was coming and that this was how you could provide your feedback.

Another thing that we did, Karen, was that we launched this in the test environment, to the public, three months before we launched live. So, we were running our old website and a new website in parallel for about three months. We did a lot of media around the launch, requesting people to give us their feedback and to fill in the survey and to test the site out, and that allowed us to get some good customer feedback, some buy-in with the public that we were working on something that we were thinking about what they had to say. So by the time it went to launch, there’d already been significant conversation that the new website was coming and that this was how you could provide your feedback.

We do a lot of analytics to just make sure that we understand how people are using it and that we’re getting the right results.

Paul:

We also look at really empirical sources, like Google Analytics and site usage. We were looking just today at how people are getting to content. Are they deep linking it from search results, are they spending less time on the site in the right places? So, just improving the way people are working the site. We do a lot of analytics to just make sure that we understand how people are using it and that we’re getting the right results.

If you’re building a website, focusing on your priorities: what’s your primary function of the website, and make sure you hold that up front and center.

Ethan:

Paul, Maureen, I have to say, this has been an amazing conversation. I’ve really enjoyed hearing a little bit more about the site and how it got designed. I guess, as we draw to a close, do you have any advice that you might be willing to share with our listeners, if there’s anyone listening today who’s about to embark on a responsive redesign? What have you learned during the redesign of BCTransit.com that you would love to share with them? Maureen, do you want to go first, maybe?

Maureen:

Sure. From my perspective, you’re going to have all kinds of stakeholders with all kinds of wants and needs, and if you’re building a website, focusing on your priorities: what’s your primary function of the website, and make sure you hold that up front and center, and then ensure that you have a way to communicate the changes that you’re making to create buy-in going forward. From a website perspective, especially for us, our key audience are our customers, so improving the customer experience and ensuring that people knew that we are engaging with the public and engaging with the customers and we’re not creating in a black hole, to me those would be some key advice that I would give. It certainly helped get buy-in and get approvals and get funding when people saw that we had buy-in and that we had done extensive consulting.

You can’t have everything, because we’re serving very small screens and a very concise area. You have to make compromises and you can’t have everything.

Paul:

I think for me, my advice is sort of twofold. Again, I don’t think you can focus enough on starting in the most agile and conversation-driven way, because it’s those meaningful—start with the cheap tools, start by sketching, move quickly, sort of narrow in. Because I think if you try our old approach, years ago the agency would disappear and would come back with some impressive-looking discovery documents, and then disappear and come back with a beautiful design that was presented in Photoshop, and then a TV screen in a boardroom and, “Here’s the design,” and then would go away and come back with the finished product. Where that fails in responsive is you need to make a lot of decisions with the experience. As you were saying, Maureen, you need a lot of priority-driven decisions all the way. You can’t have everything, because we’re serving very small screens and a very concise area. You have to make compromises and you can’t have everything. And so, that requires a lot of conversation, it requires starting small.

Starting in a light way, using less expensive tools, moving quickly to design, you can focus your budget on testing and QA.

The other benefit is starting in a light way, using less expensive tools, moving quickly to design, and sort of maybe a little less reverence for the traditional design/big reveal approach is you can focus your budget on testing and QA, because releasing a big site, especially a site like this that has a lot of rich Internet application, like a lot of interaction that’s a part of the site with all the mapping and the wayfinding and the Google Transit integration, dealing with a multi-device world…

You need a huge QA process just to make sure you get it right, so you want to save a lot of time there.

You know, it’s no longer we’re testing on four browsers on Windows and Mac and maybe someone has a Linux machine somewhere. We’re really dealing in a very complex world and we’re going to find a lot of problems because browsers are built in very different ways on different devices. Supporting BlackBerry users, supporting various Windows users, the Android community, there’s just so many different articulations of browsers and devices and screen sizes and rendering engines in JavaScript. You need a huge QA process just to make sure you get it right, so you want to save a lot of time there.

You win more with the actual build experience of the site rather than just creating a design that wins in the boardroom. The real world, rubber-meets-the-road work is where it makes the difference.

And then just the ability to optimize in that phase too, just improving the mobile experience and the load and performance, making your JavaScript more efficient, making your CSS more efficient, your data loads more efficient—all of that, there’s a huge opportunity to improve there. You win more with the actual build experience of the site rather than just creating a design that wins in the boardroom. The real world, rubber-meets-the-road work is where it makes the difference on a site like this.

It’s really important to have a training plan to train your team that’s going to be updating the site for content.

Maureen:

Another thing I’d like to add is that it’s really important to have a training plan to train your team that’s going to be updating the site for content. It was really important we were provincially spread across. How could we teach all the different operating groups how to use the system and make it valuable for the customer, make it easy for our content group to upload information? We put together a training plan and a training schedule, and we went back and went through it a number of times, and that just increases ease and confidence. So I think between the QA, the prioritization and the training, plus a good consultation process, you’ve got what you need.

Karen:

Well Maureen, Paul, I’ve got to tell you, I am a huge fan of public transit, I am huge fan of Canada, so it’s probably not a surprise that I am a huge fan of both of you. This has been really delightful. I’m really impressed with the work that you’ve done and I’m so happy that you took the time to join us today. So, thanks.

Paul:

Thank you.

Maureen:

Thank you. I’m really happy to have had the opportunity. Thank you for inviting me.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, Harvest. Go to getharvest.com and start tracking your time, painlessly, today.

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 also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near 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 podcast episode at responsivewebdesign.com.

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