Designers and developers often end up at odds with each other. But it needn't be that way, says Luke Clum.
Designers and developers are often assumed to be at odds with each other: designers like room for creativity, while devs want hard deadlines; designers need an understanding of the overarching project, while devs focus on one task at a time.
But there are many reasons why these differences should be reconciled: not only is it to the benefit of the working relationship between both professionals, but it's also of great help to increasing the efficiency and clarity of a cooperative project in its entirety.
Most importantly, developers have a lot to teach designers. Here are just a few things we can learn from them...
If you haven't heard of continuous integration, it's a popular application of what's coming to be known as Agile development, the new solution that has begun replacing a traditional 'waterfall' workflow.
Waterfall development: An approach where each stage of planning, design, development, and testing is undertaken sequentially, with each stage getting signed off on before the next is begun. This can create difficulties if problems are discovered late in the process, because they're more difficult to rectify after so much work has been done earlier on.
Agile development: The process of breaking a project down into smaller deliverables, where continuous collaboration between teams creates solutions that evolve over time. Every task is accomplished 'as needed', making it easier to revise earlier decisions.
The advantages of the new approach over the old are obvious, but so is the discomfort that designers might feel with the quick turnover and seemingly hasty decision-making that is necessary when using the Agile approach.
It's difficult to back away from the holistic understanding that most designers are used to attaining with a project before relinquishing it to the next stage of development. In order to effectively handle these new challenges, designers should put some other ideas into practice...
02. Problem solving, not styling
A lot of talented creatives lapse into thinking their jobs begin and end with organizing basic functionalities into something pretty to look at and easy to understand. This is by no means a misconception that all designers suffer under, but those who need some new perspective should start by approaching their work like a developer would.
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
If you break down a project into small tasks in which you must solve inherent problems - the button that needs to garner attention, the list that needs to be made visually palatable - then you're thinking like a developer.
Flat design
Take, for example, the current trend of flat design that so many websites have recently adopted. Designers considered the issue of button prominence as a problem to be solved, rather than an element to be styled. And they discovered that the traditional methods of differentiating a button from its background, with a skeuomorphic styling of drop shadows and beveling, was no more visually effective than simply using one bright, flat colour.
What's more, this solution was not only just as UX-friendly, it was also easier and lighter on the backend. The adaptation of this kind of problem-solving takes us to the next three points...
03. Recognizing and working with limitations
When approaching each task, it's important to acknowledge and quickly respond to limitations. Most web designers have heard that functionality trumps creativity, but in an Agile design this must be taken even further: creativity sometimes must also give way to convenience.
Web designers need to balance the sum effectiveness of a creative choice against the amount of work it will take to achieve. And to get that understanding, they must stay in constant communication with both each other and their dev team.
04. Constant feedback
Groups of designers are very frequently separated by their particular specialty within a team, and for the most part it's a solid assumption that this specialization is an effective strategy. Where this policy fails is during the brainstorming and critiquing phases of a project, which always seem to suffer if there is not enough diversity of input. And these phases are just as vital in an agile development mode as they are in any other collaborative system.
05. Constant collaboration
In addition to continuously coming together for inspiration and feedback within teams, designers need to respect the limitations that a project presents to the developers who bring their work to life. In order to understand what can and can't be done with the alacrity that an Agile project requires, communication between designers and developers is essential.
In short, a designer that adopts the thinking of a developer is one that problem solves as efficiently as possible, taking into account both functional and creative boundaries to find solutions that are flexible for future modifications.
Stated as such, these ideals hardly seem intimidating. But these small modifications in behavior can be all it takes to vastly improve a project's workflow and outcome, as well as the relationships between all of its creators.
