Developer’s Tale: of Design Education and Interactive SEALs

picture of compressed code

No one said enterprise-level design was easy. But few realize how much of a difference good collaboration and communication can make especially between designers and developers. While sometimes they seem to live in different worlds, their common goals put them firmly on the same team.

We talked with web developer Chad Wooten of GDC Marketing and Ideation about working with designers in an enterprise environment. With more than 20 years of experience in web development, systems administration, and graphic design, Chad approaches projects with careful attention to both technical development and creative execution.

Because of his hybrid background in front-end and back-end development, he has wide-ranging and valuable insight in regards to UI/UX testing, responsive design, and digital best practices.

How is developing for enterprise customers different than smaller companies?

There are more layers for approval so you have to be very conscientious about timelines. Testing takes longer in some circumstances because of an overzealous IT guy.

What information is often missed at the beginning of a project with a major client? What do you wish you’d known later in the development cycle?

In my experience, the little things get overlooked. The client loves the design on paper and they don’t think about hover states or the interactivity. It is also hard to communicate the subtle differences in UX/UI on a mobile device for responsive sites. Like the lack of hover states, etc …

What miscommunications have you encountered when working with a design team?

Because I work in a traditional advertising agency, most of the designers I work with are used to print design or broadcast. This leads to missing interactive function in the design. Animations are hard to convey on a print out. Sometimes little changes in the visual design are huge changes in the code and sometimes the opposite is true. Communicating the differences can be a challenge and may lead to designer shell shock if you are an aggressive developer. 

I have a background in IT so I am used to many questions that I consider to be trivial but the user is truely clueless. You can either get annoyed by this or you can embrace their curiosity and use it as a teaching opportunity. The same holds true with development. Questions that seem simple to the developer may be completely Greek to a designer.

“You can either get annoyed by this or you can embrace their curiosity and use it as a teaching opportunity.”

One time I developed a site that needed a “simple” webform. They just wanted to collect a user’s information with four basic questions: name, phone, email and zip code. By their answers, specifically the zipcode, they would receive information that was geographically based.

The simple change they requested was stated, “Can we have them fill in their zip code first and, based on this information, have a form that routes to a specific person?” Uh, yes, that can be done, but it is more complex than a “simple” webform.

How early do you think developers should get involved in the design process?

Developers should be involved from the brainstorming on and there should be regular check-ins to ensure the designers or the client aren’t encouraging scope creep.

What advice would you give developers about making design decisions? How about clients or managers?

Keep the budget in mind and know how long it will take to achieve the client’s goals. Don’t be afraid to give your opinion on the design but remember the designer and the client are in charge if the design. Like it or not, we are in a service industry and we are here to develop, not to design.

What should developers know about design?

This is a tough question. Developers should have an open mind about design. I think they should have a basic concept of good design. They should be able to spot good composition, know about the “rule of threes” and understand the concept of negative space.

On the other hand, designers should know basic programming concepts. On the favorite team I was ever on, we liked to think of ourselves as interactive SEALs. We all had our specialty, but we knew enough about each other’s jobs that we could do it if that person was missing in action. That is an effective team model.

What do you find rewarding about working in an enterprise environment?

The larger and more recognizable the brand, the better your resume will look. The code isn’t always more challenging but there is almost always more of it, haha. I thrive on working under pressure and large clients love last-minute changes.

And, above all, when your friends and family say, “I just went on so-and-so’s website and it was so easy to use” and you say, “I developed that @&#! site!” Well … yeah, that’s awesome.

If you were in charge of an enterprise-level project, what would you like to change?

I would have an initial meeting with the client that involved everyone on the team. I would make sure there was complete agreement on the intent and scope of the project before it started on all sides. I would make sure there were regular team check-ins to ensure the project was on track and within scope.

I would also make sure that once the mobile and desktop design was complete, the developer and designer hashed out all of the interactive elements before client approval. Finally, I would make sure to hold regular developer/designer check-ins during the programming to ensure creative integrity.

Quote: Ben Gremillion
Source: UXPin