In my experience, web designers talk far too much about development. We're worrying about how something might look in IE8, swapping rounded corner fallback solutions, and now stressing about fluid grid frameworks. The danger is that technical constraints will stifle our creativity.
How often do you lay an idea to rest because it's just going to be a nightmare to implement in CSS? How soon do you crush that idea? Do you let it develop a while to see if it's the best possible way to communicate your site goals to your user? Or do you just shelve it as soon as you consider how much markup it will require?
Since the advent of responsive design there have been an awful lot of zealots telling people if they're not designing in-browser then they can't possibly be doing it right, because the only way to realistically show the natural flow of content as it is in the browser is in the browser itself.
But this bothers me. I really want to be able to design in the browser, but I'm just not capable. If I think in CSS, everything just ends up being boxes with borders, because that's what is easy to make in CSS.
It's not because I'm a bad front-end developer: I know I'm capable of building very complex designs. It's just as if the technical and creative sides of my brain just don't want to interact in such a way.
As Robbie Manson so beautifully put in his talk at New Adventures, "Designing in the browser doesn't necessarily foster creativity". I was so relieved when Robbie said this that I had to hold myself back from standing up and cheering.
[Editor’s note: also see Sarah Parmenter, ‘I can’t design in the browser’]
The creativity we lose when designing in the browser isn’t my only problem. We're rethinking our working processes at the moment, trying to accommodate new devices, and I wonder where browser-based design should fit into that process.
Previously we had processes that were generally a variation on Research > Planning > Design > Development > Testing. Looking at this process as a rough overview, development in the browser comes somewhere towards the end.
Now I know that we all think we're very clever and won't ever skip important steps, but what happens when we start to 'build' our designs in-browser as early as the planning and design stages? I worry that once people have started sticking in their prototyping and grid frameworks, they're already constraining their designs with development tools. You're already starting to think in terms of the solution to your development problem before you've even started identifying what your user experience or design problems might be.
Big, scary & different
I have a theory why we're doing this, why we're going on about markup and device testing and all these other very important, but not-necessarily-appropriate-at-the-design-stage, issues. We're overcompensating because we have absolutely no idea what we're trying to design.
Responsive, adaptive and otherwise flexible layouts have completely changed how we design and the environments for which our designs are destined. This is big and scary and different. No longer are we decorating 1024 pixel-wide rectangles, we've got to come up with design strategies that will work across a multitude of viewports. We've got to understand and decide upon what will differentiate a site across these viewports and what will unite the elements to give a cohesive cross-device experience.
As designer-developers, development is a great excuse to avoid our craft as designers. Technically development might be harder, but in design we're more likely to come across challenges where the solution isn't straightforward or has already been shared by another developer.
Development is important
Of course a lot of development has a bearing on design. For example, I believe media query breakpoints are really a design consideration. We decide on the viewport sizes we want to accommodate in the early planning stages of our site design, we structure our layout around our content which we usually have in our late-planning early-design phases. The development of media queries is about planning the breaking and changing points of a layout based on a balance between viewport widths and content structure. Therefore this is fundamental to layout decisions.
I don't think we need to be technically ignorant, but rather agnostic to the technical solutions that may be here today but solved in a polyfill or spec next week. User experience is ongoing and is affected by the ever-changing contexts of our projects.
We're incredibly fortunate to be working in a time where the web is improving and moving at such a fast pace. We need to take responsibility as pioneers of the responsive web and start openly discussing our design challenges in order to forge the standards and conventions of the future.
Now check out the latest features in Photoshop CS6.