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, Karen and I are somersaulting with joy because we could not be more excited to speak with Naa Marteki Reed and Dan Munz from the Consumer Financial Protection Bureau. Marteki, Dan, thank you so much for taking some time with us.

Marteki:

Thank you.

Dan:

Our pleasure. Thanks.

Karen:

But before we get started, I’d like to say a few words about our sponsor, GatherContent. I am so excited to have them as a sponsor, because I just love GatherContent as a product. Pulling off a responsive redesign means wrangling lots of content and stakeholders. The editorial and migration process can be one of the most difficult parts of going responsive. GatherContent makes collaboration and approval processes a snap, with simple workflows and structured templates. It’s much better than the mess of Word documents, Excel files, and missing emails you rely on today. What’s even better is the API that takes your work out of GatherContent and into a prototype or your CMS. Managing the editorial processes in a responsive redesign is difficult enough, so make your team’s life easier, with GatherContent. Go to gathercontent.com and find out how this content collaboration tool can help you plan, organize, and produce your web content.

We’ve, to date, secured over ten billion dollars in relief for seventeen million consumers, taken over 650,000 complaints and, in general, we believe that you have a right to a consumer agency on your side as you try to live your financial life.

Ethan:

So, for our listeners who may not be super familiar with the CFPB, maybe one of you could just briefly explain what the organization does, and maybe then both of you could launch into a little bit of an introduction and tell us a little bit about what you’re working on. Dan, why don’t you go first?

Dan:

Sure. So, the CFPB is a government agency that was built to ensure that banks, lenders, and other financial service providers treat consumers fairly. It was created by the Dodd–Frank Wall Street Reform and Consumer Protection Act in 2010, and began operations really in 2011. And while it was created then, it really was created in response to the financial crisis that we saw from 2007/2008. And we’re a little bit of a unique organization in that, you know, having been created in the 21st century, we can really take advantage of modern technology in interesting new ways. We oversee really a lot of different parts of the consumer experience, so everything from mortgages to credit cards to student loans to checking accounts that are the products that consumers use every day to live their financial lives, and we have a really wide variety of tools that we need. We can enforce existing laws, we can write new rules, we can help resolve individual complaints, and we can collect data to understand and shed light on the market as a whole. We’ve, to date, secured over ten billion dollars in relief for seventeen million consumers, taken over 650,000 complaints and, in general, we believe that you have a right to a consumer agency on your side as you try to live your financial life.

Ethan:

That is fantastic, and it’s been really interesting to see the interest at the CFPB in terms of it going responsive and make it a little bit more accessible. But before we get into that, let’s maybe talk a little bit about how responsive design has been playing into your daily roles at the CFPB. So yeah, tell us a little bit about that.

Marteki:

I’m relatively new to the CFPB. I started in January of 2015, and it was wonderful to hear, when I first started, that the default assumption is that our mobile strategy is responsive design. That was just an expectation for any new projects going forward and also something we’re looking to do to improve our current site, which is currently not responsive on all pages, everywhere. So, that was just something that was great to get on the first go as you’re starting a new job.

As I’ve gone through, I think now I’m on my fourth or fifth project really, working now at the CFPB, that’s just been a constant there. It’s always the, “Okay, responsive design,” that’s an assumption that’s scoped in from the very beginning. There is buy-in on all levels, on the executive level all the way down for that, so it’s a constant as we go through our work.

Dan:

Yeah, and I would just say I think Marteki got it exactly right. I’ve been at the CFPB for longer, almost five years I was there until I actually left recently in July, but one of the things I’ve seen in my time there is a real shift from the idea of responsive or mobile versions as an additional business investment to a belief that it’s just the correct way to build web applications and to build products for the consumers we serve. And a lot of that really just has to do with numbers. While I was at the CFPB, they started a design and technology fellowship that brought just a number of amazing designers and developers into the bureau, and I think that really was the point where we started looking at responsive design as, just culturally, the right way to do any project we were embarking on.

It’s no accident that the places where you see our earliest ventures into responsive are the places where we were the most focused on providing just a really simple, usable experience.

Ethan:

That’s fantastic. I’d love to hear a little bit more about the origin story around responsive design at the CFPB. I think the first responsive project that I saw was the Spanish language home page, which I think is really beautiful work, and then I’ve seen responsive design roll out to some of the subsections of the site, like the “Owning a Home” landing page. I’d be curious to hear a little bit more about, like in some of those earlier projects, what the conversation around responsive design looked like. Were there any interesting discussions that had to happen with your stakeholders about why this needed to happen? Or were there any questions that came up about why responsive design might’ve been challenging as an approach?

Dan:

Kind of what Marteki was saying, I’ve really seen over time a change in the conversation. And when you look at our Spanish language site, I think that’s a good example of a project I was involved in where we were building the site and at some point there was a meeting where the developers said, “Hey, you know, we think we can pull of a mobile version. What do you think of that?” and, as someone on the business side of it, my reaction was, “Yeah, if we can get it into scope, absolutely.”

The default assumption of going responsive actually has acted like guard rails around the vision that we have for different products.

Some of the early projects you see that were responsive were very much the result of those kinds of discussions of, “Do we have scope to do it? Can we fit it into the time we have to deliver this product?” Because we still, I think, are, but then even more so we’re in a startup mode and really just focusing on delivery. And I think that the healthy thing is that over time, like Marteki said, certainly now it’s just sort of the default assumption. You almost just don’t have the separate conversation of, “Well, should we do a mobile version or not?”

I will say that I think it’s no accident that the places where you see our earliest ventures into responsive are the places where we were the most focused on providing just a really simple, usable experience. A learning I have is that those few things really go hand-in-hand, and more and more I think the default assumption of going responsive actually has acted like guard rails around the vision that we have for different products, where it becomes very very tempting to add features and take ideas from stakeholders. But you do that and then you go into a meeting and then you look at the mock-ups of a design or sketches of a design in the mobile version, and that constraint very quickly refocuses you on what you were really trying to deliver anyway. And so, I think that kind of moment… Really the story is just that that kind of moment has happened more and more as we’ve had just really more and more people in the building who think about responsive as just the correct way to do things.

Marteki:

I agree completely with what Dan said. In addition, he mentioned that it was something that has been really driven by getting new folks into the bureau who are looking towards that mindset and thinking about it as the right thing to do. We’ve also gone through and, as a result of that, to help those sort of discussions, we’ve started building some tools internally in order to decrease the time to delivery, in order to just make it better so that, as we’re scoping these projects out, that we can go ahead and include it within the scope.

The other thing about our work within design and development at the CFPB is that the majority of the stuff that we do ends up being open source and it’s freely available on GitHub.com. So if you go to github.com/CFPB, you can see a great number of our projects there.

Two major ones that you can see on there that we actually use in order to bolster our responsive design practice is our design manual, which is found in repository under that link, design manual. So it’s github.com/CFPB/design-manual. We also have capital framework, which is sort of a UI pattern library that we have to go ahead and help our front-end developers, help our designers better understand how things can flow across different screens, how they’ll flow out together; we can have things consistent across the entire site. There’s things that we’ve built internally in order to make sure that that practice of doing responsive design is actually as robust as possible.

One obstacle to responsive sometimes is that on the business side, when you hear someone say, “We should do a mobile version,” it’s easy to hear, “I want to make my scope twice as big.”

Dan:

I would just say I can’t say enough how important that is, because I think one obstacle to responsive sometimes is that on the business side, when you hear someone say, “We should do a mobile version,” it’s easy to hear, “I want to make my scope twice as big,” right? So, “I want to do this project and then do it again on mobile.” But if teams can invest time in the kind of things Marteki was talking about in building those frameworks… You know, I had teams start arriving to me and say, “Here’s the product and we think that we could really easily do the mobile or responsive version of this without a lot of additional scope or time,” and that just becomes a real pleasure to say yes to and to be able to support.

At the CFPB we believe that people are people and that we’re serving all American consumers, no matter where or how they choose to engage with us, and we want to go ahead and create an experience for them that will be as complete as possible.

Karen:

Sometimes what I hear organizations say is that responsive might be great from a design and development standpoint, or from an ease of maintenance for the team that’s going to be building and owning it, but what about the user experience? So, some organizations seem to wrestle with whether users that are “mobile” vs. users that are on a desktop computer need different things—different information, different transaction flows, just a different experience in general. Can you talk about how you describe the difference between mobile and desktop users? Or did you think that they needed different things?

Marteki:

I think that, in general, at the CFPB we believe that people are people and that we’re serving all American consumers, no matter where or how they choose to engage with us, and we want to go ahead and create an experience for them that will be as complete as possible, no matter how they choose to engage with us. So I think we go through and we have the ideas for this is the content, this is the type of experience that we want folks to go through, and then we look at it at the different screen sizes, think about the different devices, those kinds of touchpoints that people are going to be coming to us at, and saying, “Okay, do we need to make adaptations on the page?” in terms of how the content is presented, in terms of the UI, in terms of various different things. However, I think that we feel very strongly that we’re not going to give a reduced or more limited experience to folks who would be on a mobile device simply because they’re on a mobile device.

Make sure that you’ve thought deeply about what your actual users might need out of a mobile version, not just what the hypothetical mobile user on-the-go needs.

Dan:

Yeah, I think that’s totally right. I come at this from two different angles. I think one is just to say that I think as responsive has grown as a trend, I think we have a shared mental stereotype of what a mobile user is. If you think of it as stock art, it would be a young businessperson on-the-go, on the train to work, just wanting to grab quick information, like headlines or sports scores. But we did a lot of research into what kinds of moments people are actually having in their financial lives when they’re on a mobile device. A mobile user might be someone who’s actually sitting at the table with a lender, trying to make a financial transaction. From another project, we did ethnographic research that showed real interesting things about how low to moderate income users use mobile devices. So I guess one thing I’d say is that before you accept that answer, I think it’s really important to make sure that you’ve thought deeply about what your actual users might need out of a mobile version, not just what the hypothetical mobile user on-the-go needs or not.

But, you know, more broadly I think the thing I’d say is that, you know, for us it’s not that easy to get consumers to think of a four-letter federal acronym like CFPB as somewhere they should turn for help living their financial lives. And so if we do manage to bring them in through any of our various channels, like social or search, there’s a really good chance that’s on a mobile device and that’s really our first chance to make an impression and build a relationship with them, and so I think it’s really important to think about, from a specific product and feature perspective, what do you need to deliver on mobile. But more broadly, as someone who’s in the position not just of managing products but as building that relationship with consumers, the investment in mobile is really an investment in that, in the idea that when you first show up to them, you look right and good and trustable and not, you know, like a broken experience, because that’s what they’ll remember. And it may not be that they need your services right there on the train or wherever they are with their mobile device, but that’s what they’ll take away from that interaction with you.

When we think about mobile-first, we’re not just thinking about designing and developing mobile-first, we’re thinking that that might be the first place that folks are engaging with us.

Marteki:

Yeah, what Dan said. When we think about mobile-first, we’re not just thinking about designing and developing mobile-first, we’re thinking that that might be the first place that folks are engaging with us.

Dan:

And for us specifically, this is especially true I think in the financial sector, we saw a few weeks ago that in 2015 for the first time I think it was more people banked via a mobile device than went to a physical bank branch. And so, you know, more and more I think the likelihood is, especially for us but also in general, that the first time people encounter you, it will be on a mobile device.

We’ve even shifted and adapted and modified the way we work together because we see improvements in what we can do to put out great products.

Ethan:

One of the real limitations of the podcast format is enthusiastically waving my fist in the air doesn’t really carry across. So, uh, I love everything you guys just said. Maybe we could just jump ahead a little bit. You’ve got this laser-sharp focus on the needs of the mobile screen. I’d love to hear about how, if at all, your design process has changed as you’ve been moving further from the desktop. Maybe even specifically like what kind of applications and tools are you using to talk about and visualize a responsive design? Are you still using mock-ups or more prototypes? I’d love to hear a little bit more about your process.

Marteki:

We have a team that’s coming in with lots of different backgrounds, lots of different knowledge of what is out there and what is possible. We also have lots of different tools that we can use in there. Just in the course of my core project team that is, again, as I said earlier I believe, has moved between various different projects, we’ve even shifted and adapted and modified the way we work together because we see improvements in what we can do to put out great products.

Generally for us, however, we start with pen and paper and sketching stuff out, like the real basics of going through and looking at various designs, looking at adding Post-it notes in order to figure out interactions. And it’s graphic designers, the user experience folks, our content strategists, or even our front-end developers and our back-end developers get involved; it’s kind of a whole-team process. We’re constantly engaging with our product owners, as well, on this.

So starting there, with like the basics of pen and paper and “How could this work?” and “How can this move?” and “What is the information chunks that are important to bubble up and to give higher priority to?” We then generally shift into either rough wireframing in code or rough wireframing in a program such as Illustrator, then. And then as we continue discussing, continue talking, continue seeing what works, what doesn’t work, generally starting with the smaller screens but keeping an eye towards larger screen implication, then we continue building out the fidelity of either the code that we have that’s going to then roll into our actual code, or the comps that we have that will then be used in order to verify that the code does match up and it’s also for sharing out with our stakeholders.

We do a lot of talking among the team about our work; we do a lot of showing our work, also, both within the bureau and to external folks through usability testing and other means. And then we just go ahead and continue refining it until we get to the point where we say, “Okay, this is an MVP that we can continue to push out along the way.” But we always have the idea that there’s going to be continued improvements, that there is a road map towards future improvements that we can do.

Focus is a very hard thing to impose retroactively.

Dan:

And I want to just chime in on one thing Marteki said that’s so important, which is, as a partner and customer to this process, I’ve seen the team more and more start with just pen and paper sketches and have those pen and paper sketches include both what you’d think of the full screen and the responsive experience. And that’s so, so important because it sets from the beginning that design process and the way you’re thinking about the product has to accommodate both of those, and that’s really an evolution from a process that designs the full product first and then says, “Okay, what does this look like on mobile?” And that’s a lot harder to do, because that can often feel like taking away these features that you’ve worked so hard to build. Focus is a very hard thing to impose retroactively, and so it’s been really, really impactful to have it be the case that, even from the first case of “I drew this from a notebook, here’s the sketches version of product,” we’re looking at the desktop and mobile form factor side by side.

We are really seeing the value of moving from the smaller up to the large consistently throughout the entire process.

Marteki:

And that’s not always been true, even on the projects that I’ve been on. I think it has been a learning, particularly for my project team, about that. I think the first major project that we worked on, which was a planning for retirement tool, we started out with some sketches in mobile, then we quickly jumped to a larger screen. Then as we were going through and continuing to design and develop back down, we actually discovered that, “Oh, there are some major issues that are coming through here in some assumptions that we made about how things would work on the larger sizes that aren’t going to work so well on the smaller sizes, the medium sizes…” So, it was something that we’re able to do and try to work through without removing any of the functionality, without removing any of the content, with only some changes to the interactions that we were thinking on there.

It was also a learning experience for us as we’re going through, saying “Okay, now let’s try it for another project the other way and look at it from a different view.” On the current project that we’re on right now, we have taken that approach and it has just reduced the amount of heartache and amount of heartburn around that actual process there. So we are really seeing the value of moving from the smaller up to the large consistently throughout the entire process.

As far as the hierarchy of the content and what we wanted people to see first or not, that did not change depending on the type of device.

Karen:

Let me ask a similar question about how this process changed the content that you have on the site. Did you think about the editorial process or the priority of different content or what users wanted to read or learn from visiting the site? Was that different as part of this responsive redesign?

Marteki:

I think it’s something that we were thinking about no matter the screen. Because we went into it with the idea of we know it’s going to be across all the different screens, we were already thinking about like the hierarchy of the flow and what is important for people to see first as their eyes are moving across the screen. Then when we start moving across the different screen sizes, and perhaps instead of being on a narrow column, it starts shifting into multiple columns, it’s then still, okay, what is important for people to see as they’re going across the screen now knowing that perhaps their eyes are moving in a slightly different way? Or perhaps their mouse is moving in a different way, or perhaps their screen readers then are still going through and making sure that the tabs are working the correct way. So, those are all considerations there in terms of how we placed the content, then. But I believe that as far as the hierarchy of the content and what we wanted people to see first or not, that did not change depending on the type of device.

The editorial process is shaped by the assumption that we’re doing a mobile version, and so it really inspires us to say, “we have limited area, what are the things that they really need to know?”

Dan:

Yeah, and I think for individual products, that totally mirrors my experience, and I think, again, it’s been helpful because, you know, often in a policy context when you’re trying to give consumers information that they need to navigate the financial landscape, from a policy side you want to tell them everything, right? You want them to have all of the information they possibly can to make a decision. But we all know that it’s possible to have too much information and to be informed into a stupor.

I found in a lot of cases during the product development process, the editorial process is shaped by the assumption that we’re doing a mobile version, and so it really inspires us to say, “Look, these are all the things that we would love for a consumer to know, but when it comes right down to it and we have limited area, what are the things that they really need to know to get to this particular decision or consumer moment?”

I think that’s pretty well reflected, actually, in the retirement tool that we’ve been talking about. The considerations and the information that we have for consumers really are pretty simple and pretty tactical and that’s definitely in part a result of saying, “This is going to have to work on a variety of experiences, so we really have to do what we ought to do anyway and just give people the amount of information they need the moment they need it.”

Part of our thinking for our project team about our responsive design and development was not only across different screen sizes, but also across different languages.

Marteki:

Part of our thinking for our project team about our responsive design and development was not only across different screen sizes, but also across different languages. So, for example, for the “Planning for Retirement” tool in particular, we went ahead and made sure to include in our scope and talk to our product owner and said it would not be too much of a lift to include inside the scope having the tool fully translated over into Spanish content then, which then ended up meaning that that also entailed some tweaks to design to accommodate some changes that would come through from having the different language in there.

Now we have a tool that works not only across different screen sizes, across different devices, but also across two different languages, and that was an effort from user experience, graphic design, front-end development, and back-end development—in fact, our back-end developers were the largest proponents of making sure that that happened.

Dan:

And that’s an awesome example of how investments in these tools can really be helpful, because I think in a lot of organizations that kind of thing would’ve been a business case and memo-reviewing process. But in this case, the team was able to deliver that I think in less time than it probably even would’ve taken someone to write up a memo and circulate it about whether we should. And so that was really extraordinary to see, as well.

Something that’s really helpful is to have screenshots in there or have links to prototypes in there so folks can see in context what is going on and how the content will actually work.

Marteki:

And again, because we’re a federal regulator, our content and pretty much all our work does go through thorough reviews internally from our subject matter experts, from policy experts, from our legal department, then. As we’ve gone through, that ends up becoming a part of the editorial process, like that getting approval for content, getting approval for what is put out on the page that is going to be going out to the public.

Something that’s really helpful as we’re going through, if there are perhaps suggestions to add additional content or to change content a certain way, is to have screenshots in there or have links to prototypes in there so folks can see in context what is going on and how the content will actually work. It’s not dissociated from it in a Microsoft Word document or something like that—it’s part of one whole, the entire product.

Ethan:

I’d love to follow up just for a second on something Dan said at the end of his last reply, in terms of delivering information to people in the moment they need it. Is performance something that’s talked about when you’re actually designing a responsive site for the CFPB? You know, the speed of the thing, not just the layout and the aesthetics? And if so, how do you measure that, how do you talk about that internally? How does that shape the design process?

Marteki:

It is something that’s talked about. It’s an ongoing conversation to evaluate and try to improve our performance. It’s actually something that’s being looked at right now in the larger redesign effort that we have that’s covering the entire website, some aspects of the website that aren’t necessarily being touched soon otherwise, and the idea of looking at it and saying, okay, what changes could we make perhaps on the development or the infrastructure side in order to improve performance of the website? What adaptations could we make? What shifts could we make in order to just get content, get the information that we’re trying to share, get people access to the pages quicker, sooner?

Karen:

Let me ask sort of broadly about how you measure the success of these newly responsive sites. Like, do you still look at your analytics data through the lens of smartphones and tablets and desktops? How do you define what success looks like for a responsive redesign?

Marteki:

We’re looking at it through multiple different views. I actually have it open right now. So we do have it using Google Analytics right now, we’re tracking it with buckets that say “Mobile,” “Tablet,” and “Desktop.” We also have specifics around different OSes, different browsers, different screen sizes… So there’s lots of different ways that we could look at it and see, we’re tracking how people are going through.

We have some new tools within the bureau that are actually going through and doing heat mapping, so we can see if folks are going through and clicking and engaging with our pages in the manner that we expect them to. If it turns out that there’s a drop off partway through a page or that a certain aspect is not being engaged with, then we can recognize that.

In addition, even before we move to production, we are doing usability testing across all of our products; we are going through and engaging with folks who we think would go ahead and go through this page and are the right recruited base for it, to see how they actually go through and engage with the page without prompting, without anything where we’re going through and directing them where to go to on the page. And we’ve gotten a lot of insight from that, just within the projects that I’ve been in, that some of our assumptions, as always, for those of you who’ve participated in usability testing, you know that very often the assumptions you have at the beginning of the project are swiftly blown apart by the folks who are actually going through and engaging with the page, which is a wonderful thing. [laughs] It’s a terrible thing and it’s a wonderful thing, because it’s an opportunity to improve and make it better, and make it actually fit the needs of the people who are going to be engaging with it.

Going through and getting the entire team involved and engaged, and even widening your idea of the team. It’s not just the designers, developers, the writers who might be engaged with it.

Ethan:

Well, I’d love to hear from both of you about any advice you might have for our listeners who are about to start a responsive redesign. I mean, you’ve both amassed this wealth of experience at the CFPB. What’s something that you’ve learned in the course of working responsively that might be useful to others? Marteki, do you want to go first?

Marteki:

Sure. I think it’s really going through and getting the entire team involved and engaged, and even widening your idea of the team. It’s not just the designers, developers, the writers who might be engaged with it, it’s folks like Dan, it’s folks who are maybe higher up on the product level, it’s folks who might be tangentially involved with it, folks involved in infrastructure, folks involved in development that might be further away, inviting them in to share the designs with them, have them get a sense of what it is that you’re doing.

They will probably see, especially if they are engaged at whatever company you’re at and they believe in whatever company you’re at, they’ll see the importance of what it is that you’re doing; start asking questions then, and get the curiosity going, and the involvement and investment, even if they’re not directly involved in it. And I think building that attitude and that culture is something that is instrumental towards driving the culture of the importance of responsive web design forward.

More and more for organizations that want to “go responsive,” I think the smart investment to make is in doing those things that move culture and make it painless.

Ethan:

And Dan, what about you? Any advice for our listeners?

Dan:

Yeah, I mean I think what Marteki said about culture is incredibly important. I think the story of responsive at the CFPB is really instructive in the sense that a lot of times people think about responsive from the standpoint of “How do I build a business case for this, and how do I convince people to let me do a responsive version of a site, or take it responsive?”

But what’s been successful for us really has just been hiring enough people who come into projects with that assumption and build a process such that we’d have to make an active choice not to build a responsive version, and that choice is really hard to make even if you wanted to because rather than thinking about how this is going to be twice as much work, what you’re presented with is just immediately of a mock-up of what a mobile version might look like and immediately the framework to get us there relatively quickly. And so, more and more for organizations that want to “go responsive,” I think the smart investment to make is in doing those things that move culture and make it painless, and you’ll find that that’s an effective way potentially to shift the default assumptions and culture of the organization about how we develop products for people rather than spending a lot of time in this loop of “I’m trying to tell my management to let me do this but it sounds like a lot of work. How do I get them to let me do it?”

Karen:

Well Marteki, Dan, I know I can speak for Ethan here when I say we are huge fans of the work that you’ve been doing at CFPB, and it’s been a real pleasure to have you on the show today, so thank you.

Dan:

Thank you so much.

Marteki:

Thank you.

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.