The roles of the designer and developer are increasingly overlapping, and it can be a struggle to know what each one does or does not do on any given project. Nowadays, template-based design and the ever-increasing expectation that designers can code mean that these roles often become an amorphous blob where no one quite knows who’s responsible for what.
In this article, we’re going to do our best to end the confusion and focus on how powerful these resources can be when they work together (plus some relationship advice on keeping them together).
A look back at the designer
Historically, the web designer was primarily responsible for, well, designing a website (or app). They were the ones who took the idea from a client, usually in the form of a brief, and went away and figured out what the website or app should look like. They made most of the decisions regarding things like look and feel, the interactions between the user and the site, and in some cases the information architecture. They were also involved in branding, either executing the brand guidelines or working to develop the brand with the client.
Finally, it was the designer who (in theory) would be working closely with the copywriter. Because these roles interact so much, the best results are driven by full collaboration. For example, imagine even a simple blog post. Keeping design and copywriting separate would be like one person dropping in images before the blog post is even written. Sure, it might
sort of match, but they’re hardly going to be a perfect fit.
How we used to see the developer
Traditionally, if the designer on a project was the ‘architect’, then the developer was seen as the builder. We used to think that the developer's only goal was to turn the designer’s ideas into a reality, taking the images and wireframes and bringing them to life through code.
Developers did this in two ways. First, by building what’s called the “back end” of the website – the stuff that the end user doesn’t see. For example, how the website interacts with the server, and where the site is stored.
Next, the development team builds the “front end”. They are the ones who make sure that the website looks the way it’s supposed to look, to the right users, at the right time.
In many cases, different team members are responsible for front end and back end development, as they require different specializations.
We're better together
The relationship we’ve just outlined was a traditional waterfall designer/developer relationship. The designer designs in isolation, the developer develops in isolation, and other than a brief handoff and a few check-ins, they don’t really have much to do with each other. This approach works fine so long as:
- Scope never changes
- Design or development specs never change
- Everything goes perfectly
As if! That is not the world we live in. Both design and development projects’ specs and scope change frequently. Furthermore, the very nature of a project can change throughout its course. For example, a designer might be asked to incorporate a new web page in the design, or a developer might be asked to change how an interaction works.
The point is that websites and apps are very complicated entities, and a design/development team working in their own silos won’t be nearly as productive as when working collaboratively. Designers are evolving and so are developers. And the lines between the two are blurring, for the better.
For example, some elements of design might work brilliantly in theory, but be a nightmare to execute. In a siloed team, the developer might struggle for weeks to get something just so, making the project run late. In a collaborative team, the designer and developer can work together to re-examine the problem and simply change the design early on with input from the development team, and then progress quickly to implementation.
So it’s easy to see why
this sort of collaboration is so popular. But how do we get it to work?
How to work better with your designer/developer co-worker
There’s a natural tension between a designer (who dreams up amazing concepts) and a developer (who’s now stuck with trying to turn those into a reality). So here are three tips to make this dynamic work a little smoother.
- Bring the team together early
This is the most important thing to remember. It’s a lot easier for everyone if both the designer and developer are involved in the project scoping process at the start. Developers are the best people to evaluate early design concepts and help set goals and timelines. As user experience, content strategy and information architecture continue to be king, bring the experts to the table at the start.
- Designers: don’t ever say ‘just’
Just is a very dirty word to a developer. ‘Just’ change the font size. ’Just’ rearrange the grid. ‘Just’ make all the images responsive. The problem is that each time a designer asks for a ‘just’ change, it might warrant a mountain of work for the developer. Respect what you’re asking for, and work together to find a simple solution.
- Work together (literally)
Working in the same space at times throughout the project can be beneficial for both parties. Better communication and better understanding of the process happens in person more than over email. Working together vastly improves relationships.
Wrap up
Any web project is going to involve both designers and developers; they both provide essential, but very different skills to a project. There’s no escaping that these groups are going to have to work together. But when teams can go from simply ‘working together’ to truly collaborating, projects go smoother, relationships are stronger, and the end result is better!
So go on. Bridge the gap of friendship and ask your designer/developer friend out for a beer. After all, you know they’ve earned it.
