Mobile-first responsive design creating an interface that addresses the constraints of mobile (small screen, low bandwidth, etc), then progressively enhances the experience to take advantage of available screen space, features, and more.
- A fresh start – A mobile-first responsive project is a clean start. Designers are excited to focus on core user and business goals. Developers are focused on lean, mean markup. By casting aside (or totally reworking) an existing codebase, teams can address our multi-device reality without having to worry about legacy overhead.
- Better support – By developing mobile-first, developers are able to support more mobile devices, especially older devices that don’t support media queries.
- Performance – While the performance of any site really depends on the implementation, a mobile-first responsive project gives teams the opportunity to address performance out of the gate.
- Concurrent Consideration – More broadly speaking, a mobile-first redesign (despite its name) tends to factor in the entire resolution spectrum rather than placing emphasis on any one device class.
- Future friendly – A mobile-first experience addresses creates more an opportunity to create a sound foundation that’s build to stand the test of time, and to serve as a platform for future growth and iteration.
- Time consuming – let’s face it, a mobile-first redesign isn’t a shortcut. It takes a lot of time and effort to build things from the ground up. The trick is to make the effort worth it.
- A mental shift – It’s challenging to get teams and organizations to think about things differently. The mobile-first mentality flips everything on its head, which challenges the conventions people have gotten used to over the years. This requires selling things through (thankfully there’s a book for that), and ongoing reminders to keep people from falling back into their old ways.
- Organizationally difficult – A big redesign is usually encumbered with all sorts of organizational red tape. The CEO wants to weigh in on the designs, despite not being in all the preliminary meetings on what all this responsive design hoobityboop is all about. Ambition and politics can get in the way of creating a user experience that looks and functions great on any device.
- Unfamiliar – Any redesign is going to be unfamiliar to users at first. But great care needs to be taken to maintain users’ level of familiarity with the interface, especially after going through a major overhaul.
A piecemeal responsive strategy breaks a large-scale redesign down into bite sized chunks. Like retrofitting (although in this case these strategies aren’t mutually exclusive), it might not be possible to undergo a massive redesign. That’s why some organizations take it a step at a time. There are few different flavors of piecemeal responsive redesigns:
Page by Page
Page-by-page responsive redesigns take a subset of pages . Companies like Microsoft have rolled out responsive homepages, while leaving the majority of interior pages desktop-only.
- Highly visible – rolling out a responsive version of most viewed pages (like a homepage) puts the effort where most users are likely to see the refreshed redesign.
- Learning to be flexible – Organizations often use these projects as pilots for broader initiatives. By focusing on a few core pages, they’re able to learn all that goes into making a responsive interface and then use that knowledge to apply to the rest of the site.
- Better chance of launching – Focusing on one page or one feature is a great way to make sure things actually get done. Redesigning the whole kit and caboodle at once could be a monstrous undertaking, which means it might never see the light of day.
- Continuity – User goes from shiny, new responsive experience to crappy legacy content a few quick clicks. This is bad from a consistency standpoint, as users view a company as a single brand, not as a hodgepodge of different departments and priorities.
- Short-sighted – a lot of page-based redesigns are so focused on “launching by Q3″, there often isn’t a game plan for rolling out the project to the larger site.
- Die on the vine – You have to plant a flag in the sand first and foremost with a strategy like this, or else risk permanently living in Frankenstein land.
Component by Component
I’ve worked with several organizations that are undertaking a rather interesting approach to responsive design. Instead of tackling the homepage first then moving onto interior pages, some organizations are making key components (like the header and footer) responsive, then slowly moving onto other components. When the whole interface is made responsive, they switch on the viewport meta tag and be left with a responsive experience.
- Gradually introduce users to a new interface– Instead of knocking users over their heads with an All-New, 100% Amazing Responsive Experience(!), this piecemeal approach introduces the new interface over a period of time. The changes aren’t so extreme that users will be angry, but move the design in the right direction.
- Break things down – Teams learn to solve problems at the modular, atomic level rather than focusing on the page.
- Gauge level of effort – Breaking things down into modules gives a better idea of the scope of the project.
- 50 Shades of Incomplete – This approach can be awkward as users are exposed to a Frankensteined interface that is both old and new, fresh and stale.
- Die on the vine – these types of projects need to have clear end goals or they could end up in purgatory forever.
- Technical co-existence – What happens when one module using the latest technology and techniques butts heads with an old crusty legacy module? There are lots of technical architecture challenges with this approach.