In continuation of yesterday’s post, here is Part II of “Develop/Design – An Enlightened Discussion”.
Where does the designer’s job end, and where does the developer’s job begin?
At many companies, designers are given the responsibilities of handling all HTML & CSS work, then hand the work off to developers to complete the back end. Here at Enlighten, however, designers provide developers with a .PSD of design work, and the developer handles the front-end development process from there. Andrew noted, “For me, writing the CSS/HTML puts my mind at ease because I’ve designed the piece, I know where the pixel by pixel detail is important, and the visual translation to code is my responsibility. I’ve been hesitant in the past handing off my designs to certain developers, with worries that their attention to detail won’t be in tune with mine.” This is a valid concern, especially for the detail-oriented designer who is confident in the CSS/HTML skills.
Developer Mike Behnke weighed in with his own thoughts on the subject: “Part of the advantage of having the designer do the CSS allows for quick fixes to be made when things don’t work quite right in the browser.” He continued by explaining that, “A lot of times, designers have the ability to make slight adjustments to the comp in order to make the CSS fit or work better.” At times, developers can get ahold of comps that have already been signed off upon by the client, requiring strict adherence to the image that has already been approved. “One of the things that drive us nuts,” he continued,”, “is when you get a PSD from the designer and there are inconsistencies in a layout.” This causes the developer to have to make assumptions as to what the designer envisioned for the work. Later on, this guesswork can prove to be incorrect, “but it’s because there were inconsistencies in the designer’s layout.”
As for Karen, “I can see advantages in the designer doing none of the development, because as a designer, if you have to code something that you’re designing, you may restrict your design to something that you’re comfortable coding.” This seems to reflect an earlier point made while answering the first question. It seems that these ideas are somewhat intertwined. “When you have developers,” she continued, “they have more time to dump into putting everything towards making the project perfect.” That said, no one should take Karen’s statement as an attack on the quality of work that designers can provide. Karen believes that accepting work from designers is “really something we need to be sensitive about. We’re taking someone’s vision and bringing it to life, which is why it should always be important to work closely with the designer, because only then can you come up with something that you’re both happy with.” Even when adjustments have to be made, “the designer’s vision is still realized even though you have to adjust for the browser and its limitations.” Mike B. agreed with this assertion, including that “it’s so important to keep [designers] involved through tiny changes and tweaks, even if it’s just a header color change.”
In continuation, Designer Mike McGowen asked, “If you’re moving away from your specialty, are you cutting off the knowledge that Karen or Mike might be able to bring to the project because you’re coveting the power?” Karen quickly responded, “Yeah, the projects I’ve come away the happiest from, they’ve been prototyped again and again with designers. There’s a lot of satisfaction to be felt there. It pushed us forward.” She continued in posing an insightful and important question: “How can anyone know what’s possible right off the bat?”
It seems that the cooperation between designers and developers is absolutely essential in gaining understanding of just what is possible between the two groups. At Enlighten, we are fortunate enough to have incredibly talented minds working together to form inventive, bold, and exciting work for our clients. What’s more impressive than watching them work independently, however, is observing them as they work in tandem with one another.