In responsive web design we’ve found a technique that allows us to design for the web as a medium in its own right: one that presents a fluid, adaptable and ever changing canvas.
Until this point, we gave little thought to the environment in which users will experience our work, caring more about the aggregate than the individual. The applications we use encourage rigid layouts, whilst linear processes focus on clients signing off paintings of websites that have little regard for behaviour and interactions. The handover of pristine, pixel-perfect creations to developers isn’t dissimilar to farting before exiting a crowded lift, leaving front-end developers scratching their heads as they fill in the inevitable gaps. If you haven’t already, I recommend reading Drew’s checklist of things to consider before handing over a design.
Somehow, this broken methodology has survived for the last fifteen years or so. Even the advent of web standards has had little impact. Now, as we face an onslaught of different devices, the true universality of the web can no longer be ignored.
Responsive web design is just the thin end of the wedge. Largely concerned with layout, its underlying philosophy could ignite a trend towards interfaces that adapt to any number of different variables: input methods, bandwidth availability, user preference – you name it!
With such adaptability, a collaborative and iterative process is required. Ethan Marcotte, who worked with the team behind the responsive redesign of the Boston Globe website, talked about such an approach in his book
The responsive projects I’ve worked on have had a lot of success combining design and development into one hybrid phase, bringing the two teams into one highly collaborative group.
Whilst their process still involved the creation of desktop-centric mock-ups, these were presented to the entire team early on, where questions about how pages might adapt and behave at different sizes were asked. Mock-ups were quickly converted into HTML prototypes, meaning further decisions could be based on usage rather than guesswork (and endless hours spent in Photoshop).
Regardless of the exact process, it’s clear that the relationship between our two disciplines is more crucial than ever. Yet, historically, it seems a wedge has been driven between us – perhaps a result of segregation and waterfall-style processes – resulting in animosity.
So how can we improve this relationship? Ultimately, we’ll need to adapt, but even within existing workflows we can start to overlap. Simply adjusting our attitude can effect change, and bring design and development teams closer together.
Good design is constant contact.
The way we work needs to be more open and inclusive. For example, ensuring members of the development team attend initial kick-off meetings and design workshops will not only ensure technical concerns are raised, but mean that those implementing our designs better understand the problems we’re trying to solve.
It can also be useful at this stage to explain how you work and the sort of deliverables you expect to produce. This will give developers a chance to make recommendations on how these can be optimized for their own needs.
You may even find opportunities to share the load. On a recent project I worked on, our development partners offered to produce the interactive prototypes needed for user testing. This allowed us to concentrate on refining the experience, whilst they were able to get a head start on building the product.
While developers should be involved at the beginning of projects, it’s also important that designers are able to review and contribute to a product as it’s being built. Any handover should be done in person, and ideally you’ll have a day set aside to do so. Having additional budget available for follow-up design reviews is also recommended. Learning how to use version control tools like Subversion or Git will allow you to work within the same environment as developers, and allow you to contribute code or graphic assets directly to a project if needed.
Don’t underestimate the benefits of designer and developer sitting next to each other. Subtle nuances can be explored far more easily than if they were conducted over email or phone. As Ethan writes, “‘Design’ is the means, not merely the end; the path we walk over the course of a project, the choices we make”.
It’s from collaboration like this that I’ve become fond of producing visual style guides. These demonstrate typographic treatments for common markup and patterns (blockquotes, lists, pagination, basic form controls and so on). Thinking in terms of components rather than individual pages not only fits in better with how a developer will implement a site, but can also ensure your design works as a coherent whole.
Despite the amount of research and design produced, when it comes to the crunch, there will always be a need for compromise. As the old saying goes, ‘fast, cheap and good – pick two.’ It’s important that you know which pieces are crucial to a design and which areas can allow for movement. Pick your battles wisely. Having an agreed set of design principles can be useful when making such decisions, as they help everyone focus on the goals of the project.
The best compromises are reached when both sides understand the issues of the other.
Ultimately, better collaboration comes through a shared understanding of the different competencies required to build a website. Instead of viewing ourselves in terms of discrete roles, we should instead look to emphasize our range of abilities, and work with others whose skills are complementary.
Perhaps somebody who actively seeks to broaden their knowledge is the mark of a professional. Seek these people out.
The best developers I’ve worked with have a respect for design, probably having attempted to do some themselves! Having wrangled with a few MySQL databases myself, I certainly believe the obverse is true. While knowing HTML won’t necessarily make you a better designer, it will help you understand the issues being faced by a front-end developer and, more importantly, allow you to offer solutions or alternative approaches.
So take a moment to think about how you work with developers and how you could improve your relationship with them. What are you doing to ease the path towards our collaborative future?
Comments
Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.
Got something to add? You can leave a comment below.
05/12/2011
Excellent article Paul. Some of the most enjoyable projects I’ve produced have been where I’ve worked very closely with a designer and UX. It’s amazing how much you can get done in a little team of three people.
I must admit I’ve never had a designer with access to version control, but it sounds like an excellent idea if they are willing to give it a try.
Vote Helpful or Unhelpful
05/12/2011
“The responsive projects I’ve worked on have had a lot of success combining design and development into one hybrid phase, bringing the two teams into one highly collaborative group.”
It had actually never occurred to me (as a 16 year old generalist who’s never worked with any other designer/developer) that design and development wouldn’t be done at the same time, especially for a responsive website.
The idea of a “designer” who comes up with a purely visual design then hands it to a ‘developer’ who makes it is repulsive to me. How does that make sense? Surely a ‘designer’ should not only be putting together the visual aspect, but also helping to build and oversee the overall look and feel of the site?
Great article — I didn’t realise people didn’t do what you’re suggesting!
Vote Helpful or Unhelpful
05/12/2011
Nice article :) We’ve been using this approach at work quite a bit recently and found it a massive help. It’s not limited to responsive designs either, although it clearly helps a lot more there.
I think in any endeavour it makes for a better end result if the whole group are on-board and aware of what others are doing as early as possible. You never know what considerations others in the project might have with some of the things you do, or the insights they can offer. It’s beneficial to at least get mock-ups discussed with the group before settling on anything final if there isn’t the time or budget to do more than that.
Vote Helpful or Unhelpful
05/12/2011
@Barnaby
I agree with you, but the reason it’s not done like that everywhere are twofold. One is that most established design studios have “designers” already, and they have a tendency to want to use their established print team to do “visual design”, then hand over to their specialist “web team” to code them. That’s not a great way of doing things, but it’s perfectly understandable. It’s taken a little while where I work but we have come a long way and migrated away from that flawed way of doing web designs.
The other reason such a compartmentalised way holds on is economy of resources. If you already have “designers” you use them, and then you use “coders” to implement it. Each does their specialist role faster individually. But the end result isn’t as good. That’s why I’m a big fan of “talent bleed” and this type of approach. In the end, everyone can do their jobs better.
Vote Helpful or Unhelpful
05/12/2011
@Barnaby it probably does sound really crazy to you as a 16 year old as the web has changed so much in the last few years, however this separation of roles was pretty common for years. It still is out there in agency-land. I wrote on our company site about how we, as a 10 year old company, have had to change how we work on things – You need a web designer
It’s also good to have new people coming through and pointing out where we are doing crazy things because that’s how we’ve always done it :)
Vote Helpful or Unhelpful
05/12/2011
“While knowing HTML won’t necessarily make you a better designer, it will help you understand the issues being faced by a front-end developer and, more importantly, allow you to offer solutions or alternative approaches.”
Exactly! There are a number of constraints to integrate and sometimes designers are not aware, and are disappointed, thinking that dev “sabotage” their work.
Now the constraints are even more important with the need to always produce faster interfaces, which means fewer files, reusing some background images, …
Vote Helpful or Unhelpful
05/12/2011
Excellent article, understanding each others work/part in a project is the most important thing that leads to successful results as, dare i say that web design/development is beautiful information architecture.
Vote Helpful or Unhelpful
05/12/2011
I agree with the importance of a good relation between designers and developpers. But I would not stop there. In my experience it is very important to meet up with the whole team. A meeting in person where everyone sit together and let multiple ideas come together. That will give better results.
Vote Helpful or Unhelpful
05/12/2011
Best article yet! I’ve seen a lot of the stuff you wish for failing. For various reasons. Collaboration also is a personal thing and it seems (from my limited experience) maybe only 20-30% of people are even capable of doing it. Sad really. But you wrote a lot of points that warm my heart (it’s xmas after all ;) and gave a little hope back
Vote Helpful or Unhelpful
05/12/2011
@Matt Hmmm… One thing that always strikes me whenever I learn something new in any field of the web is how it affects my thinking in other areas. So I agree that talent bleed is an asset, not a dilution.
@Rachel
Your article sums up my thoughts well — the web is indeed its own medium, and demands the skills and expertise of someone who has a wide breadth of knowledge and experience. It’s a pity we have to call ourselves “Web Designers”, I’m not sure that term really expresses what we do. Unless you take ‘design’ to mean design of everything from code to content strategy.
Vote Helpful or Unhelpful
07/12/2011
Wow. This is a pretty great article. I’ve been hunting around for a while for something similar, since there’s been tons of talk about responsive design but not much about the process of making it happen. So far, the only other good one I’ve found is this:
http://curatedcommented.com/2011/in-search-of-a-responsive-workflow/
There’s so much to be said for integrating the teams working on a modern site, and responsive design pretty much requires it. Kudos to you for the great article.
Vote Helpful or Unhelpful
14/12/2011
@Thom,
Like you I’ve also seen quite of articles telling folks their photoshop mockup process is wrong (it is) but little in the way of writing up of the processes people now use to develop more responsive sites and layouts/interactions etc.
I tried to write up some key steps for our process at Offroadcode if you’re interested, it’s by no means the same steps for every project but hopefully gives a bit of an overview of how we work with our projects.
http://offroadcode.com/blog/2011/7/18/turning-our-design-process-upside-down/
J.
Vote Helpful or Unhelpful
Impress us