<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content

By David Wierbiki

Mindset of the Two Groups

Developers and designers have two distinct goal sets in software development. The developer is concerned with databases, platform code and meeting the business requirements for the project on schedule. If they use HTML tables for user interface (UI) layouts, that is alright by them. A designer's focus is to give the end user a visual wow factor, and meet the business requirements for the project on schedule using cutting edge HTML/CSS/JS. These are generalizations, of course. Plenty of developers are equally interested in the visual wow factor and enjoy being a part of that. And vice-versa, some designers expand their aptitude set to include having a firm understanding of platform code.

The mindsets are distinct and unique to each group, with crossovers between domains being rare. Clashes over what is most important for a project are not uncommon, but they both have one common goal: meeting the business requirements on schedule. Is that it though? Is that the only reason they are able to work together for (potentially) years on a single project? Surely there are other bonds between these two camps.

Establishing Boundaries

Like a junior high school dance where the boys are on one side of the room and the girls on the other, no one wants to take that first step to the other side and look foolish. As adults, many never move past that innate behavior. I have had some truly great mentors over the years. The most important thing that each of them has taught from day one is to just ask. There are no poor questions worth feeling foolish over from those who truly want to know and will take what you teach them and run with it. You may be amazed at how receptive people are when you ask them for help.

From the designer camp, we rely on the developer to help get our platform environment up and running – at least initially – and/or to fix it when we break it. A good designer can work in any platform's IDE to massage and manipulate the platform's code to inject their HTML/CSS/JS as needed. Over time, we gain some valuable insight into how the specific platform's code works by recognizing patterns and eventually just picking up little tricks here and there. While designers are primarily visual in their day-to-day workings, we are able to think in a logical manner no matter how much cerebral hemorrhaging it causes. It is a skill we need to learn early on and need to realize that it is something to continuously cultivate to survive in a developer/designer world.

A typical developer either does not know or care about how the UI is done, just so long as it happens. This is evident with the use of inline styles, tables for layouts and gigantic images given pixel dimensions so they fit where they want them. Another generalization, but more common than not. Generalization or not, a rational developer will jump at the chance to work on a project with a seasoned designer who knows how to move around in their specific platform's IDE.

For the most part, the roles of designer and developer are pretty straightforward. But at the onset of any collaborative project, the designer and the developer need to sit down and understand exactly who is responsible for what, and this is based largely on the designer's level of experience. Is the developer handling some or all of the JavaScript? Is the designer comfortable in the platform's IDE? Are they ready to identify when something requires them to work in tandem and not step on each other's proverbial toes?

During the course of the project, the daily SCRUM can identify collaborative needs as they arise.  But the true collaborative efforts rest on the shoulders of the designer's capabilities. Software development is a developer’s world, to be sure, but the designer is critical to the project’s success. If the product doesn’t look great or is not intuitively usable, then the project as a whole suffers - and that is completely avoidable.

Not all designers are created equal... at least not initially

For the purposes of this article, there are three levels of designers. Level one is where they all start – creating Photoshop layouts that can be handed off to a developer for cutting up and implementation. Level two is greatly coveted by a developer because they have taken the time and energy to work in a platform’s IDE and take their Photoshop layouts, cut them up and implement them in and around the workings the developer has placed in his JSPs or ASPs (just to name the top two). The level two designer can implement their design, test locally and push their changes into source.
There is typically one of two catalysts for becoming a level two designer. The first catalyst is usually just sheer curiosity and possibly pressure from a developer to do more. The second catalyst is frustration over the design being butchered and poorly implemented after hand-off to a developer. In either case, the developer, team and project ultimately benefit.

Level three designers are capable of everything from level one and two, but can also completely manipulate the UI through a JavaScript library and possibly perform some minor platform-specific coding.

Why are they a match made in heaven?

We all have our strengths – things we excel at and for which we are known. Developers and designers may have different mindsets, but they share a common goal. They need each other to accomplish that goal effectively. The designer needs the developer to work the back-end and platform-specific code, and the developer needs the designer to make it all look amazing. Sure, either has the potential to perform the other's specialty. However, the old adage, "just because you can doesn’t mean you should," comes to mind here. Years of study and experience go into each field of work, developing expertise with their respectively honed skills, and a great deal of respect between the two is bred over the years of working together. Peace-of-mind, focus and a clear sense of purpose allow the designer and the developer to grow in their respective fields without having to worry about the details on the other side of the fence.

See More From These Topics