When working in teams made up of designers and front end developers, there can be a lot of frustration and confusion when it comes to handing assets over from one team member to another. These might be design mockups or icons or high fidelity imagery for banners and the like. Regardless of the content of these handovers, there can always be improvements to this process.
Depending on the project, developers will often require certain materials in order to make development as smooth as possible. So, I’d like to review a couple of steps that designers might take in order to alleviate these pressure points.
That sounds like an obvious statement, but in the past I’ve worked on teams where we haven’t had that conversation early enough in the process. This can lead to all sorts of failures in communication where developers don’t know which assets are the most recent ones. That can then lead to implementing features that aren’t even necessary.
Here’s some questions that you might ask at the beginning:
- Are the front end developers comfortable with Photoshop or Illustrator?
- Would it be best to give them mockups in a certain application, or can they build the website with simple images that have been exported?
- What image sizes do we need? How are we handling images in general? Is a build tool making all the various sizes we need?
- What sort of bug tracking tool are we using? And how should we describe, name, and label new components that need to be developed?
If developers receive a Photoshop document that outlines the entire design of a template, such as an About or Home page, it’s more likely that they’ll write bad code that ties all these context-specific components together. As Harry Roberts argues, this is simply bad design:
If you need to change the cosmetics of a UI component based on where it is placed, your design system is failing. It’s as simple as that. Things should be designed to be ignorant; things should be designed so that we always just have ‘this component’ and not ‘this component when inside…’.
This means it’s best for developers to build independent components and then bundle them together into a specific view later, such as that About page. This isn’t a new idea—atomic design has been telling us this for years—but my point is that the handover process should reflect this change in thinking, too.
Before we add a new item to our team’s to-do list, we need to make sure that they won’t be going over every single mockup hunting for every modification of that new component. This process of collecting every button or icon in the design should be the role of the designer, as this will help other team members extrapolate visual design changes into code.
Brad Frost has called this process an interface inventory and ideally it should document every modification and deviation of every component in the mockups:
An interface inventory is similar to a content inventory, only instead of sifting through and categorizing content, you’re taking stock and categorizing the components making up your website […] An interface inventory is a comprehensive collection of the bits and pieces that make up your interface.
After a designer has performed this interface inventory, they can begin to add all of these variations into an app like Trello, as previously we’ve mentioned how useful it is when designers can track bugs and define new features that need to be built. Instead of a block of text in our to-do list it would be best to attach those interface inventories onto the item itself, like this:
As a front-end developer, I find this much more accessible than a big ol’ directory of mockups that I’ll need to review and pick out each component (especially if I’m unfamiliar with that particular designer’s layer structure). Speaking of which…
Not much to say about this one, besides that it makes a whole lot of sense to keep those layers organized if someone else has to navigate them in the future.
There’s been a lot of projects I’ve worked on in the past where it’s been the developer’s responsibility to receive the mockups from the handover and pour through each file to export everything, even if they’re unfamiliar with the design. These could be banner images or icons, or even the final drafts of the copy.
However, if we have smaller handovers made up of modular components then there’s less chance for misinterpretation.
Since developers now have plenty of build tools such as Grunt and Gulp at their disposal which will generate bitmap images, such as .png or .jpg’s on the fly, in certain circumstances developers will only need an SVG of a particular asset. For example, when developing a system of icons for the project. Adding these bitmap assets is probably a waste of the designer’s time in most cases, so all that’s needed is the original SVG exported from the designer’s app of choice.
Similarly it’s not a good idea to optimize the images, because our build tools will likely deal with those modifications anyway. But, if in doubt, talk to a front end developer beforehand.
This one is a little tricky because it involves talking to the developers again. But, naming an icon
icon-13.svg is obviously less useful to a developer than
windmill.svg. In most cases there will be some kind of pre-existing naming system for these files, especially if we need multiple versions of them for some reason, take
windmill--small.svg as an example.
There’s no right or wrong way to do this but it does require that everyone on the team is working to the same standard. If you have access to the repo then it might be a good idea to add some of these thoughts to the readme in order to help other designers and developers in the future.
If you have any additional thoughts then be sure to add them as a comment below and I’ll add update this post for further reference.