Responsive Overhaul at Bloc

When Bloc was young, we focused on iterating the product until we found the right fit. We consistently asked ourselves, "What's the fastest, cheapest, nicest way to figure out if we have the right product market fit – all on the budget of a small team?" As you might guess, in the fast, cheap, quality triangle, something has to get cut. And sometimes, that was quality.

One thing we cut was responsive web development. A few pieces of the product were mobile-optimized – landing pages, some product features – but many were not. But we got by for a few reasons: the amount of mobile visitors we had was low, and the nature of our product necessitates that a student uses a desktop computer. Today, professional designers and developers don't code or design on a phone or tablet (yet) – so it worked.

However, in 2015, we doubled our staff, multiplied our user base, and settled on a product direction. And, two events were on the horizon: Google was taking mobile-friendliness into its SEO rankings, and we were overhauling our UX/UI Program. Both of these offered an opportunity for us to get responsive design really right.

Research + Stakeholders

So, I made a pitch for doing a responsive overhaul across the entire site. I had to show that this was a problem worth solving, get multiple stakeholders on board, and show how we could solve it, and solve it well.

To show that this would have a positive effect for growth, I looked at qualitative and quantitative data and asked some hard questions. How many visitors to our sitewere impacted by a poor mobile experience? Where were our visitors coming from? Overall, with the opportunity to increase our SEO ranking and acquire a greater amount of visitors from mobile advertising, we had a compelling argument.

And then I found an argument for product. I scoured past user interviews and support tickets for keywords related to product usage. I cleaned up the data, and found a small but robust sample of feedback pushing for mobile friendliness. We found some pretty revealing behaviors – particularly that our users often read the site on the go to review material or get started before at their desktop. We also found that students wanted to message their mentor easily via mobile – for last minute reschedules – and this seemed like an excellent opportunity to improve that user experience through mobile-frienliness.


Next, I asked HOW we could solve this problem, and how we could launch this in a piece-by-piece manner. I created a sitemap with every page layout, rating each page red, yellow, or green to show how mobile-friendly they were. The rating criteria was based on Google's responsive design tool, which included simple usability and development guidelines. Green was good: there may be some polish needed, but the page was mobile-friendly. Yellow was a warning: the page was close to mobile-friendly, but had clickable areas that were too small, cut off images, or a sloppy presentation. Yellow pages were visually messy and technically messy. Red meant the page wasn't mobile friendly.

After sharing the breakdown with stakeholders and discussing multiple plans of attack, we agreed to fix growth-related pages first. We'd revamp landing pages and marketing material first because of the looming Google SEO deadline and the higher percentage of visitors that visit on mobile. Then, we'd tackle the product on a feature-by-feature basis. We started revamping the highest impact pages (where the most users went, homepage and fst page) and then tackled the easier, lower value pages.

Wireframing + Visual Design

Luckily, a lot of our pages were initially designed mobile-first, so adapting those layouts wasn't particularly difficult, but it required a lot of design+dev pairing for a few weeks. For pages that were pretty old and never designed with responsive in mind, I had to do a complete overhaul. I'd take the original page, wireframe out the content, and do mobile-first design tweaks that got the page similar to the original, while still being mobile friendly first and foremost.

The biggest problem was the navigation: site wide, it wasn't ready for mobile, and needed some serious clean-up. A fellow designer, Sanny, came up with an elegant solution that seemed usable and prototypes it in HTML.

Usability Testing

Once we brought a page up to "good", we'd run it through Google's responsive design grader and Browser stack to see how it rendered on multiple devices. We also brought it up on a simulator for iOS since it constituted the majority of our mobile visitors and tested in person with multiple iOS and Android devices. From there, we made tweaks, and reassessed.

Final Solution

Our first round of responsive revamp launched a week before Google's SEO ranking change took affect. It included the majority of our external pages, and it didn't affect our ranking. And, over time, we saw our visitors to mobile increase by a certain percentage.

Our second round of changes for the product launched in stages, each tacked on to a larger project. First, we launched a redesign of our checkpoint legibility. Anecdotally, we saw a marked increase of feedback from students, thrilled that the checkpoints were responsive. Over time, we tackled the student roadmap and account pages in larger projects. (You can read about one of the roadmap revamps here.)

Next Steps

We now design mobile-first, but we still miss a lot of nice polish and micro transitions. Growth is fine, but product really feels like a webapp that's responsive rather than a native app. Some functionality could be done much better. I think the next step would be native apps for select functionality – messaging, for instance.

We still have a few pages that aren't mobile-friendly. They're incredibly complex, low return items, but it galls me to believe that we still are not entirely mobile friendly.