When making the transition to building responsive websites, the hardest part can be getting started.

I get my fair share of questions about how to choose a direction and chart out the first few steps from industry comrades and potential clients. It can seem daunting, so I thought I’d attempt to sum up a few of my own current thoughts on the matter.

Consider RWD From the Beginning.

I believe this starts with a shift in perception. Whether massive or minute, this shift usually involves letting go of a lot of assumptions that center around desktop-centric browsing. There is so little that we can actually count on: mouse pointers vs fat fingers, hover states, screen sizes, connection speeds, device capabilities, etc. What good is initial planning (content strategy, IA, sketching, prototyping) without considering all of the variables the multi-device web provides?

If a team is knee-deep in .PSDs before considering layout changes and alternate viewports, opportunities for optimization and innovation will be overlooked. I’d rather proactively embrace a new approach than try to shoehorn an old one.

Benefits of a Lengthy On-Ramp

If I were on a team organized around fixed-width desktop-centric production I wouldn’t want to be expected to immediately start building responsive sites at the usual pace. Taking time to fiddle with devices, hack code, and perhaps most importantly, time to think pays off in the long run. Giving teams and individuals a cushion to get back up to speed after taking a new direction helps instill a sense of purpose instead of panic.

This cushion could be in the form of extra time for reading and research, extra time budgeted into a project, or even better, a responsive hack week project. Imagine teams of 2-5 that build a responsive site on any fictitious topic they want.

We had to uproot a lot of what we were used to at Paravel, and there are only three of us. Processes and roles will change. Not everyone will be delighted about these changes all the time, so ease in and give team members time to learn by doing.

De-compartmentalize workflows.

I’ve mentioned this before, but ditching the assembly line method of site building for a more communicative, iterative process will be helpful. Team members learn from each other (fatten those T’s) and arrive at solutions more quickly when they work closely. Rather than a more traditional design and development departmental split, why not create small teams with both design and development talent? That way, when someone has a good idea, it can be designed and prototyped without the hassle of multiple handoffs.</div>