The 11/21/14 edition of SmashingMagazine.com published an article by Paul Boag titled Why You Should Include Your Developer In The Design Process that is an absolute must-read for any arts organization considering a web redesign project. I’ve been trying to write about this very topic for months now but it always ended up on the backburner because it lacked a certain level of conciseness; fortunately, Boag had no such trouble.
Ever since arts orgs started publishing websites, I’ve witnessed groups waste thousands of dollars per project in unnecessary development overruns and endure god-only-knows how many hours of frustration simply because they got caught in an a common process bear trap:
- Hire graphic design/branding firm to design website.
- Approve design.
- Hire and/or tell existing developer to build said design.
Simply put, this is a recipe for catastrophe but you can easily sidestep this mess by interjecting the designer and developer at the onset of the project. Moreover, don’t give either one decision making authority over the other; instead, contractually require them to work collaboratively.
Boag highlights the benefits of this approach and since he’s a designer by trade, when he references we, us, our, etc. he’s talking about designers. Here are some of his key points.
…when developers are not involved in design. It can be disastrous. It can lead to designs that are impossible to build, designs that introduce unnecessary technical complications, endless back and forth between the designer and developer as they struggle to fix problems created by the designer, wasted days of revision and iteration — all because the developer wasn’t consulted.
As a technology provider that offers both development only and design plus development services, I can say with all confidence that this is the one area where clients end up spending far more than they should.
Another wrinkle to consider is making certain your designer understands the platform used by the developer. Ideally, your developer should use a fully responsive publishing platform and by nature, that design process requires something far more flexible than the old-school Photoshop mockup, approve, then build routine.
This is where a collaborative minded developer will shine as the interaction with the designer to better understand the ultimate user experience environment will make all the difference; on that note, it also leads right into Boag’s next point.
“The developer can improve our understanding of what is possible.” – Paul Boag
But we need developers not only to block infeasible ideas. They might also suggest ideas that we’ve dismissed as impossible. We sometimes filter our own ideas because of the limitations of our technical knowledge, especially if we do some coding ourselves. We figure that if we cannot think of how to build an idea, then it cannot be possible.
If you hear your designer say they understand responsive websites and don’t need input from the developer, trash their proposal (or fire them). Responsive web design is a concept but the gulf between understanding that and understanding the specific front-end framework within the publishing platform(s) used by a developer is akin to the difference between shooting a bullet and throwing it.
Consequently, you need the designer and developer to communicate throughout the process and learn from one another to produce a final product that is greater than the sum of its parts instead of a compromise that satisfies none.
“Developers make design decisions all the time.” – Paul Boag
The biggest reason, though, for involving developers is that they will end up making design decisions anyway. The truth is that, as a developer delves into building a project, they will have to make decisions that affect and refine the design. Designers rarely have the time to consider all nuances of a website. The rest fall to the developer.
One additional thought here is if you’ve engaged a genuinely collaborative process, the designer and developer will build a certain level of trust that marginalizes the potential for you, the client, to burn up your precious time having to step in and mediate a design fight.
“The developer will have a greater sense of ownership.” – Paul Boag
Too often, developers are at the end of a long chain of decision-making. Their voice isn’t heard because they’re brought into the process far too late…By bringing them in earlier, they will feel more connected to the work and more appreciated, too.
Ideally, your developer should also be the provider who is delivering ongoing support and training so from a return on investment perspective, engaging them in the design process will only encourage them to take a higher degree of involvement down the road; meaning they aren’t just changing diapers, they’re helping to raise the child. In turn, this means you end up with a better website that maximizes its role in delivering your mission based activity.
Boag wraps his article up with some very practical insights on how to go about interjecting the developer into the design process. Additionally, most arts orgs will have a few additional items to consider; not the least of which is how and where the third party box office and/or customer relationship database (CRM) provider(s) fit into the design mix.
If your organization has a fixed box office/CRM provider, you need to interject them into the process as well because even though the amount of project overlap between that provider and the designer won’t be very high, the cumulative impact on the three-way relationship is more profound.
You can begin to see how important it is to make sure each of your providers can demonstrate the ability to work together before entering into written agreements.
Does this mean it makes more sense to opt for uber-providers that bundle all of these services together in a single agreement?
Not really; Boag makes some very good points in his post about web design firms that employ both designers and developers having just as much of a dysfunctional relationship as what you might encounter from separate providers. If anything, you might have a more difficult time uncovering potential issues with combo providers but it certainly shouldn’t preclude them from consideration; instead, it’s just a different degree of due diligence on your part when evaluating proposals and conducting interviews.
In the end, Boag offers some solid advice about the perils of letting any single provider have too much control over what should be an entirely collaborative process.
Excluding the developer from the design process will do nothing but prevent the project from living up to its potential. In fact, excluding anyone — whether copywriter or SEO specialist — will ultimately compromise our work.
Good advice indeed.