Editor's note: This is a guest blog post from Flurin Egger and Adrian Egger. We loved their talk at Future of Web Design earlier this year in London so much we asked them to elaborate further in print.
We spoke about designing in the browser at Future of Web Design in London in April 2015. Since then, we’ve noticed a lot of rumblings about designing in the browser — or rather, designing in code.
Does it mean designers need to be as good at coding as developers? Does it mean developers are redundant now? Does it mean designers are redundant now? Does it mean unicorns will die every time I open Photoshop?
It‘s a polarising issue. Much of the discussion revolves around code being just “yet another design tool.” That’s missing the point: designing in code not just a design tool, it’s a part of a workflow. And as a part of a workflow, it’s a way for designers to become better collaborators. Just like anything in design and development, it’s an iterative process.
When designing in code is part of your workflow, it’s important to involve every team member from the very start of any project (especially developers!). This approach makes the most of everyone’s strengths, allows for cross-pollination of ideas, and detects issues early. For this, we need a common language. Sketching is the most accessible solution — simply because it’s a low-threshold, fat-free medium. There’s no room for territorialism here: everyone gets to play. We’re not doing each other's jobs — we’re filling the gaps between the specialties.