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, we couldn’t be more excited to be speaking with Michael Morisy and Allan Lasser, who are coming to us to tell us about MuckRock. Michael, Allan, thank you so much for taking a few minutes with us.

Allan:

Thanks for having us.

Michael:

Happy to be here.

Karen:

But before we get on with it, I’d like to welcome back our sponsor, Gather Content. I’m thrilled that they’ll be sponsoring this podcast for the rest of the year. I recommend Gather Content to my own clients who are going through a website redesign. Gather Content provides some much needed structure and editorial workflow to help manage a large-scale content creation process. Because Gather Content works with so many organizations going through a website redesign, they have unique insight into how content fits into a web project. And because they are such great people, they wrote down their advice for you! They’ve put together a 41-page guide to Content Strategy for Website Projects. Head on over to gathercontent.com/RWD to read their advice or download a PDF to share with your team. Thanks, Gather Content!

Ethan:

So before we dive in, maybe one of you could tell us a little bit about MuckRock and then tell us a little bit about your roles there. Michael, do you want to go first?

Michael:

Yeah, so I founded MuckRock seven years ago with a pretty simple idea: that it should be easier and more simple to get information out of the government. And so, we started off with a twenty-dollar WordPress template and the idea that we’d create this software as a service way to use the Freedom of Information Act. Now, the federal level and every state has similar laws: you have the right to get information from the government. Unfortunately, it’s kind of similar to filing taxes, there’s a lot of paperwork involved, you need to fax different agencies, you need to constantly follow-up and really know the law, know exemptions and that sort of thing.

Our idea was that if we made this process easier, we’d have more journalists using government records, we’d have regular public with a better understanding of what the government was up to, and we’d have a more transparent and accountable government. So, we basically created a software wrapper around a very messy bureaucratic process. Since then, we’ve helped file about 28,000 public records, we’ve released millions and millions of pages of government records, and we’ve helped break some really cool news stories for traditional publications, we’ve worked with a lot of digital publications, and we also work with a lot of independent people who want to know what their government is up to.

Allan:

Yeah, and I joined MuckRock back in the summer of 2014, right after I graduated from Boston University. I started focused on design aspects, HTML, CSS, JS stuff, and then that role developed over the next two years into sort of the day-to-day uptime of the site, and in addition to developing new features, working on different advertising campaigns and a whole bunch of other stuff that you have to do when you’re a really small team.

Ethan:

Well, that’s fantastic. MuckRock is a wonderful service and we’re both really grateful you could both be here to tell us a little bit about it. If we can focus a little bit less on the mission and a little bit more on just the responsive redesign, I’d love to hear how that actually came about. Specifically, given the audience you serve and the service you’re trying to provide, were there any concerns when you started this redesign about going responsive? Tell us a little bit about how it got started.

Michael:

We were a big believer in the minimum viable product approach to testing the idea in the first place, and it kind of was very minimal for way too long. I think by the time Allan joined us, we sort of knew that it was time for a refresh. We’ve always had sort of this very mixed purpose. We do a lot of our own original reporting, so we publish about thirteen or fourteen pieces of original news that our staff writes a week, but we’re also a software tool for our users, so it’s always been a very blended approach. I think we knew that we wanted our website to feel more like a web app, we knew that our website needed to meet our readers where they were.

In particular, Twitter is our single biggest driver of traffic, and so a lot of our traffic was mobile early on compared to some other news sites. We knew that when we didn’t have a responsive site, we had this sort of clunky, old WordPress template, it was a terrible experience on mobile and we really wanted to figure out how we could go mobile-first not just for our readers but also for our staff. I think one of the things is we’re a small team, a lot of volunteer labor, and if we can let people quickly handle stuff from their phones or from a tablet, it would make things move a lot quicker and we could better serve our customers and our users. So, we knew we needed to go responsive. We were a little overwhelmed because we had never taken on a project that was responsive at all, let alone something that had so many moving parts and so many constituencies. So, it wasn’t whether we thought responsive was a good idea, it was a question of would we be able to execute on that idea.

Karen:

Let me ask a little bit more about that whole mobile-first conception. One of the things that I often think about with people who are maybe journalists or they’re doing complex research tasks is that they tend to be sitting at a desktop computer. Can you talk about why either supporting a mobile-first mindset or being able to do things quickly on a phone was so important to you?

Allan:

Sure. So, the whole user experience of MuckRock really starts in the news side of it and then moves into first exploring the documents that are informing the reporting and then using the tool yourself to find more documents that may be interesting. So, we fully expected that a lot of our readers would be coming from social networks—and as that turned out, especially Twitter—and we needed a really good way to move those people from just looking at stuff on their phone to actually doing stuff on their phone. In the process, all the sort of valuable aspects of mobile design came to pass, where it helped us really focus the tool so that we could put the most important and the simplest interaction in front of the user, and then also, as far as looking through documents and experiencing that part of the site, where the most important information had to be presented first.

Michael:

Yeah, and I think for me, it came down to we saw where were journalists actually engaging a lot with their audience. So we’d have this conception that in newsrooms, people do sit behind desktop screens and that sort of thing a lot, but if you look at any reporter, they’re probably addicted to Twitter, they’re probably out chasing a story. That was something we were hearing a lot from our users, is that, hey, somebody’s at a city council meeting, they hear a city councillor mention a document, they want to file a request right from their mobile phone. Or, we’d even hear people would be out Friday night, enjoying things, they’d get an update on their public records request and they’d want to check it out right there on their phone. So, I think newsrooms are a lot more mobile than I think we give them credit for. I think a lot of times the decision-makers in a newsroom are behind a desk or are planning around a desk, and so a lot of newsroom CMSes that I’ve used are desktop-only. But we looked at our users and they were very mobile-centric already, and we really wanted to say hey, we want to reduce all the friction from thinking of, “Hey, this government document should be public,” to us helping you make that document public. So, really sort of thinking what was the core of the experience, how could we simplify it, was really key to undertaking this project.

Ethan:

How did that mobile-first mindset change your design process, Allan? Specifically when you were actually thinking about taking some of these complex workflows and making them responsive, how did you actually start to manage that scope? What kind of tools and applications were you using as a designer to figure that out?

Allan:

At first, we did a lot of prototyping on little paper cutouts that were the size of a phone screen, and actually when we cut those out, it was kind of striking how little space we had to play with. Once we had an idea of those interactions, we would drop them into—I use Sketch, which I find is really good for strategizing a design across multiple different viewport sizes. Then it finally came down to, once we had the basic framework and wireframe down, a lot of iteration in the browser. I find that I’m most comfortable working in the browser because the direct feedback of seeing a CSS change or seeing something in HTML refreshed makes that design process a lot quicker and means that we can get interesting results a lot faster. And because we’re using version control, we can sort of branch out and explore different opportunities without losing any state of the work.

Ethan:

Tell me a little bit more about that. Specifically, I’d love to hear, if you’re taking a little bit more of an iterative approach with releasing design or features, how do you actually learn from things when they’ve been released? Or just to really focus in on something: is there an example of something that you responsively redesigned, and then when it was actually out in the wild, you looked for an interesting opportunity to kind of revise it?

Allan:

Yeah, actually that describes the development of our internal task pretty spot on. Michael, why don’t you talk about the task system and how it worked before we implemented our own version.

Michael:

Yeah, so part of what we do is each week we actually have thousands of different government communications come into us. Some of those come via mail, we scan it in and upload it to our site. And then some of those come in as emails, and for a long time we had built a system where we treated an inbox like a to-do system and then it generated a bunch of URLs you could click in an email that was sent to somebody, and that person would have to go in and answer each email by clicking, “Hey, this email responds to a request,” “This email rejects a request,” and it was this sort of very long, complex manual process that had you jump in between a Gmail account and the back-end of the website. It worked okay when we were handling a few hundred requests. It didn’t work quite as well when we were managing tens of thousands of requests. So, one of the things we really wanted Allan to figure out was a better way of handling this.

Allan:

The way we started on that was basically, at first, recreate that inbox experience, provide people just basic links that they could use to take action. But after about a month or two, we came back to our staff and asked, “Okay, so when you go to this link, what information are you looking for the most frequently and what actions are you taking? Can you describe those steps to me?” Once we had that, we would put that on a whiteboard or draw it out on a piece of paper and figure out the information we had to pull out and display and the interactions we had to make really easy and obvious. The byproduct of this was that it was actually a great mobile experience because we were focused on these really core, meaningful interactions, and what that led to was staff members sitting on a couch and using their phone to take care of responses coming in or building a small Slack tool that would notify us when somebody raised a flag for moderation. Overall, I think what we took away from this was a process where it doesn’t have to even be fully functional to start, but we have to be very aware of how people are using it and build that into the product development process.

Michael:

One of the other examples that I really like was when the site first launched, as far as a frame of reference, we kind of looked at TurboTax. We wanted to be the TurboTax of FOIA requests, where it was a nice software wizard that kind of walks you through the process and helps you generate a request. So, we had a complex multi-path cue where it was like “Choose your own adventure” but for FOIA requests, and after you click through five or six screens, you get your request and then we file to the agency. What we forgot when we came up with this basic idea was that nobody actually likes TurboTax. So, one of the things I think Allan did a really good job of is helping us transition from that sort of wizard tool to something that was actually more like a GitHub clone and fork a request. I think that ended up taking that process down from a five or six-step process down to just two clicks, to sort of, “Hey, this is interesting information. I want to get it out of my government.” Bam, before you even realize what’s happening, you’re already requesting that information—but in a good way.

Karen:

Let me just follow up on your comment about understanding how people are going to use it and just ask about the content of the site in general. One of the things that Ethan and I have found when teams embark on a responsive redesign is that it often means that they re-evaluate either the content strategy as a whole or they take a look at all of the little bits and bobs of content and figure out if they have the right sizes or if they need to add additional descriptions or change the length of headlines or whatever. Did you run into questions about what actually you were publishing as you went through this redesign process?

Michael:

In some ways, I think there was some sort of—like, we changed the size of images and that sort of thing, and I think one of the things that we struggled to do is we had gotten into a habit of a very particular style and length of story. With the redesign, one of the things I really wanted it to do was sort of fit well for long stories, fit well for short stories. But I was very wary because I had worked at a number of other sites that sort of had, “Hey, here’s a short story stub, here’s a long feature story, and you need to do thirty different thumbnails to fit all different places that a story might appear.” We’re an incredibly small team, we’re about four people right now, and so I really wanted something that didn’t put too many constraints but was very flexible in terms of handling a variety of content types. So, I think it helped us get more flexible about what we considered to be a good story, like, hey, sometimes it’s just here’s some interesting documents we found, and other times it’s, hey, here’s a 3,000-word feature on Richard Feynman, and being comfortable with both I think was an adjustment, and I think the design really shines in making sure both of those types of content work really well.

Allan:

And just to share one other story that illustrates this process really well is we were—we still are, I guess—working on a project to index the different state-level public records laws. One thing that Michael was very clear about when we started was we should just start with a big text field and see what patterns we are developing as we start to detail these by both describing them in short summaries and detailing the law in more depth. From that, it worked really well from a database perspective as well as a content strategy perspective because we started with one big field and then we basically splintered off little bits of that as we found that we were being overly repetitive or starting to build a pattern. What that led to was a nice section at the top where we could detail the seal of the state in addition to the formal and informal names of the law, and a very short history of that law before getting into more depth that that larger blank text field would have accounted for.

Michael:

Yeah, I think one thing that we’ve tried pretty hard to do over the years is allow “cow-pathing” in terms of user design. We originally started where a lot of our articles were one-offs, then we started tackling bigger projects, and we have a flat page element that allowed just kind of throwing in whatever you want. So, we prototyped the idea of project pages, we built several of those over the years, and then once we had built six or seven of those, we had a really good idea of what they needed and required and what kind of features actually supported them working well. So, we went from manually hand-coding all those in HTML to turning those into an actual feature that now is open to all of our users. I think there’s been a lot of cases where we’ve always tried to say, okay, leave a general, flexible, big HTML blob space and prototype things with that before you start hard-coding things. Because I think every time we’ve rushed into a project with biases or sort of a certainty about what features would be needed, time and time again we realized that we had it entirely wrong, and all the features that we thought would be really important are useless or counterproductive, and the key features were stuff we never could have imagined. So, I think CMS features that allow for on-the-fly flexibility or let you embed stuff or try it out really has paid off for us.

Allan:

A large part of this, too, came from our lack of resources as far as user research went. I think one aspect of what Michael means when he talks about “cow-pathing” is that we do user research by giving users access to tools first and seeing how they use them rather than asking about hypothetical tools and how they might best benefit from using them.

Ethan:

Was performance a consideration that you had to design for at all? Specifically, were you talking about the speed of the site while you were actually making it responsive?

Allan:

Yeah, especially when thinking about the mobile experience on 3G connections/2G connections, people using the site on the subway or during their commute. We were able to reduce the weight of the site pretty substantially, especially on news pages, mostly by getting a lot of stuff out of the way. Then when it came to deeper elements of performance, like zipping files or really trying to minimize our file size, that came as part of that iterative process, where maybe not the first draft has that, but just putting it out in the world and seeing where the real performance constraints are and, in particular, relying on the staff to use the site as much as possible and then tell us where the issues come up, and being very agile and very responsive in terms of fixing those as soon as we find out about them felt like the right approach to us, even if there were some rough edges at the beginning.

Michael:

I think one of the things that worked well for us was, since we’ve started, we’ve never had advertising, so I think that gave us a lot of flexibility in terms of saying no to a lot of third-party trackers, a lot of ad networks. The site was never laden with third-party stuff, and we’ve really tried to minimize third-party trackers on the site since the beginning, and I think we got really serious a few years ago about minimizing that even further, and I think that made it so we had a lot of flexibility. We went to all HTTPS in 2012; we’ve always been sort of minimal in terms of how many third-party trackers are loaded up when you get on the site in the first place. So, we were able to kind of experiment, and it wasn’t as painful for us as I think it is for a lot of other sites, and I think particularly for other non-profits, you do have an opportunity here to make a choice that other people have a harder time making in terms of having a more performant site.

Allan:

And I also have to give credit to Michael’s cofounder, Mitchell Kotler, because I would work on developing layouts and sometimes they would be a little inefficient when it came to database queries and stuff like that, and he was always very good about giving me a second pair of eyes, looking at the amount of queries we were making, how we could collate those into more efficient requests, and really making sure that it was fast from top to bottom.

Karen:

Going forward, what kind of data or analytics are you looking at to track whether the site is doing its job, or what you might need to change in the future? How do you know if it’s working?

Michael:

We look at a few key things. We look at how many people are filing requests through the site, and that number has steadily been going up. We do a lot of user tracking in terms of how active are the people who sign up and use us to get information from the government. Because when we first launched, we had a lot of people say, “Oh, this is theoretically a really cool idea,” and they would sign up for an account and not do anything with it. So, we’ve been really focused on increasing the number of request files per user, as well as more qualitative things, like are we helping reform government programs, are the documents we’re publishing actually getting read by people and having an impact, are we raising awareness around an issue.

So, I think we kind of look at both quantitative and qualitative, but I think that one of the things with the redesign, especially the past two years, we’ve been trying to do is say, “Okay, if there’s a thousand people reading this article, we want to get maybe ten of those people to take that step forward and actually file a request and ask their government for something, and we want maybe a hundred people to follow somebody else’s request.” On the site, you can follow a request, so if there’s something interesting coming back from the FBI, you can sign up for notifications. It’s trying to create a funnel to better understand how can we help people—not everybody wants to file a request, but what can we do to engage people in this process that might not otherwise even have known that the Freedom of Information Act even exists.

Allan:

And going back to what Michael said and the idea of “cow-pathing,” I would look at the analytics as far as what pages people were visiting in succession and figuring out how we could make the second page that somebody visits as valuable as that first page. I realized that a lot of the top-level pages that people were navigating to from our navigation were pretty barebones and didn’t do a good job of telling our story or explaining the value of the work we were doing. So, I kind of took it upon myself to go in, revise those pages, and make sure that they were very clear about what they were doing there and what kinds of different content or stories or requests there were to be found within that section of the site.

Ethan:

Well Michael, Allan, this has been a really wonderful chat. But before we let you go, I’d love to hear if you have any advice for our listeners. If there’s anyone out there in our audience who’s about to start their own responsive redesign, what’s one or two things that you’ve learned that you’d like to share with them?

Allan:

I’d say that in the course of my time, one of the biggest things I learned was the absolute delight it is to work with Flexbox once you stop fighting against it, and the way that it can really help multiply the value of a responsive design if you design a component understanding the points at which that flex design breaks and the ways in which it needs to recompose. I think there’s probably going to be some new tech, like container queries, to push this technique even further. But thinking about how any given pattern or component or piece of a layout just works and behaves on its own, and then when you put them all together, you are saved from a lot of the higher level layout decisions because you made those earlier on.

Michael:

I don’t have anything that nearly insightful on the technical front. I think for me, this was just so much of a process of learning simplify, simplify, simplify. When we started MuckRock, and still today, I have sort of far-flung complex plans about all these interlocking features and the ability to do all sorts of complex data analysis. But I think the tools that really engage people and the tools that actually have an impact at the end of the day are things that are simple, accessible. People are busy, so any time you can make people’s lives easier and let them know, “Hey, here’s the next step you need to take,” that’s a huge win. I think with our move to responsive, we ditched so many features that were unnecessarily complex and that we thought made great sense, and then you put them in the hands of the user and it made no sense; taking this as an opportunity to come back and sort of simplify so many parts of our user flow and our internal workflow have been huge successes.

The last thing I’d like to say is, if at all possible, if you can not only make things easier for your readers or your users with responsive design, but also make things easier for your staff… Almost every news organization I’ve been at has had terrible staff tools, like the CMS will only work in Internet Explorer or you need to be on a desktop to post a story or something like that. One of the things that I was so impressed with Allan’s work was that he made equally great internal tools for our staff, and I think that’s made a huge, huge difference in terms of our productivity and general happiness.

Karen:

I think this was fantastic and I really enjoyed hearing you both talk about this story. It’s a fantastic example of how user-centered design and even something like responsive design can help make a tool that works for all citizens. So, thank you so much for taking time out of your day to come and talk to us on our little show here.

Allan:

No, thank you.

Michael:

Thanks 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.