Why designers and developers should talk more
Designer-developer communication improves product team efficiency. When designers and developers spend more time communicating, it’s easier to keep constraints on top of mind. Designers can also improve their process to ensure the developer can easily understand their decisions and ultimately can create a frictionless experience. There was a time when the roles of the designer and developer were siloed. They worked independently without much communication. This day and age, designers and developers should be communication about product decisions on a weekly basis at a minimum.
Keeps project constraints top of mind
In all reality, the developer should be participating in the entire design process because they can share valuable feedback about a project’s design. Developers can tell you if a feature, interaction, or animation is complex or simple to implement. With that said, regular designer and developer communication help ensure that projects adhere to their constraints.
At Standard Beagle, we have weekly design reviews so the designers and developers can showcase what they are working on and communicate improvements. The weekly review allows for either party to bring up issues, questions, concerns, or to gain feedback. As a designer, it provides a forum for me to figure out whether my design fits within our allotted constraints. It provides an opportunity to clarify how a feature should look and function.
The feature complexity conversation is important as it keeps a project within its constraints. For example, a homepage animation could require several days of development time. Even a modal window can take up to a day to implement. Something that may seem easy from a designer’s point of view may actually complex and time-consuming to build from a developer standpoint. On that premise, designer and developer communication ultimately saves time, prevents stress, can eliminate frustration, and keeps a project within the constraints.
Improve the developer handoff
It can be a common fallacy that the designer to developer handoff simply includes exporting images and sharing the redlined files with the development team. In reality, a smooth handoff requires much more. From a designer’s standpoint, preparing for the handoff starts from the moment we begin wireframing. Once the designer transitions into their tool of choice, the intentions of the product should be communicated. The way we group layers, label components, define text styles, and color styles matter. You need to properly annotate, redline, and label components, organisms, and templates.
Common hand-off best practices
- Use appropriate text styles and colors
- Label every atom, molecule, and organism
- Never leave a layer unlabeled
- Use consistent naming conventions
This is important because the developer often uses a designer’s naming conventions to influence their class and ids in their code. For instance, Figma allows developers to click through design to see the different layers. Therefore, if the document is created properly, they can easily understand how to organize their code just by exploring the design. To learn more about Figma can improve your workflow, check out the post, How Figma Streamlined Our UX Processes.
The importance of a style guide
A style guide essentially is a roadmap that the developer refers to during development. This is a crucial document that should be included during handoff. It clarifies ambiguity in the mockups and guides code decisions. It communicates the style of UI components and provides a platform to identify inconsistencies in varying elements. Having a style guide allows for a developer to build varying components before tackling templates or layouts. Essentially, the style guide provides a platform to create global styles that can be implemented throughout the development process. The result is a cleaner codebase, fewer bugs, and a happier development team.
Think through the functionality
The functionality rationale should be included in the handoff. This is especially important when designing and developing within a content management system (CMS), like WordPress. When designing for a CMS, a designer not only should think about the client’s end-user but also how the client will interact with the admin dashboard. In those instances, the designer has two users to consider. While designing, be thinking about the following questions to ensure functionality is being considered.
- How is this going to work?
- How will the user interact with the interface?
- What is the intention behind this decision?
- Could this work with the CMS?
When making design decisions, it is important to keep those questions top of mind. Considering the impact on final implementation while designing allows for decisions to be mindful. It also helps prepare for the handoff conversation because it helps identify the ‘why’ and ‘how’ to the development team.
