Bridging The Gap Between Design And Development

The rift between design and development is the rift between two different ways of solving problems, within given constraints. The design team aims to accommodate a vast number of factors including visual appeal, accessibility, usability, and context within a single solution so that the most substantial number of users will feel at home with the product. The development team aims to direct the complication and subtlety of the algorithm to the same set of users so that they can use it as effectively and efficiently as possible.

Both the domains of design and development are in many ways explorative in nature. There is a perpetual state of learning and discovery. So shouldn’t there be more harmony? Why do so many companies find it hard to integrate these two domains? The difference in their approach to solving problems is where the issue lies. The design should be user-oriented, focused on how every aspect of the product will affect its users. The development must be solution-oriented, focused on the problem’s constraints and how to eliminate what is not going to be a part of the solution. And both believe that theirs is the way to solve a problem. The design team will argue that a product shouldn't be merely about solving a problem and the development team will argue, focusing on the people is not actually solving the problem. Both need to be right and both are right. The mathematical, systematic and exclusive process of a developer is just right for solution-centered algorithms, and the flamboyant, complicated and inclusive process of a designer is perfect for user-centered solutions.

So how to get both teams on the same page?

It’s essential to begin by understanding everyone’s limitations so that conflict doesn't arise from ignorance. In big projects, designers are generally the ones who choose to implement complicated features that developers don’t have the means of creating yet. This puts the developers in a spot. Conversely, developers may not understand why merely because something is technically possible it might not translate well into a good design. To avoid such situations, both parties need to recognize those limitations. Increase knowledge among both groups by encouraging the sharing of basic concepts and skills. Help increase your developers’ awareness of design by sharing info with them on the basics of design and how graphic design elements are used. Maybe offer certain resources for your designer team on the basics of coding so they understand better whether if their ideas can be translated easily into code that’s workable or not. Increasing knowledge mutually can also result in more communication among the team and minimize misunderstandings.

Failing to communicate well could result in misunderstandings and even various interpretations of the same general goals. One way to bridge the gap between developers and designers is to bring developers into the scene when designers are getting started. This doesn’t mean developers must become a distraction and hoover. Make your developers part of early steps like the conference calls with clients, run design ideas through them so you can identify any issues with code early while it’s still easy to make design adjustments and seek insights from developers on how design elements would likely translate to a web application.

Streamline all communication. You might have developers who like to shoot off email updates at the end of each day and a bunch of young designers who prefer to text project updates instead. Some major members might be unintentionally left out of the loop, and some messages may be missed with numerous forms of messaging going on at the same time. Use a channel that’s dedicated to this and establish guidelines for communication. For instance, share email updates with everyone at the beginning or end of each workday.  

Then ensure the handoff from designers to developers is as orderly, organized, and comprehensive as possible. So developers won’t have to do such work on their end before getting started, properly organize design files, based on page sections label each layer and group layers clearly. Contact developers to go over the designs, after the handoff. This allows developers to ask clear any doubts they may have before they begin and finer details to be clarified and explained.

Be just as prepared with the handoff from developers to the quality assurance team. Unexpected issues like having the webpage and the design not being identical may be discovered. This might require some work on both the developer and designer end from things. Small problems like images not aligned correctly even, during the QA phase, can slow things down.

And remember, communication is culture first, tools next. Have an open culture of easy communication. Anyone must be able to reach out to anyone within an organization for easy information flow. Put everyone who is working on a product, together rather than having everyone off doing their own thing with their fellow developers or designers. Physically put members working on the same function together in the same space, if possible. To make everyone working together feel comfortable, maybe even encourage them to share lunch sometimes. Setup virtual team meetings using dedicated communication channels so ideas can be shared and concerns can be discussed as work progresses, if you have developers and designers in different physical locations.