A lot of influential web designers are heralding the end of tools like Sketch and Photoshop. But I’m going to keep using them. Sorry.
The notion that web designers should be working in the browser is one of the most controversial topics our industry. Popular conferences or big ‘rock star’ blogs give the impression that ‘traditional’ design tools (i.e. photoshop) will be going extinct in our processes any day now.
The idea of ‘designing in browser’ was popularised a couple of years ago, and a lot of people are quite evangelical about it.
When the argument is put in front of you, it really does make a lot of sense.
- It gets your design into the medium you’re actually designing for.
- It allows you to prototype the intricate responsive and interactive behaviour.
- It should (in theory) save time, as you write some code in your design process.
These are some extremely convincing arguments. I was totally sold on the idea, and convinced that this was how our agency needed to work… For a while.
Unfortunately, the reality is that trying to adapt this mentality into larger teams (at least the ones I’ve worked in) can be unrealistic. And here’s why.
You need a ‘sandbox’
For a lot of designers, going straight into code is really difficult. Tools like Sketch, Photoshop and Axure are very forgiving. They allow designers to drag things around, play with effects and trial lots of variation quickly.
The design in the browser attitude doesn’t stipulate that you should be writing perfect production code, but you still need to be thinking about things like the DOM a little too much for my taste. Being able to make snap decisions and immediately see effects is a crucial part of the early creative process.
As good as frameworks like bootstrap and foundation are, I don’t believe I’ll ever be able to code as quickly as I can use a software tool.
It’s harder to be iterative
I’ve learned that the secret to UX success is iteration. The term ‘fail fast’ has basically become my slogan. Whether it be due to user testing, team suggestions, or client feedback - you never, ever get your designs right on the first time.
When I tried the ‘design in the browser’ approach (even just with wireframes) I found that the amount of time I’d committed to coding things up made me much more reluctant to iterate. It felt like I was more invested in my work, so I ended up pushing back changes that I probably would have made otherwise. My attitude shifted to that of a perfectionist far too early.
In our agency it’s not rare for a single screen to go through many rounds of iteration, often changing dramatically between them. This can be really painful if it means having to re-write lots of code, rather than just drag a few boxes around.
In large teams, you need specialists
My belief is that designing in the browser works much better for small teams and freelancers. Those who are going to build their own designs will obviously get much more value out of bypassing mock-ups and going straight into code. (I feel like this represents a lot of those people speaking out conference tracks).
When working in a larger team, we need to have dedicated designers who can focus on research, IA, and design. In the environment I’m in, having people to focus totally on these tasks is crucial. It’s just like we need to have separate specialists for front and back-end development. They’re big fields.
Knowing how to code is the responsibility of any web designer worth his or her salt, I firmly believe that. But as long as we can make sensible, informed decisions we should leave the implementation to someone who specialises in doing so. That’s what teams are for.
You always have a choice
I think designing in the browser is an amazing idea if you have the time, capability and internal culture to support it. But I don’t, and I think that’s ok.
Younger web designers are under a lot of pressure to think that there’s one ‘right’ way of doing things, but there are many ways to skin a cat. You can make an amazing user experience by iterating rapidly, being thorough in your design work, and working closely your development team.
HTML, CSS and browser tools rightfully belong in the web designers toolkit, but no more so than anything else. Use them where appropriate, and remember that it’s all a means to an end.