As web design untangles itself from print concepts, there’s a need for new processes, workflows and tools. It’s no longer enough to create a static comp in Photoshop and fling it at a developer to turn into a live site. Increasingly, designers and developers work together, creating fluid prototypes that more closely resemble the final article than flat pixels rooted to the spot in Photoshop.
That’s not to say you should abandon Creative Suite and only fire up a browser when designing websites. Many web designers still work with a visual tool, but it’s how they do so that’s important. As Clearleft’s creative director James Bates elaborates: “It’s much more of a messy process than it used to be. You can’t think of the ‘design phase’ and then hand over comps. You’re now building stuff and if something doesn’t work, you tweak the design. It’s very much a back and forth between your browser and whatever tool you’re using to solve a problem.”
Said tool is frequently Photoshop. UI designer Sarah Parmenter says: “I know Photoshop’s become a bit of a dirty word lately, but a graphics editor is a must – if I don’t go through that process, my designs become kind of boxy and don’t look very nice”.
However in modern web design, Sarah argues that Photoshop is a place for creative thinking and experimentation – a digital sketchbook – and not for designing full PSD comps: “I sketch on paper and move quickly to the browser with a natural grid. I’ll then use Photoshop for graphic elements and colour. My PSDs end up like puzzle pieces that are put together in the browser.”
Using the browser early on in the process brings further advantages, explains Sarah: “We have clients sign-off on grey-box wireframes, and so they’re not preoccupied with what things look like. We then add to those throughout the process, because HTML and CSS is simple to update across devices – unlike flat Photoshop comps.”
On regular collaborations with designer Elliot Jay Stocks, Keir says there’s plenty of loose mock-up work in Photoshop (colour palettes, logos) and experimenting in the browser with type. James adds mood boards and style tiles to the equation, enabling designers and clients to get an idea of a design’s feel without a fuller mock-up. When it comes to software, he advocates the “path of least resistance”, using whichever tool is “easiest to trial or solve a problem, and that’s most appropriate for the job”.
Further investigation makes it clear a web designer’s toolkit is more varied than it once was. A browser is essential and Photoshop widespread, but Mac app Sketch is becoming popular for its browser-like rendering, lack of a fixed canvas and styles ‘mapped’ to CSS.
Paul Woods, a designer at Edenspiekermann, reckons “Keynote design sketches and getting design into the browser beats pixel-perfect layouts any day”; and Dan Davies, who works at McCann Metro, says the company’s designers are exploring CSS Hat to ease the transition from Photoshop to browser.
Tools can also assist when working in the browser. Web designer Oli Studholme avoids tools “not of the web” because “pristine mock-ups don’t fare well on meeting the reality of the zombie apocalypse of devices”. Post-paper sketches and basic digital ideas, he uses a mobile-first approach, building on Normalize.css.
Elsewhere, Keir recommends Mixture, a “powerful prototyping tool that enables you to get up and running with boilerplate projects quickly, including creating your own that can be integrated”. With the ability to enable common components and sharing, he posits the tool “targets the designer who’s moved to code rather than the developer who dabbles in Photoshop”.
For visual designers used to linear workflow, hopping between numerous apps and browsers might seem alien, and it also requires changes in how to work with clients and developers. “Involve them from the start, keep mock-ups lo-fi and quick, and iterate like crazy,” recommends Oli.
With clients, Clearleft senior visual designer Paul Lloyd stresses the importance of managing expectations: “We were once focused on what you presented, sign-off and deliverables. Now web design’s about letting clients know it’s a messy process, and giving them plenty of insight into what you’re thinking, not ‘deceiving’ them they’re getting a beautiful ‘final’ visual.”
James says, ideally, developers should also be involved from the start, “because a good one will check what you’re doing and make recommendations, and the collaborative process brings benefits”. Paul Woods agrees: “Work as closely together as possible and avoid the waterfall process – design, code, ‘fill with content’. Instead, design and code simultaneously. If necessary, be strategic and get to know the developer and partner when you can.”
There will, of course, be times when you’re a lone designer, unable to work directly with a developer. Even then, there are ways to ensure a project runs more smoothly.
“Get an awareness of technical limitations and possibilities,” suggests Zurb partner Jonathan Smiley. “Knowing what can and can’t be built, or can’t be built in the time allowed, is the difference between a good design getting to users and it being shelved for something else.”
Once you have those skills, “always think about how your design will transfer to code,” recommends designer and illustrator Mike Kus; for example, with responsive sites, imagine how it will respond to different viewports. “Development is very much in my mind from the beginning and throughout a project,” he says.
Finally, when in the position of handing over any visual design elements to a developer, Oli advises thinking about deliverables from a front-end developer’s standpoint. “Start with a rational grid based on the final default font size and line height,” he says. “Follow basic principles of good design, such as lining things up and avoiding minor design variation. Understand CSS margin collapsing and discuss how this will be handled, to give you insight into spacing elements. Create a basic style guide, and note down things like colours, font sizes and spacing, so the developer doesn’t need to check manually.”
Keir recalls less web-savvy designers who’ve handled things differently: “The 320 PSD, the 960 PSD, gradients within type, and an order to ‘go and make this’.” He says static mock-ups don’t change and don’t bend, but when you receive such things as a developer, you often feel you’re kicking back and having a go at the designer. “So communicate. Don’t just pull in things you’ve seen elsewhere, unless you understand their relevance. Learn about, embrace and be comfortable with the fluid nature of the web.”
Sarah expands on that point, which has the potential to cause rifts between designers and developers: “You’ve got to realise if you’ve been working in Photoshop, you’ve been working in a static medium, and probably to a fixed canvas. Too many designers still hand PSD comps over as deliverables, but you then have to ask what happens next. If you’ve not learned enough about the web, don’t be surprised if your work’s completely butchered because a developer’s on the responsive bandwagon and you’re not.” Her advice: know how a design is going to be used, and exactly what’s been signed off – the design and atmosphere or just placement – and “ask tons of questions to understand where everything’s at”.
A healthy dose of respect can also pay dividends, adds Dan: “Both you and the developer should be aware of what the other brings to the table. It’s about working together.” He does admit that, for him, “the designer has the final say,” but they must always realise that, as others have said, “things won’t always look how they’d hoped, for various reasons”. And if there’s still an impasse? “There’s always rock-paper-scissors!”