Introducing R2D2: The GiveGab Approach for Better Usability
The problem.
Below, is a screenshot of GiveGab’s old landing page and how it appeared on an average size desktop screen. Meh, not too bad.
This is that same landing page at 320px wide. Notice anything?
Yeah, we know. GiveGab isn’t responsive and this makes us sad.
Last fall, the GiveGab Design Team attended the FOWD (Future of Web Design) conference in NYC where we heard many presenters speak about the importance of responsive, mobile-first driven websites. That’s when we decided we need to do something about it. We need to make the GiveGab site responsive so that volunteers could have a better user experience.
Our team at FOWD 2013
A multitude of questions stood in our way like a giant wall between us and the solution.
Where do we begin? How do we convince the rest of the team that a responsive overhaul is important and necessary? How do we go about cleaning up and consolidating our CSS and javascript so that we improve our code quality? How long would a project like this take? How long should it take?
We needed a plan.
The solution: R2D2
Watch out. We’re bringin’ out the big guns.
We all know R2-D2, the lovable astromech droid from Star Wars, but for our own purposes it’s shorthand for Responsive Re-Design & Development. For us, R2D2 is a chance to improve our site’s usability. It’s a process by which we can tackle design problems and rethink our content.
R2D2, you’re our only hope.
Redesigning the entire front-end of a large-scale ruby on rails web application is going to be quite the undertaking (especially when there’s a lot of code cleanup and consolidating to be done). For our own sanity we’ve broken our process into phases.
Note: If you’re interested in the technical nitty gritty, by all means keep reading. Otherwise, just know that we’re working on making GiveGab a better, responsive and more user-friendly experience.
R2D2: Let’s talk details
Phase One: Research and Technical Decision Making
We were torn between two different front-end frameworks. Do we make the switch to Foundation 5 or upgrade to Bootstrap 3?
Both options are pretty baller and include responsive, mobile-first fluid grid layouts and a lot of reusable components making it easier and faster to code.
We chose to stick with Bootstrap. Truthfully, it came down to these two things:
1. Bootstrap has a larger community base
2. We have already customized a lot of Bootstrap’s UI elements
Don’t worry Foundation, we think you’re swell.
This is a great resource that compares the two side by side if you’re trying to decide.
We also decided to convert from HAML, to a different lightweight templating language called Slim. Why not? We could stand to lose a few pounds. Slim reduces the amount of syntax needed which in turn allows us to code better and faster.
If you’re converting to Slim with a converter like Haml2Slim, be aware that like many converters, it’s not perfect. It’s best to work in stages when doing a large conversion and carefully review your auto-converted code.
Phase Two: Plan. Plan. Plan.
Many of our users (and even some employees) have trouble navigating our site. We knew we needed to restructure our navigation and page flow to be more intuitive and usable. We started by taking content inventory.
Creating a content inventory will help you and your team understand what you’re working with and help you identify problem areas in your site’s architecture.
In order to better organize and restructure our site’s architecture, we held a card sorting activity with my team. Starting with our global navigation (the navigation that’s accessible from any page in the site), we wrote each of the navigational links onto separate cards. We laid the cards out on the table and structured them to reflect our current navigation.
From there, we started to consolidate similar navigational items into groups. For example, rather than having separate links for the “Nonprofits”, “Universities” and “Businesses” search pages, we grouped them into one navigational link called “Discover”. We also removed navigational items we saw were unnecessary and confusing for our users.
Luckily, we had results from a recent usability test and a lot of customer feedback that helped us make some major decisions around our information architecture. After all, a wise CTO once said, “there are no facts that exist within the building, only opinions”. Assumptions only get you so far. Conducting usability tests and tapping into your user base is essential during the development process.
We also planned a prioritized set of features that we will be redesigning over the course of the next few months. We found that this approach makes the redesign much easier to tackle.
Phase Three:Implementation
Our back-end team provisioned a separate heroku environment for R2D2 so that my team could work on the redesign without interrupting the work being done on the GiveGab web application. A separate environment, though needing to be constantly rebased against our web app, has proven to be very beneficial for now. We plan on merging in the redesign work once we’re finished with our first round of prioritized features.
We’ve already made some great progress with the redesign. Our landing page, at the top of the page, has received a facelift and is now fully responsive. We conducted an A/B test between the old and new landing pages and were fairly surprised by the results. After only 2 weeks of running the test, we saw that our conversion rates were exactly 91% better with our new landing page design.
Below is the new landing page design in an average desktop viewport.
This is what the new landing page looks like on an iPhone 5 and Droid Incredible 4G.
Currently, we redirect our users to our mobile website if they’re visiting GiveGab via their mobile device. It wouldn’t make much sense for us to remove the redirect now since only the landing page is responsive. Never fear. We hope to remove the redirect in 2-3 months once more of our site is redesigned and responsive.
Keep on the lookout for more updates about our R2D2 process. Until then, rock on!
