When I started as a designer, handing off tons of documentation to developers was best practice and a necessary evil. I used to spend hours transcribing the designs into documentation and redlines, assuming developers would build the exact same designs. Developers had to spend time making sense out of the extensive documentation and then turning it into code. It wasn’t a great experience for both sides.
Luckily for all of us, tools got better and so did we. At Idean, we’re always up for a good challenge, so we questioned how we work with developers and decided to try new things. One of the tools we’ve brought in is called Figma. It helped us collaborate more closely as a team. I’d go as far as to say, this new workflow helps us build better products.
‘Is this design ready?’, ‘what happens when the user taps here?’, ‘can you send me that asset?’… Does this sound familiar?
Below are some of the most frequent questions we get from developers, our current solutions and why it makes our lives easier.
Is this design ready?
One of the reasons for choosing Figma as our design tool was having the designs in the cloud. We had this idea that we could have just one file and go through all the phases of design in that same file; exploration, testing, production… We would share a link to the design file with developers and they would provide feedback throughout the process and implement the designs.
So we did that, and gathering feedback was working surprisingly well. They were using their technical expertise and knowledge about the product to tag us with questions or ideas that we hadn’t even considered before. On the other hand, they were unsure about what was ready for implementation or what was still under discussion.
We decided to create a separate file for developers called ‘Production-Ready’ where we share the latest designs. Everything is organised and linked to the Design System, and its content doesn’t constantly change.
Developers said it helps to have a file with the latest decisions and still have access to a previous version to understand what was added, updated or de-scoped. Also, having a Production-Ready file has helped other parts of the business to know what’s going to be built next.
What happens when the user taps here?
We used to get a lot of questions about the flow and interactions, and for that, we were building interaction flows in a separate page and prototypes to define all the transitions.
It was a lot of work to keep flows and prototypes up to date with the latest changes and developers had to constantly cross-check the interaction flow and prototype with the designs.
We now create the interaction flow and prototype in the Production-Ready file using the actual designs, not images. Developers can click play at any point and interact with the prototype. We also make sure all the grids and constraints are in place to show how it behaves with different screen sizes.
That way, the design file becomes the documentation and it holds the visual design, interaction flow, prototype and specs in one single file.
It prompts us, as designers, to think about all the scenarios and edge cases while we’re working on the visual design. It also reduces guesswork and ambiguity for the developers.
What do we do when the server is down?
This question will have different flavours depending on the product, but there is always a technical question that we as designers couldn’t foresee. It could be a constraint, an edge case, something adding unnecessary technical complexity, you name it.
Involving developers in the discovery phase hugely helped to identify technical topics we needed to cover during the project since the beginning and reduced big surprises further into the project.
However, when we shared the Production-Ready file we still got technical questions that we couldn’t anticipate, and there is nothing wrong with that. It’s totally normal that as developers get into the details of building the product we might discover areas that need more thought. What helped with those technical questions was to be open and find a solution as a team.
This meant for us to embrace change and accept that the final design doesn’t exist, it is just the latest design.
Can you send me this asset?
Previously, we were exporting and sharing assets with developers. This implied finding the required assets to export and paying attention to platform-specific naming, screen resolutions and image formats.
As developers have access to design files, they can now export directly the assets they need instead of chasing designers to get it. They just need to know things like how to select the whole component, export to different resolutions or formats… and they’re ready to go.
One thing to keep in mind is that by having developers export assets, you might lose track of all the visuals that are being used in the product. To avoid this, we always have the assets as components in the Design System which helps to keep consistency in the product.
Why is this a different colour?
This is one of the best questions we can get as designers. It means you are in a very good place where developers understand the designs and are able to find inconsistencies.
When developers use Figma’s inspect functionality to get sizing, spacing, colours… they can also see if the text or colour style belongs to the Design System. This is very powerful. It just requires an initial alignment with developers to make sure you’re using the same naming in the designs and code.
Lastly, we have to communicate any modification to the Design System, for which we simply tag the developers in a comment.
Shared goals, better products
We now work closely with developers and bring their expertise into the design process from earlier stages.
Developers said the new workflow makes better use of their time as they don’t have to constantly chase designers to find answers and everything they need is in one place.
The shared designs don’t come as a surprise as developers were part of the process. It’s also a better use of our time as designers as it reduces a lot of manual work and we solve concerns before they become an issue.
In the end, we are all working in the same direction with shared goals which translates into building better products.