Communication between developers and designers isn't always easy, especially if they work in separate teams and the infamous silo effect occurs. How they work together also greatly depends on the type of company.
For example, working in a company that has a single product you can work on day in and day out is completely different than working in an agile environment, such as SpiceFactory, where you have to juggle multiple projects and deadlines at the same time.
Before we dive in into the the topic, let's visualise the problem first. Here, we have two shapes that barely touch each other.
If we zoom in a bit, we can see that there is a gap between the two.
A lot of information, time, and money is lost in this gap. Hopefully, by the end of this post, you’ll have the knowledge you need to bridge this gap and improve the flow of information between the designers and developers in your company.
Following are a few important observations about designer/developer communication that we made by working on many projects in SpiceFactory.
Bad implementation is usually perceived as bad design
If you show an application that is half-finished and looks a bit off to your client, they will most likely think that the problem is in the design and not implementation. This brings me to the next point:
To the client,
interface = design = product
If design is not quite there yet, it is always better to show your client a bare bone app that looks nothing like the design. This way it will be more obvious to them that it does not reflect the design.
Everyone can design(?)
This is true. Everyone can design, but not everyone can design well. Requirements change all the time, deadlines are tight, and it is always easier for a developer to just make the call on where to put that button or feature without consulting the designer.
Sometimes this works out well, but sometimes it’s like throwing a monkey wrench in the cogs of design. Especially if there is a build-up of improvised features and interface assets that the designer needs to (re)work later on.
It can be tempting to bypass a design step in the process, but this can introduce long term problems. That’s why the development team needs to at least consult a designer to prevent problems from happening.
Inconsistent Interface
This is one of the most common symptoms of poor communication between designers and developers. The cause of this is usually the fact that the designer didn’t communicate their design well - the developers are working on details first without noticing the pattern in design. They don’t see the big picture.
Without communicating the big picture, spaces and sizes will seem random.
Design is used as a loose reference
More often than not, developers are not using the available tools to “read” the design. Consequently, they’re not able to use the design as a precise spec. Developers need to use the tools such as Zeplin or InVision, to help them read the design.
These tools allow designers to upload their designs and make comments for the developers so they can work more efficiently together. Being able to access all the assets they need and see all the specs in one place is a huge time saver for developers.
Plus, tools that enable designers to build interactive prototypes out of their static designs are extremely useful for developers. They can see which elements are clickable, as well as gestures and transitions, helping them implement the design more efficiently.
Point of no return
At this point, fixing the interface will actually be more costly than just rolling with it.
Development made a few poor choices in implementation of the design and it only goes downhill from there. This is a consequence of a build-up of improvised or poorly implemented interface elements, or parallel implementation and design (starting implementation when design is not ready).
This also happens if designers were not included in the process when the implementation started, and the code depended heavily on the structure of the app design.
Review often to avoid build-up
Designers should be involved as consultants/reviewers from the get go. As a designer, you should always try your best to be ahead of development when working in an agile environment.
Ticketing fixes takes more time than fixing
Sometimes you just want to fix a padding on a button and it might take more time for you to document this request for development than for the development to actually implement the fix.
Couple Up
Set a dedicated time with your developer to go over the interface together and tighten things up. This will save you both a lot of time in the long run, even though it may not seem like that to you.
This is also a good opportunity for a designer to learn more about how things work under the hood and for the developer to learn more about design and the thought process behind it. It's definitely a win-win for both!
No time for proper documentation of the design
When you are working in an agile environment, deadlines and limited resources might prevent you from writing a proper design documentation.
Chances are that your designs have a lot in common even though they are made for different projects and you should document the elements that these projects have in common.
This will make it easier for you and for other team members to understand and reuse the design elements.
Don’t reinvent the wheel
Use Sketch to save time. We use React.js at SpiceFactory and this works well for making reusable components. React is a component based JavaScript library which enables us to reuse components from project to project. Both design and development aim for component based workflow and this creates new opportunities for shaving off hours if not days of work.
Remember - structured design leads to structured implementation. Hopefully these tips will help your team work closely together and not just complete their step in the development process. Communicate, share information, and aim to achieve the result that is best for the product and the end user!