I recently contacted Jay David, Interactive Creative Director at TOKY (St. Louis), regarding the working relationship between designers and developers. Jay’s work has always been inspiring to me, so it only made sense to contact him first. In many cases, these teams have different points-of-view and approaches to making work.
Here are his responses:
1. When you work with a web development team, what do the developers expect from the designers?
Detail. The most frustrating thing I hear from developers when working with designers is the lack of attention to detail in how the user interface works (not the design details). Designers sometimes slave over a design and get it just in the right pixel-perfect place, but then quickly realize that it all falls apart when it gets built and used by real humans.
- Developers want a plan for worst case scenarios: What happens when someone enters too much text in an area you designed? What if the client uploads a vertical image in an area that fits only horizontal images?
- Developers want a plan for screen sizes: It’s a rare developer than can just assume what you want to happen when someone looks at your site on a tablet or phone. Design as many screens as you can within budget. In a typical project we will design all desktop and mobile versions of the site, and a few key pages on tablet. We’ll also mock up how navigation changes at several breakpoints.
- Developers want clean files: If you’re working in photoshop, developers love clean files, named layer sets, layer comps, rollover states, etc.. Especially helpful would be mocking up a few animation examples in something like Keynote or After Effects. There are a lot of other tools out there that can help to prototype. We’re also big fans of using Invision to work through the design process with our developers.
- Developers want a design spec or a style guide: This is something we do at the tail end of the design phase on all of our projects. We develop a document that explains how all components of the site will be used, how they will interact, and what type of content restrictions there are. Developers (and clients) review this and sign off before the project starts so they have a clear understanding of what is about to be developed. This could be a time consuming process, but we’ve found it to save future development headaches that could blow a budget.
- Developers want communication: (This one can be tough because many developers can lack in communication skills.) We try to involve our developers at many points in the beginning parts of the project. The best experiences we’ve had have been when developers have an active role in brainstorming functionality and are available to set realistic expectations on how things will work. If you don’t yet know who will be developing your site, save references, links, or code demo sites that help articulate what you’re trying to do.
2. Obviously, a designer needs to be web-savvy to a degree, but how deep should that knowledge go?
3. What makes developers want to smash the wall? What should designers know/do to keep things running smoothly? (That’s a big one, and probably difficult to answer.)
Developers are usually last in line of the web design process. They’re the ones that no one really understands what they do all day (or why it takes so long). They’re also the ones who feel the pinch when everyone else before them blew their deadlines in the process leading up to where they take over. The number one way to keep things running smoothly, in addition to meeting your deadlines, is to communicate. Ask questions, see if they have a better way to come up with how something could work. Make sure what you’re designing will not overcomplicate the development process. I’ve seen this countless times: A designer comes up with a beautiful solution to a problem – but it’s never really been done before – therefore you burn through several developers (and the budget) before you end up having to simplify key parts of the interactions. A lot of project headaches could be solved if you just present your work to the developer: Talk it out, walk them through the process and how things work, and listen to their concerns and ideas for how to do something that could achieve the same goal.