Skip to main content

By Jesse Schutt

Design + Development

When I joined Zaengle at the beginning of 2015, I became the third full-time developer on the team.

Prior to that, I wore both a designer’s and developer’s hat as the internal tech person for a non-profit. Though I enjoy being able to focus entirely on development at this point, I’m grateful for the years I was required to design because it provided me with a better understanding of the unique skills it takes.

Bringing design in-house

In May 2015, Derek Nelson became the fourth team member at Zaengle, and the first non-developer. He brought with him a host of commercial advertising experience as well as a solid background in web design. Before Derek joined us, we relied primarily on external relationships with several talented designers. This worked well, but as we looked at our skillsets, we realized that it was time to bring design in-house.

There’s no question that having a designer really rounds out the team from a ‘we can do it’ perspective, but I think internally it’s valuable to have someone really advocating for visuals. It’s bumped up the quality of our work several notches.

- Philip Zaengle, Owner - Zaengle Corp

What we've learned

After more than a year of design and development working closely, here's a few of the lessons we’ve learned:

1. Don't just throw it over the fence

Traditionally, there has been a great chasm between the disciplines of development and design. Although that gap has closed in recent years, the tendency to pass off a design to the development team and say “make it happen” still exists.

2. Understand what’s possible - from both directions

Developers: raise your hand if you’ve ever been tasked with html-ifying comps that came from an old-school print designer… (raises hand slowly). Did you enjoy the process?

I think the reason that is such a frustrating experience is because one party doesn’t know what is possible in the other party’s realm.

Designers: do your research. Try to understand what you are asking from developers when you draw that multi-gradient, circular, animated graph. And as much as you may dislike it, the web is still constructed in boxes.

Developers: yes, it’s up to us to take the PSDs and do our very best to represent it in code. It’s up to us to make static pixels do something. Remember, designers don’t hate us! They are attempting to translate the project goals into colors and shapes, not make us miserable. Believe the best about each other.

3. Respect each other's strengths

Both designers and developers must possess certain skills and traits in order to be effective in their fields. It is so valuable to recognize and respect each other first as human beings, and second as individually gifted, even if you don’t completely understand (or agree) with everything.

I’m frequently impressed with what Derek envisions, not only as visual solutions, but also with his ability to understand and anticipate what a user will experience on a given product. As a developer, I’m thinking about how I will solve a problem from the technical level, while Derek’s strengths allow him to approach the problem from an entirely different plane! It is these stark differences between us as professionals that make the end product all that much better.

As James Archer puts it in his article on design/developer collaboration: "...we’d all do well to remember that both sides bring an incomplete set of answers to the table."

4. Ask questions & give feedback

Because we possess such different skill-sets, it’s been very important to communicate frequently. Derek has been a terrific example of fielding feedback without getting defensive. I trust him to hear me out, and he trusts that I’m not just nit-picking tedious details. I know he’s got the visuals covered, and he is flexible when I raise issue with design elements that don’t work well on the development level.

Bonus! Establish project styles

One area that we are continuing to explore at Zaengle is that of overarching project styles. Our typical flow has been to have Derek design top-to-bottom comps for nearly every view of a site. We realized that even with that level of care, inevitably the developers will need to add or modify something. So now we are attempting to work off “project styles”, which is a collection of elements that are all themed for the project. I’m able to grab components, like modals, or buttons, and drop them into the visual framework Derek has established.

Community advice

I posed the following question and received several helpful responses:


"Focus on regular and clear communication without micromanagement. Combine that with total ownership in your particular area of responsibility, and over time you will develop a shorthand that will let you break all the "rules" and find true productivity."
Jack McDade (Founder, Wilderborn)

"Be open and flexible with each other, which is basically key in all relationships! I think sometimes one party tries to be the end-all on decisions and that can kill the mojo for the designer or developer."
Bill Kenney (Co-Founder/Creative Director at @focuslab & @madebysidecar)

Conclusion

High Fives

Over the past year, I’ve witnessed firsthand the strength of Design + Development. I’ve coded myself into a corner, only to have the creative thinking of Derek propose an elegant solution. I’ve been able to give feedback on visual designs that would require significant development overhead and be met with gracious responses.

These concepts aren’t new, in fact they are as old as humanity itself! Check out this ancient advice on working with others:

"Two people are better off than one, for they can help each other succeed."
Ecclesiastes 4:9

Want to read more tips and insights on working with a web development team that wants to help your organization grow for good? Sign up for our bimonthly newsletter.

By Jesse Schutt

Director of Engineering

Jesse is our resident woodworker. His signature is to find the deeper meaning in a project and the right tool for the job.