- Collaboration
- Direction
- Process
Qualities a designer should have in a working relationship with a developer.
The initial discussions, the back-and-forth, the beginning of a project.
- This means some technical understanding, but not for the reason you might think.
- More than specific technical understanding, I’d rather a designer have a larger understanding of the current state of web design.
Any technical understanding makes you a better designer. I don't have expectations as a developer of you understanding nuances of markup or CSS, but understanding the principles of web development in the same way that you would expect me to understand basic principles of typography.
Web development's changed a lot in the past few years. The way we work is very different from how it was even a year or two ago. I'll get into this more later, but responsive design was a huge shift in thinking for web developers. It changed the basic principles of how I work.
Technical understanding means not discarding ideas.
“How hard is this?”
Don’t ask this. Or, don’t go to this first.
We can talk about feasibility, timelines, and what’s technologically possible with the time and availability we have, but this 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 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, 1921
Often quoted more pithily as:
“Be bold and mighty forces will come to your aid.”
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 tiny and complex. But if you campaign for a great idea, I will want to make it happen. That means...
- Prototypes and proofs of concept are crucial to this process
- Take work live as soon as possible
- Developers need exploration too, just like designers do
- Sometimes a prototype or an exploration won't work out
Prototyping > Talking when it comes to executing on an idea.
Being aspirational and pushing boundaries doesn’t mean we can leave users behind.
But it shouldn’t compromise the original intent. This means thinking through what progressive enhancement and graceful degradation might look like in your work, and accounting for that approach from a dev 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 your mind as designers. “No one’s at this resolution” and “we’ll make it one column” aren’t design decisions so much as they are compromises.
Similar goals but different concerns:
- Page speed
- Semantic markup
- Dev and design maintainability
- Browser compatibility
- SEO
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. And, in those discussions, we're looking to you for...
Qualities that provide support to the developer.
You have authority here; authority shares the root with author, and you are the author of the design we’re building. A developer looks to you for expertise. We trust your judgment. Give confident, authoritative direction. This pairs with the next item:
Any time you don't give direction, the developer will need to make decisions.
You 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 do this. Or, if you genuinely don’t know what to do in a given situation, or a dev asks a question you don’t know the answer to, talk through it so you’re better informed next time.
Guidance and resources:
- Style guides
- Annotated assets
- Conversations about the reasons for doing things
- Explanations of the problem a given design is solving
Provide enough initial guidance and resources so the developer isn’t saddled with a series of tough choices. All that said about direction and guidance and authority…
Ideas, designs, code — nothing is sacred.
- Nothing should be sacred
“If you here require a practical rule of me, I will present you with this: ‘Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it—whole-heartedly—and delete it before sending your manuscript to press. Murder your darlings.” — Arthur Quiller-Couch, On the Art of Writing, 1914
Requoted everywhere, most notably by Stephen King. I go back to this any time I fall in love with a particular idea or a clever bit of code. Be willing to evaluate your work.
The boring stuff.
The more that gets written down, the better.
Formalized communication helps a lot. If we have a conversation, I try to write it down or type it up somewhere so I remember the takeaways. If we discussed a plan of action, I'll immediately assign myself tasks in Asana.
Project management toolkit:
- Task management
- Organized asset delivery
- Consistent versioning
- Check-ins
These are the obvious tools for project management, but it helps to get into a more formalized pattern of usage with these. For example, consistent versioning and git for developers (semantic versioning as well). Planning regular check-ins instead of ad-hoc scheduling; all of that can potentially reduce friction. The more transparent, the better.
How the work is built may be different from how you perceive the finished product.
Copy - HTML, JSON or other dynamic loading Page layout - HTML and CSS Styling - CSS or images Images - Images in different formats
We see these things differently, and it’s often better when they’re organized but separate. Making sure these are organized and versioned is a pain that pays off. The more efficient the procedural stuff goes, the more fun we can have.
Parallel work is good, constant work is better.
Clarity about timelines is important. We should work in parallel when we can, but we shouldn’t prioritize working in parallel. Communicating the priorities and understanding when work is slated to be done helps everyone use their time efficiently. I don’t mind work getting blown up, I mind when I’m given everything at deadline.
- 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.
- Learn from the end of the process. Take stock of the build process after you handed off designs and note points of improvement. Take usage information and other metrics and apply those to future work.
I like Versioning and Sidebar in terms of dev and design newsletters.
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.
So, I like thinking about video game design — it’s a unique blend of design and development.
- The Legend of Zelda: "It's dangerous to go alone"; Link doesn't have his sword to start the game
- Super Mario Bros.: Reusing assets; the bushes are clouds
- Super FX chip; the hardware design was led by software needs
- The Legend of Zelda: Wind Waker: Going between islands in Wind Waker, which avoided needing loading screens
- Super Mario Galaxy: Programmatic pitch matching with sound and music, even though they used a live orchestra
https://gist.github.com/vaguity/4326f26926dca18596e2
http://www.smashingmagazine.com/2014/11/21/why-you-should-include-your-developer-in-the-design-process/
http://www.smashingmagazine.com/2014/10/09/front-end-development-ode-to-specifications/
http://www.sitepoint.com/good-developer/
http://pivotallabs.com/best-practices-for-designerdeveloper-collaboration/
http://www.amazon.com/Designing-Web-Standards-3rd-Edition/dp/0321616952
http://www.sitepoint.com/versioning/
http://sidebar.io/2015/1/23
http://www.eurogamer.net/articles/2013-07-04-born-slippy-the-making-of-star-fox http://iwataasks.nintendo.com/interviews/#/wii/super_mario_galaxy/2/0