SIMON YEE
Product Designer

Post-Design Considerations


Or, what happens after the last pixels have been pushed and it's time to hand off your files to Engineering?

In a previous post, I outlined some quick and easy steps to help early-stage organizations establish a scalable, design system. But what happens when all the assets have been exported and it's time to hand them off to Engineering? This is part of the design process too, but one that is often overlooked and neglected. I like to refer to this as Post-Design.

Why This Is Important In the frenetic world of startups where release cycles are king and mantras like “shipped is better than perfect” reign supreme, asset management can easily get lost in the workflow. While it is important to get projects out to the public quickly, there are simple steps we can take to ensure that in the midst of shipping designs, these same files don't come back to haunt us in the future. I've detailed a few things here that design teams often overlook and don't address until the problem becomes unavoidable. By futureproofing the way we manage design assets and workflow, we can avoid turning a molehill into a mountain.

File-naming Conventions One small thing that early-stage organizations can do right off the bat is to standardize file names. Have you ever downloaded an attachment from a project management board or an email thread with a filename that looks something like this: final-design-version02.png? I think it’s safe to assume we all have at some point, and instead of downloading that file in confidence and proceeding with the next steps in our workflow, we pause. Is this really the final design? What project is this for again?

Design can answer these questions, but before I offer some ideas on how it can, I’ll ask a few questions of my own: Is there a system in place that allows anyone in the organization to look at any given file name and know which iteration it is and what project it belongs to without opening it? Is it still clear without a folder or directory? Is this clear to stakeholders outside of the organization?

By standardizing how files are named, we can provide stakeholders with immediate context around any given file, minimize potential confusion, and prevent accidental overwrites. At BlueVine, we used a system of hyphens and underscores: hyphens to designate word spacing in the title and underscores to separate category blocks from each other. It's a bit difficult to explain with words, so here is a visual example:

The naming convention the design team adopted at BlueVine.

I’ve included the guidelines for this in the Resources section at the bottom. Feel free to use it in your own organization if you find it useful.

This is a practice that can go beyond files and be utilized in naming design layers and artboards as well. Imagine how much easier it would be to scan and identify the objects you were looking for if they weren’t labeled generic things like “Artboard02” or “Rectangle 27 copy”. It seems like a really basic thing, and maybe it is, but you will be amazed at the number of unorganized and unlabeled layers I come across all the time. Sloppy design organization works just like sloppy code. At the end of the day, it will do its job, but it will inherit huge scalability and maintenance issues. And eventually, someone will have to wade deep into the trenches and waste their time cleaning it all up. This is one of the reasons why it’s so important to include minute details like this as part of the design process and to have a strong Post-Design structure that reinforces it.

Version control Since Sketch autosaves, is there a system in place that allows a designer to open up another designer’s Sketch file, and edit said file without saving over the original? Can the team revert back to a previous design if necessary? What happens to deprecated designs or shipped projects?

These questions (and the solutions to them) used to be a huge pain point within design teams, but with the advent of tools such as Abstract, version control is now a semi-automatic process that has become much easier to manage. Even browser-based design tools like Figma and Invision provide ways to do this. Like most things in design, the tool you use isn’t important, it’s what you do with it. The point is to give this area of design the proper consideration it deserves. Prior to this wave of fancy new software entering the scene, version control was largely ignored because it was such a tedious manual process. Times have changed now, and we are spoiled by the treasure trove of design programs at our disposal, so there isn't really an excuse to leave this as an afterthought anymore.

Programs like Abstract make it easy for design teams to track edits, manage changes, and version control their files.

File handoffs Some organizations manage it better than others, but there is invariably a subtle tension that exists between Design and Engineering caused by a difference in philosophy and perception of prioritization. In my experience, every startup runs into the same fundamental questions over and over again in regards to handoffs: How do design files get to engineers? Do they even get files at all? How does Design communicate the nuances of a UI component to Engineering?

Unfortunately, there isn’t a quick and easy answer to all this as it really depends heavily on your surrounding environment. Engineering preferences, resource allocation, and technical compromises are some of the things that designers typically have to work through. For instance, some companies have Engineers work directly from Sketch, while others use PCs exclusively—which renders Sketch files virtually useless. Conversely, some design teams ship their projects in code or use code as their primary design tool. However, not every designer knows how to code, and for those that do, it might not be the best use of their time. Others use browser-based tools such as Zeplin to help bridge the gap and make designs platform agnostic, but I’ve also worked with a CTO who hated using it.

And then there’s Product Management, who is usually in the middle trying to make compromises on both sides. How do they communicate Engineering feedback to designers? And when the designer makes changes, how do they document them and communicate it back to Engineering?

While most of the aforementioned tools come equipped with some sort of annotation feature that can solve some of these problems, a cohesive structure still needs to be in place to facilitate these changes. Ultimately, handoffs aren’t just a method of putting designs onto the screens of engineers, it’s a system of communication and keeping everyone accountable.

Let’s go back to the example of the designer who iterates on an existing design. So how do those edits get back to Engineering? Should it be uploaded into the cloud or attached as part of an email thread? Should it get shipped back to the PM who then passes it on to Engineering? How does Engineering know what changes were made and what they should work on? Should Design commit to a git repository? Should they even have access to one?

Once you understand these problems within the context of your organization, your team, and the constraints in consideration, you can begin to reframe them in a more workable manner. I’ll go back to the CTO I worked with who vehemently despised Zeplin. It turns out that the reason he hated it so much was because it was misused. Before I hopped on board, the company worked with an agency who did a lot of their visuals and marketing collateral, but wasn’t very well-versed in delivering digital designs to developers. The agency ended up shipping over designs that did not adhere to the grid, suffered from inconsistent sizing and spacing, and lacked a uniform design language. Despite heavy pushback from Engineering on why these designs would not work, and how they would break in development, the agency insisted that they would, and used Zeplin to “show them how it’s done”. It’s not surprising then, why the CTO ended up hating this tool and associated it with pixel-perfect designs that made his team’s lives unnecessarily difficult.

Epilogue There are a lot of things to consider in the world of Post-Design. When navigating these stormy seas, try not resorting to software as a default response. Instead of saying, “Such and such tool can help us fix this particular problem”, dive deeper and find out why that problem exists in the first place. Can it be solved more organically and earlier in the workflow?

A good Post-Design System can theoretically solve these issues, and if done right, should work in harmony for all parties involved. Granted, that’s an incredibly optimistic perspective, and there will always be an evolving set of constraints, but it’s a valiant goal that designers should strive to work towards. At the very least, like most of the things in this article, it should give us something to think about.

Resources File-Naming Guidelines