It’s not every day you get to redesign a product used by hundreds of thousands of people, virtually overnight. But that’s what happened when we launched Mercury Reader, a Google Chrome plugin for formatting articles into a clean reader view.

Once you install the extension—and you totally should go do that right now—any time you see an article that’s cluttered or weirdly formatted or showing all sorts of eye-grabbing clickbait and all you want to do is just read, man: click the rocket ship. Mercury Reader strips away all the excess and presents a comfortable reading experience. Mercury Reader is one of the three products in the Mercury Toolkit, a project created by Postlight Labs. And it’s powered by the (free!) Mercury Web Parser, which is also made by Postlight. After soft-launching last month, we’ve already passed 1 million downloads.

This is a behind-the-scenes look at the design process and what’s on our roadmap.

Rocketing off the couch

Mercury Reader is a complete, ground-up replacement for a different product called Readability. Postlight co-founder Rich Ziade recently wrote about the historical connection of Readability to Postlight and what makes the products different.

From a product perspective, this legacy meant I was designing for a product with a giant built-in user base that had been using the Readability Chrome extension for years — and for some users, using it every day since launch. I personally used it daily until we relaunched Mercury Reader. Their familiar red couch was going to become an unfamiliar rocket ship.

Mercury makes a clean reading view of web content, which is great for everybody. But a huge segment of our installs come from people who rely on tools like Mercury Reader for a number of accessibility purposes—from increasing the size of typography for low-vision users, decreasing motion and distractions for students, to reducing the amount of non-essential copy for screen readers, Mercury Reader helps thousands of users every day read comfortably.

I had to admit, while I was concerned about regular users, I spent a ton of time thinking through the needs of users for whom Mercury is a necessity.

I also was pretty lucky—Readability had been running for years. The team had done great work, and I had an excellent starting point. We were taking the knowledge poured into that design process and focusing the value proposition down to an essential mission: Reading on the internet should be better than it is today.

Landing on typography

Choosing typefaces for a project that relies so heavily on type was tough. It’s easy to get bogged down in downloading every font or trying all sorts of combos together. Using both Freight and Freight Sans as our main fonts was a pragmatic choice; they’re both sturdy workhorses that stay close in relative size to each other as body copy but are still eminently readable. And they look great when paired with something geometric like Avenir Next.

We considered having more granular options, like letting users scale both the text size and column width independent of each other, or mixing different typeface options together. But ultimately we decided to build an ideal reading experience that could satisfy the majority of all users and avoid an overly complex interface.

Here’s a few of the (many) iterations:

The Elements of Typographic Style says that the ideal length is anywhere from 45 to 75 characters per line, with 66 being the the gold standard. Many, many designers have found that could be applied to web with great success. (Who can forget Wilson Miner’s photo?!)

Early in my career as a graphic designer, I created layouts for daily newspapers and wall-sized graphics for museum stanchions that had to meet recommendations from the Americans with Disability Act. Much of this approach is what went into the original designers’ intent on Readability and informed how we built Mercury Reader: Think of a page at a natural distance from your eye, then get out of the way.

Framing the content into an isolated ‘page’ takes cues from the analog world, and lets that page “breathe”—with as little adornment or distraction as possible. We proportionally scaled the type up in size for users who prefer larger type and down for those who want more information density, and that worked easily to create the size settings. Users also don’t have to fiddle as much with the settings to find the a comfortable experience, unlike other Reader-like experiences.

A secret from our years of experience with Readability: the vast majority of users don’t ever change the settings at all, which makes the default choice that much more critical. It’s also why we tucked it away at the top of the page instead of having something omnipresent while scrolling. Once users get comfortable, they usually don’t need to change it again later.

It’s (not always) full of stars

A minimalist design that gets out of the way of the content is deceptively simple; things can get unbalanced pretty quickly if you don’t sweat the details. Luckily I work with a number of very talented developers. We tested using Zeplin and Invision Inspect to translate my Sketch files to get the right baseline working in the browser.

But for a productivity utility like Mercury Reader, you need to test in the real world. Trying out a variety of articles from across the Internet, tweaking animation styles and keyboard shortcuts, putting the Mercury Web Parser through its paces and testing in a variety of browser viewports and screen distances and settings — all of this was part of the work to get a version we felt comfortable launching to all our existing users as a beta test. (There was definitely some super last-minute hovering behind a developer’s shoulder nudging some line height two pix — no, one pixel — no, back to two, sorry sorry sorry lol I’ll go back to my desk.)

We launched! And we’re still not done! We’ve been hearing a lot of great, honest feedback from our soft launch. For the most part people are happy to have a tool they knew and loved back in action, running faster than before.

There’s more to build. We released a new version last week that improves compatibility with some screen readers, supports right-to-left languages, has better HTML5 video embeds and retina-ready icons. And we have more features in the works. ?

We’d love to hear from you on how to keep improving Mercury Reader; shoot us a line at mercury@postlight.com with your feedback.

A huge, huge thanks goes out to the Mercury Reader team: Nick Beattie, Jeremy Mack, Adam Pash, Neil Renicker, Frankie Simms, Toy Vano and the efforts of the all of Postlight in helping with custom parsers.