A few months ago Jason Shen touched on the idea of a full-stack creative team in the Percolate marketing department. What that means in practical terms is that we have a team of people coming together from engineering, design, and business backgrounds. We make it work, and here’s how.
I’m an engineer on our marketing team, building outward-facing projects with the communications designers. That includes a lot of web design and web development for a general audience, which in turn makes for a lot of dev/designer collaboration.
The most successful projects I’ve worked on in my career have had a strong collaborative aspect between designers and developers. It’s better when the two sides can work together to solve problems instead of putting too much weight on one side or the other. We have weekly design workshops internally and I recently presented the list below to members of our marketing team who participated on what I like to see in a working relationship between designers and developers.
1. Understand the medium.
As a web developer, understanding the medium means having a technical understanding. Any technical understanding makes for a better designer. I don’t have expectations as a developer of a designer understanding nuances of markup or CSS, but someone designing for the web should understand basic principles of web development in the same way that I would be expected to understand basic principles of typography.
Instead of specific technical understanding, I’d rather a designer have a larger understanding of the current state of web design. Web development’s changed a lot in the past few years. The way I work is very different from how I worked a year or two ago. Specifically, responsive design marked a huge shift in thinking for web developers. It changed the basic principles of how I work. The tools of my trade have changed at such a rapid pace, I’m usually learning something new with every project I work on. A designer with a sense of history and foundational of understanding of how the web works makes for a better collaborator.
2. Be aspirational.
Some technical understanding can often mean not discarding ideas at the start of the project. A designer can present a scaled-back idea because they’re not sure if the idea is even possible. I like to encourage the designers I work with to be as aspirational as possible at the start of a project.
There’s one question I always hear at the beginning of projects: “How hard is this?”
I hate this question.
I understand why this question comes up, but I’d prefer it didn’t at the very beginning of a project. We can talk about feasibility, timelines, and what’s technologically possible with the time and availability we have, but “How hard is this,” to me, isn’t a valid question. Don’t undersell an idea because you assume it might be difficult to execute. I’d rather have that discussion about practicality first than leave an idea on the table.
“Go at it boldly, and you’ll find unexpected forces closing round you and coming to your aid.” — Basil King, The Conquest of Fear
Engineers want to do good work and make amazing things. Sometimes that means putting a lot of work into something massive in scale. Sometimes that means putting a lot of work into something small and complex. But if you campaign for a great idea, I will want to make it happen. This reflects one of Percolate’s core values: we’re focused on scale, but willing to do things that don’t.
3. Push boundaries.
Prototypes and proofs of concept are crucial to the exploration process. Developers will want to take work live as soon as possible to test the feasibility of an idea. Developers need exploration in the same way that designers do, and just like design explorations, sometimes a prototype of exploration won’t work out.
Including the space for this work during a project will make everyone happier, and the aspirational idea that might have seemed impossible at the outset has a chance to take hold.
4. Settle… without compromise.
That said, being aspirational and pushing boundaries doesn’t mean we can leave users behind. But settling shouldn’t compromise the original intent. This means thinking through what progressive enhancement and graceful degradation might look like in everyone’s work, and accounting for that approach from a development perspective.
Most people see our blog on a device that is not a desktop. Thinking about these users is a critical part of my work as a web developer, and it should be on the mind of designers too. “No one’s at this resolution” and “we’ll make it one column” aren’t design decisions so much as they are compromises.
Designers and developers often have similar goals but separate concerns. Page speed, semantic markup, maintainability, browser compatibility, and SEO often land in the realm of the web developer. These concerns have to live in harmony with design decisions. The weight we give design and development concerns guides our decision-making and influences the finished product. No one side should always win. That decision-making process leads me to a different role a designer takes in a project.
5. Be authoritative.
The designer should have authority within a project; authority shares the root with author, and you are the author of the design we’re building. A developer looks to the designer for expertise. I trust the judgment of the designers I work with, and the best designers give confident, authoritative direction.
I recently worked with Michele Byrne, one of our communications designers, on a page for our Client Summit. Event sites have different needs than other projects, and Michele took the lead on the branding for the entire event, and she wrote about the brand system she built. Working with a designer with a larger vision for the project as a whole meant Michele could make quick and authoritative decisions, which made implementation easier for me (especially under deadline).
6. Empower your colleague.
On the flipside, any time a designer doesn’t give direction, the developer will need to make decisions. The designer can guide and empower those decisions. Often, a good film director will just let an actor take a scene where it needs to go and trust in that actor’s decisions. But that’s still direction — it’s a purposeful directorial decision.
Try not to say “I don’t know.” Or, if you genuinely don’t know what to do in a given situation, and a dev asks a question you don’t know the answer to, talk through it so you’re better informed next time.
7. Provide guidance and resources.
Direction can come in the form of style guides, annotated assets, conversations about the reasons for doing things, or even simple explanation of the problem a given design is solving. (That list of things could be titled “Things I Love.”) Often, direction doesn’t need to be more than a well-put-together and annotated layout.
8. Create without ego: ideas, design, code – nothing is sacred.
All that said about direction and guidance and authority, remember that.
“Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it — wholeheartedly — and delete it before sending your manuscript to press. Murder your darlings.” — Arthur Quiller-Couch, On the Art of Writing
This sentiment is requoted everywhere, most notably by Stephen King. I go back to this thought any time I fall in love with a particular idea or a clever bit of code. Whether it’s an idea, design, or code, be willing to evaluate your work.
9. Manage the project.
Process and procedure can be the most overlooked parts of collaboration, but the day-to-day of how things get done is probably the most important.
Project management shouldn’t be completely outsourced when team members are collaborating. Having a project manager is really helpful, but it shouldn’t be a project manager’s sole responsibility to communicate between team members. Formalized communication — by everyone — helps a lot. The more that gets written down, the better. If I have a conversation about a project, I try to write it down or type it up somewhere so I remember the takeaways. If I discussed a plan of action with someone, I’ll immediately assign myself those tasks.
The basic tools of designer/developer project management seem pretty self-evident: task management, organized asset delivery, consistent file versioning, and one-on-one check-ins all play a role. It helps to get into a more formalized pattern of usage with these. The more transparent everyone is as a project progresses, the better.
10. Organize the deliverables.
How the work is built may be different from how you perceive the finished product.
Designers and developers often see a web page differently, and it’s better when these items are organized but separate. Making sure these items consistently versioned is a pain that pays off. Programmers have version control systems and efficient tools to manage complex codebases. Programmers also love to automate things, sometimes needlessly. It could be the case that a complex or unwieldy process that a designer has to work through could be improved with a little scripting or changes in how files get managed, or that a designer might be doing extra work that complicates the process for the developer.
You should feel free to collaborate about process. We’re all busy, and the more efficient the procedural stuff goes, the more fun we can have.
11. Schedule out the work.
Parallel work is good, constant work is better. I’ve often found that a lot of work can go into trying to parallelize tasks, when the project would have gone just as smoothly had everyone progressed at a comfortable pace. Designers and developers should work in parallel when possible, but that shouldn’t be a priority above getting the work done. Clarity about timelines is important. Communicating the priorities and understanding when work is slated to be done helps everyone use their time efficiently. I don’t mind work getting completely re-done in service of better design or implementation; I mind when I’m given everything at deadline.
12. Other ways to foster a good design-dev relationship.
Collect. Share good or interesting work that you find. Design and dev newsletters, sites, blogs are all great. Share these with devs — they’re inspiration for us both. I like Versioning and Sidebar in terms of dev and design newsletters.
Learn from the end of the process. Take stock of the build process after you’ve handed off designs and note points of improvement. Take usage information and other metrics and apply those to future work.
If you don’t control the feedback loop, someone else will, and they may not have the context you had with what you designed. Often optimization and metrics are out of our hands, but they shouldn’t be.
When developers and designers work in concert, the things they accomplish can be truly awesome. See more work we’ve done on our Percolate Design Page.