Different teams will have different ideas and perspectives of what the final product should be – designers and developers often have different thoughts on the best direction forward. Each group also has a different set of skills and capabilities that are important to creating high-quality products. In the end, pulling the best ideas together and finding consensus across teams is important as we create high-end experiences together.

So how do we succeed in this inherently subjective world of design and development? One solution is fostering good communication between design and development early in the process.

Conditions of Communication

Start communication early

This may mean that the designer brainstorms an idea and then links in the developer, or they may involve the developer from the start of wireframes. Either way, having design pass ideas through development helps to ensure the work will be a viable solution, and allows time for the two teams to innovate on issues along the way. It also helps keep the project within the time frame, budget, and skill level of the team members doing the work.

Set up checkpoints along the way

Each major phase of the project should include a checkpoint between the teams before a key milestone is finalized (or sent to the client in our case). This helps foster a creative and collaborative team environment, while leading to a greater understanding of the project as a whole. While the designer is working on their part of the project, the developer can already be thinking about theirs – maybe even getting a jump start on the project. After the design is mostly done, and the developer is releasing milestones, the designer may also be involved in reviewing work. Checkpoints can go both ways.

Keep team communication going

The designer’s job does not end when the comps (mockups) end, the same as the developer’s job does not start when the comps are finished. The developer should be active in the design phase, and the designer should be active in the build phase.

Tips on Working Together

Reviewing wireframes and comps

Have a sit-down between the designer and developer, in person if possible. The designer needs to walk through all designs with the developer and explain how each interaction works, providing examples if available. Even simple concepts should be discussed – as mentioned previously, designers and developers can have a range of skills, capabilities, and knowledge. It’s vital to ASK QUESTIONS throughout the sit-down, otherwise, it will be assumed that everything discussed has been understood by both teams.

When design discusses their ideas with development early, a few things happen:

• The developer has input on layout and functionality early, rather than being surprised by it later.
• The developer can help bring up issues the designer may not see.
• The developer will have an idea of what they are committed to coding before others see it, becoming part of the internal approval process.
• Both teams gain a greater understanding of the process from the other perspective.
• The designer has more confidence that their idea can come to life as they continue designing.
• The designer has a better understanding of limitations and constraints they need to solve on the next project, and how responsive and adaptive layouts will scale.

Keeping the developer in the loop gets them thinking about the layout and functionality before starting the build. Start this conversation BEFORE clients review the designer’s work; it is not ready to be reviewed by the client before it is reviewed by the developer. The designer will look to the developer to “approve” a wireframe or comp, with the understanding that the approved layout can be built as intended by the designer.

Responsive is important – understand how a responsive environment affects layout

There isn’t always the time or budget to create wireframes and comps for every layout; however, there is time to think about how layouts for one device will function in an ever increasing device-agnostic landscape. How will a desktop layout function on a mobile device? How will a mobile layout function on a device where we may not know the exact size? What about when a new iPhone is announced – will the layout still work? Make this part of the conversation when the designer is discussing wireframes and comps with the developer.

Designers need to: 

• Be ready to explain how images will behave on different browser sizes.
• Have a solution for complex layouts in a single column device.
• Collaborate with the developer to determine when a layout will look best, and adjust what predetermined points the layout may change.

Be ready to answer questions about how something functions

Know why and how something works; don’t be just satisfied knowing that it works. The designer should be able to explain every aspect of the design to the developer. Assuming it’s clear based only on a wireframe or comp will ultimately leave the developer guessing how to fill in the details—resulting in a designer receiving a build that might not match their intentions.

If functionality details are still being worked out, the designer needs to let the developer know. Collaboration between the teams will help create new solutions that may not have been previously discussed.

Understanding why something DOES NOT work is a starting point to where a concept can be creatively adjusted to work well and save time. Small tweaks to a concept can have a huge impact on development time and budget, yet still maintain the integrity of the goals of the intended design.

Developers should understand intended functionality before letting a designer know if a layout will work for the project. The designer should initiate the conversation, and allow the developer some time to ask questions to better understand. If a solution won’t work well in development, the developer should let the designer know why, and ideally bring solutions to the table for both parties to collaborate forward.

Asking if it CAN be built is only half of the question

In reviewing comps or wireframes, a designer may first ask if something can be built. What is really being asked is, can this be built within the scope, timeline, and budget constraints? Anything can be built with enough time and budget, but most projects do not have the timeline or resources to go blue sky. The designer’s job is to create solutions that fit within constraints. After all, creativity still thrives under constraints.

Stay involved in the project after designs are complete

The designer should remain approachable for questions from the developer even after the design phase is complete. Even with good documentation, there will ALWAYS be questions. The designer should periodically check in with the developer to see if any new questions have surfaced, much like the developer is periodically collaborating during the design process.

Work one-on-one for quick build fixes and reviews

Keeping the designer active during the build phase allows for quick, on-the-fly reviews and bug fixes that can go directly into development, saving time. The designer should detail out larger and more difficult bug fixes for the developer: sketch, create visuals, keep a log, use a task management platform like Asana or Jira…there are methods to help keep track of fixes needed.

Remember both teams are partners in building great experiences, encouraged to voice their expertise

The best solution is not always the quickest or easiest solution. Find a balance between client needs and goals, timing and budget, the best solution and right solution.

• Designers need to stay open-minded, ready to brainstorm new solutions with developers if the developers express concern over functionality. Pulling in other designers or developers for brainstorming also adds a fresh perspective. New perspective means producing new ideas or innovating an established idea.
• If a solution doesn’t work for the development team, they should let the designer know why, along with what can be changed to fix the issue.
• At the end of the day, both designers and developers are consultants. If it makes sense to propose a new solution, they have the ability to figure out the added effort it would take, working with the project management team and the stakeholders to update the project scope.

Ideals vs Actuals

There are some instances where this collaboration process breaks down. Designers don’t always have access to developers on their project or vice versa. What if the developer is part of the stakeholder team and only the designers are in-house? How about if the designs were created by another company, but development is in-house?

The solution here is to express the need for close communication and explain its benefits. Use as much of the process as possible, and tailor it to the specific project.

Conclusion

Designers should review wireframes and comps with a developer before client review. Developers should point out any issues with a concept that might affect budget and scope, and help offer solutions and alternatives to ideas if needed.

Designers should think through how a layout will behave in a resp

onsive environment, and be ready to discuss the full layout and functionality with developers. Developers should be active in the project at this stage.

Designers should be able to answer any questions about functionality and responsive layouts when talking with developers about their concept. They need to know HOW AND WHY SOMETHING WORKS, not be satisfied just knowing it works. Developers should leave conversations knowing the direction the designer is going with the project.

Designers should remain an active part of the project after the design is done, working with developers to review builds, log bugs, and suggest change.

Designers need to consider what the client can afford to build when they begin creating design concepts, but not be afraid to push the boundaries of design and development.

Ultimately, designers and developers are co-creators. They brainstorm and concept ideas together, review builds and make changes together, and remain active participants in the project, even after each’s portion is complete. We build better experiences when we communicate, collaborate, and work together.