The Fundamental Rules of a Successful Designer-Developer Relationship
A designer working with a developer, and vice versa, is a great idea to speed up the website creation process, and it can also often times yield better final results for the project. Working together can let each professional focus on what they are best at, and what they also prefer to do - meaning both parties will enjoy the project a lot more.
However, designer-developer relationships can also be stressful if not coordinated properly. Developers, or the coders, may not envision what a designer had in mind correctly. Designers, on the other hand, may not see eye-to-eye with a developer on what's done easily, what's nearly impossible, what's less or more efficient, or what effects are almost unnecessary for both the user and time put in to code a particular feature. For many web people, being a Jack of All Trades is considered easier, even if the situation is not ideal.
Designer-developer relationships can be successful, though, and when they are, a project can reap all the benefits. Beyond the benefits of the project and work preferences of each individual, designers and developers can also collaborate, educate each other, and help each other network with other clients or individuals in the field. In this article, we're going to look over some of the core rules designers and developers should both follow if they are to have a successful designer-developer working relationship.
Work Together Throughout the Design Process
When many designers want to pass on the development stage, they complete the design portion for a client, and get in contact with a developer afterwards. They then expect the developer to just "make it happen." While most of the time developers can do what the designers asks of them, or at least something similar, it's not to say that it's necessarily the best solution.
Image credit: venessamiemis
Designers are great at making things look good, have an expertise in providing a good user experience visually, and planning for perhaps some developer-implemented visual techniques (drop downs, sliders, etc.). Developers, however, aren't just machines that implement whatever a designer wants. They know a thing or two about efficiency, and the user experience from a more technical perspective. They're constantly asking, "is this added feature worth the excess code and slower download times," or "what's the easiest and cleanest way to do this?" How a design is set up has a lot to do with how the backend of a web design works, so it's essential to plan ahead with a developer.
Through the design process, always communicate with the developer:
- Before the process even begins. The client knows what they want, and the designer has worked with the client to brainstorm a real solution with them. What's the developer's point of view though? What's the best solution, from a coding perspective, for the client? WordPress, a custom CMS, or just a static web page? What interactive features can help them reach their goal?
- Get input throughout the process. Is the general layout/wireframe a smart solution for the development solution planned? What would make it easier? More difficult? What design-related or interactive features are essential, and which are almost unnecessary to add on to the development costs? What's the time frame for certain elements added?
- Collaborate on a final review before presentation. Check for solutions, additions, and alterations together before the final presentation to the client. Then, go from there.
Does this mean to make the design as 'easy' as possible for the developer to create? No, developers tend to like a challenge much of the time. The point is, it can be great to collaborate on interactive techniques, interesting layout schemes, and more with developers to see how efficient it would be, or if the developer knows of smarter techniques that a designer can work around. It can also be good to communicate over what's technically possible or within the developer's skill set, and what is possible within the development timeframe.
Explain Features Thoroughly
The big bridge between design and development are all the interactive features that can go into a web experience. Bringing a PSD to life from a visual standpoint is relatively easy, but knowing exactly how dropdowns, hover states, sliders, and more should work needs more explanation. Some are self-explanatory, but don't assume it all is. Having clear documentation before the development stage begins is crucial otherwise the developer may have to keep going back to revise and edit. That only takes up more time, and creates further frustration. Help the developer get it right the first time!
Also, for PSD's, make sure hover states and the like are clearly labeled in respective layers, textured backgrounds and other essential patterns or imagery aren't merged, and etc. Having PSD's organized into groups of layers and paths also helps. Make the PSD as clearly defined as possible. If a developer, make sure to ask questions before assuming and getting it wrong!
Keep Open Communication
If something's causing a problem with a project, don't keep quiet and just work through it. Speak up! Let the other partner know what the issue is, and brainstorm solutions, or change the budget accordingly. Designers may not always know what features are going to take a lot of extra effort, and developers may not understand and overlook the importance of the tiniest detail in a design.
If a developer forgets something in a coded web page, let them know. If they don't understand the functionality of a feature, let them know, and collaborate to get it fixed or altered. If a designer has an overly complicated design for coding, but it's rather simple in design — this should be mentioned by the developer in the design phase. If the designer suggests a feature that is too complicated for what it's worth, developer: speak up!
Image credit: dailypic
"You didn't code this right!"
- Understand why the developer may have not done it correctly. Was it simply overlooked? Did they not see the importance and therefore went with an easier, more efficient way? More importantly: were they right? Is it that big of a deal? Or was it essential to the design?
- Explain why the feature or detail was important. Be sure to communicate with the developer as to why that small detail made such a big difference. It's a great way to educate someone who may not be as experienced in the design field, and since they don't see the purpose by themselves right away, you don't seem like a silly, obsessive nit when correcting them without explanation.
- Compromise on a medium. If something's not possible or more difficult to implement than you had thought, be open to compromise. Can this feature or detail be sacrificed? Can it be done differently? Can the solution of that design feature be solved by something else?
"This was not designed with the web in mind - it might as well be made for print!"
- Embrace a challenge. If it's just a new layout structure, something more difficult, or something you're not used to, it's not the end of the world. It may be more difficult, but embrace it as a challenge to learn how to code something in a new way.
- Discuss functionality thoroughly. If the functionality of a certain piece is unclear, speak up and get it clarified. If it seems really complicated for the timeframe and/or budget, let the designer know. Also speak up if you feel there's a better way, or an alternative way that you already know how to implement. The designer may be up for compromise.
- Educate designers on coding web standards and best practices. If something is really not adhering to a great user experience from a development perspective, let the designer know. It can change the outcome of this and future projects for something better.
Understand and Respect Each Other's Professions
A developer might say that a designer only creates pretty pictures, and gets to play around all day being artistic. A developer's job is an "intelligent, real job." In contrast, a designer might say that a developer has no understanding for the user experience and no appreciation for the visual aspect of a functional web page. They may complain that coders do not take designers seriously enough, or do just the opposite, and not take developers seriously enough themselves: "developers have no creativity, they just put websites together systematically like a machine - step-by-step; cookie-cutter; not a lot of real, creative thinking involved."
Image credit: adc
So what if a developer doesn't have great design skills, though? So what if a designer doesn't completely understand what smart code is, and doesn't embrace why it's important? That's what your own expertise is for, whichever side you may be on.
Obviously, there's a lot to both professions, and it's important for both designers and developers to respect that. They are different, but neither is more complicated than the other, easier, more creative, or deserves any less respect. So, in order to have a good relationship with a fellow designer or developer, try to understand what skill sets they have and need to do their part, and work with them by doing your part.
By also understanding the expertise of each profession, working with them through both the design and development process can become easier. A designer will know when it's best to come to a developer for an expert opinion, and vice versa. They'll know the limitations, and what they're likely to be great at. On top of these benefits, knowing and appreciating the skills of the respective partner also create for a much friendlier and relaxed working relationship.
Working together doesn't have to be difficult. Working together shouldn't be difficult. With so many benefits that can come from designers working together with developers, there's no reason not to try it out, and to try it out again even if there's been a negative experience in the past. Working together can help both a designer and developer focus on what they love to do, and what they're best at. Projects are better in the end, and clients are happier. Businesses can move along faster, and grow larger.
Feel free to share any experiences, negative or positive, from teaming up with another web professional in the past. Was it worth it, or could the experience have been improved?