Great web projects don’t succeed on good design or development chops alone. Communication and collaboration among both designers and developers is just as important.
I’ve seen firsthand otherwise solid designers and developers botch a project just from miscommunication. And those poor relationships persisted beyond the life of the project. I’ve also seen novice designer-developer teams work in unison and deliver amazing results. They resolved potential pitfalls early, delivered their projects on time, and iterated quickly. Coordination isn’t just for projects either; a well coordinated team is a happier team. There are less misunderstandings and less tension if tasks aren’t going as planned.
The collaboration between design and development teams becomes critical in responsive web design (RWD) projects. There are now many devices to account for. Fixed, “pixel perfect” design is exchanged for fluid ratios and proportions. There are also extra image assets to optimize for different device sizes and resolutions.
In short: with RWD, there are more variables, more deliverables and more obstacles. Here are several techniques to overcome these hurdles in any RWD project.
Most designs start from a static perspective. You pick a viewport width and height, then sketch or mockup from there. What do you focus on first with the dev team? What should be the first high-fidelity deliverables to hand off? Which devices get considered early for technical constraints?
I usually recommend to start designing with the smallest and largest common device sizes. When in doubt, base your range on general 2015 web analytics. 320px by 568px, the iPhone 5 in portrait, is a good choice for the small end. Apple’s older flagship is still popular yet small compared to other modern smartphones. For the large end, I like 1600px by 1000px, the size of a large browser on a desktop. Your audience may be different: skewed more towards mobile devices or desktop/laptop users. Check your analytics and change the range as appropriate.
You’re forced to make hard choices when you start with the smallest viewport size. You have to decide on the most important features in your design due to limited space. With the large end viewport, opposite considerations come into play. How much content is too much? Are text columns going too wide, affecting readability in a negative way? Should select elements receive extra white space? And addressing viewport extremes isn’t just about sizing, it’s also for different input methods. The smallest viewports generally use touch, while the largest rely on mouse and keyboard.
It’s easy to forget RWD is a fluid platform given the design attention on static wireframes and comps. Most of your audience won’t see the exact view as your static design. Instead these will tend to be a bit larger or smaller. So consider the layout adjustments necessary between different breakpoints and static comps you design. For example, when sizing down, text content may shrink in size. Image assets can drop into a single column.
Avoid making assumptions about what those adjustments will be with your development team. Be proactive: bring up adjustments before your developers are too deep in their work. For complex layout changes, create another wireframe or sketch to illustrate them. Where specificity is less important, a discussion or an email describing transitions can suffice.
A common stumbling block between designers and developers is image formats and sizes. Smaller elements and icons might be PNGs, JPGs, icon fonts, or SVGs. There’s no one right answer; it depends on the content and resources available. But it’s important to agree on one format and stick with it. Also, you’ll likely develop patterns for common image sizes as your web project progresses.
Yet for modern RWD, that’s just the starting point. You’ll need at least two assets for raster formats (JPGs). One will be for normal displays and the other for high resolution ones. Advanced responsive image techniques need more assets to optimize for different viewport sizes.
Avoid leaving decisions on responsive image formats to the end of a project. At the bare minimum, have a strategy for display density. Read up on srcset and polyfills like Picturefill to ensure good cross-browser support. If it feels overwhelming, start small. Just altering a few image elements with the srcset attribute is a good first step. See how the process goes and grow from there.
So for developer handoffs, I like to concentrate on small and reusable components first. Smaller components generally keep the same UX and visuals across different devices. That consistency can be easier to digest for the development team. To boot, small components tend to be more reusable between pages on your design. So if you design an effective solution, it’s that much easier to re-apply it later on.
Imagine you’re designing a signup page with a headline, large graphic, and signup form. Depending on the device, these elements may shift around or change in size. Early on, focus on the smaller details of the signup form with the dev team. How does it look? What kind of validation is appropriate? How may a form component change with touch input versus mouse and keyboard?
Some designers shield developers from product meetings, usability sessions, and other opportunities for feedback. There’s a kickoff meeting, a handoff meeting, and little else. That’s a mistake. Remember that experienced developers are often an underrated knowledge base. They could have intimate knowledge of the product, especially if they worked on it for an extended period of time.
The skills of front end developers and designers also often overlap. Designers are starting to write their own code. Developers are learning about rapid prototyping, wireframing and aesthetic design. RWD has only exacerbated this trend. A developer can bring strong design insights without a formal “designer” title.
Granted, there’s still value in a separation of roles and responsibilities. Yet small steps toward inclusion can significantly assist the design of the final product. So for your next usability test, bring in a developer to discuss the outcome. Or if you’re on a design brainstorm, consult your developers for a second opinion.
All these techniques need planning and buy-in from others. With so much attention on launching products and hitting deadlines, that can be hard. But designer-developer relations are often underrated, especially for RWD projects. A small investment at the onset can have an exponential payoff for your team.
This post originally appeared as a guest post on InVision’s designer blog.