Design + Development: Tips On Working Together

As a Frontend Digital Designer here at Rocketmakers, I have a foot in both the design and development teams. At the moment I work mostly in Visual and UI Design, but over the last five years I've learnt lots about how design and development teams can work together more effectively, so I thought I'd share some tips.

🗣 Communicate

Always talk to each other. 

Good communication makes for good results, and avoiding miscommunication between the design and development teams is really essential.  As you get further down the line in a product build, misunderstandings often result in problems that are expensive and waste valuable time.

It’s important to keep an open line of communication between the design and development teams so that everyone on the team can understand what’s happening at any given time. 

At Rocketmakers, we use agile methodology, we find our daily stand up meetings to be paramount for maintaining communication, and allow us to address any issues or blockers quickly and effectively as a team. 

It’s important that designers are able to share ideas with developers so they can understand the gravity of design decisions and the feasibility of building features. On the other hand, developers need to be able to express technical concerns and clarify functionality from the design team in order to build the product effectively. 

From my experience, collaborating and sharing ideas from both design and development will help create a better final product. 

🤝 Trust each other

It’s impossible to communicate every single aspect of an application between design and development, so you will need to trust each other.

As a designer you need to communicate the visual design of the product and inform the development team of the interaction design. It’s not within a designer's responsibility to tell the development team how to execute the designs. 

Likewise, as a developer, it’s not your responsibility to tell the designer how to design the product. Although your input on technical feasibility and effectiveness would be useful, it should never stretch to giving personal opinions on the visuals. 

You’ll need to trust the design team to create a design that is fit for purpose and meets the client’s brief and expectations. Then it's over to the development team to execute this technically. 

📜 Make rules

The best way to define a set of rules for the visual design is through a style guide. 

An informative and comprehensive style guide is important for all of your team to reference. It should give your developers enough knowledge of the project's brand that they could create a new page or section in an application that fits the brand's guidelines. It can even help other designers onboard onto the project and contribute to the visual design seamlessly.

For developers, the style guide should directly inform the reusable variables in the code. Using variables in development will help standardise the frontend design, and when used correctly this allows that elements of the brand to be updated easily following a design change. 

An accurate style guide which everyone follows creates consistency across the application, from fonts, to sizing and brand colours. It should include any design rules the designer would like the developers to follow. A secondary benefit to a style guide is that it can be referenced by the clients for materials outside of the application we’re building, like social posts and marketing. This helps align a consistent brand identity across platforms, which is important for creating an effective and memorable brand. 

♻️ Reuse 

Reusable design elements should directly translate to reusable code. It’s generally the rule that developers shouldn’t have to write the same function in code more than once. That same approach should be applied to design.

Wherever possible in the design phase, reuse components and visual elements. Not only does this help create a consistent and scalable visual language but it will decrease the effort required for the developers to build the application.

If direct duplication isn’t suitable, try to include variations of a component that shares the same baseline component but has slightly different styling or content configuration. 

An example of this might be a content slice that has the image on the right, and you need a variation with the image on the left. This would be easy enough for the developer to configure as a property of one reusable component (as long as the content and general styling was the same). 

🔍 Details, details, details

Throughout the process of building a product there will be an endless amount of detail. 

It will be too much to remember, so it’s a good idea to keep notes. Whether you’re in the initial client’s specifications meeting, or at an internal technical meeting, keeping track of the features and specifications is important. 

As a designer, you can relay these details as annotations on your screen designs. Even if it seems obvious to you where a button goes, for example, using explicit annotations will save the developers time in the future. As a rule of thumb, annotate your designs whenever there’s an animation, interaction or general expected behaviour - even if it seems obvious. It’s much quicker to annotate your designs than to explain the functionality to the developer as they build out each page, one by one.

As the designs are usually the “source of truth”developers use to  build the product, this is a great place for explicit clarification via annotations. 

Later on in the build process, a lack of clarification and the resulting confusion could cost valuable time, and ultimately impact client satisfaction.

Interested in finding out more? Take a look at some of our design-led projects.