Developers typically split the task of finding issues from building a project for wider release. These modes are often called debug and release. I think designers should take a similar approach.
In debug mode, everything is optimised for finding issues. There’s typically more logging, breakpoints and other tools available to developers. In release mode, everything is optimised for production release, and debugging information is stripped out.
What would be an equivalent for designers?
To find out, you’ll need to be using automated asset building. You’ll need to be able to generate entirely new sets of assets with minimal effort. You’ll need to treat all those lovely PNGs and SVGs or whatever you’re creating as disposable.
I usually use slice sheets in Photoshop for automated building. I’ve also been experimenting with automated SVG exporting from Affinity Designer, and set up the Bjango App Icon Templates using a variety of different methods. Any automated method will do, using whichever tool flips your bits. It just needs to be easily repeatable.
No design tool I’m aware of offers a specific debug build mode. My solution so far has been to create a fresh set of assets with helpful information baked in — you won’t want to use them for your production website or app, but they can make development faster and easier. Debug assets can remove a lot of tedious work writing specs, and they can make layout adjustments a lot quicker. Here’s some of the ways we’ve been using the technique.
On one of our projects, there was an issue where the incorrect images were shown for button states. The button down image was showing when the button was pressed, but it was stacked on top of the normal image. It was only noticeable by the strange corner antialiasing and incorrect shadows, but definitely there.
To debug, I re-built the assets with the state added in a way that could be seen no matter how they were stacked. Once the bug was identified, it was easy to correct, and the debug information was removed from the assets.
It is quite likely the developer on the project could have added similar debug information on the code side, and also found the issue in a short amount of time. Debug assets aren’t just about improving process — they’re about enabling designers to play a larger role in the engineering side of projects, without needing to write code. They are another debugging tool, useful in many situations, but not all.
Any project big enough or old enough will go through phases where assets need to be removed. Colouring deprecated assets is a great way to see which old elements are still in use, and where.
To mark an asset as deprecated, I usually colour it red with some kind of overlay. If you’re using slices in Photoshop or Affinity Designer, a single partially transparent vector layer in a bright colour is great. Due to the way slices work, the single layer can appear in any or all exported assets.
If you’re using Generator with groups in Photoshop, a colour overlay layer style could be good (that way you can copy and paste it, too).
If you’re using Sketch, an additional fill can be added to multiple objects at the same time, for a quick way to mark elements as deprecated.
The same method can be used to indicate unfinished assets — once you’re using automated exporting, throwing an asset in with the correct name and likely size is easier, as is iterating on that asset’s design. It means development can continue while assets are being finalised, and the asset can be marked as non-final.
Set the background of a main container view or div to an image with guides baked in, and it’ll be underneath your running app, making alignment issues obvious. Working this way removes the need to spec position information — the background debug image serves as a live spec to match, making it easier to keep mockups and the production project in sync.
For a responsive design, several guide images can be used at important breakpoints. In some cases, nine-part images can be used for a responsive grid with a single image.
Those who enjoy designing in the browser may see this approach as ludicrous, but remember that there is no design-in-the-browser equivalent for native software, and even where it is possible, it’s not always the fastest way to work. I am not advocating against designing in the browser — I frequently work that way when designing for web. I am simply providing other processes that may be of use, and I find spec documents a pain for all involved.
It is becoming more common for large projects to be managed with sticker sheets. Sticker sheets contain common elements used, and are intended to restrict assets and styles to those already available in the code base, which keeps things efficient and consistent. If an asset or style isn’t in a sticker sheet, then it will need to be implemented, and the team can discuss if it is a worthwhile addition. Sticker sheets are a continuous stock-take.
Design debug builds are not only compatible with sticker sheets, they fit the overall philosophy perfectly. Debug builds allow labelling for things like deprecated assets, stand-in assets, and assist large project management.
Debug vs release build
There’s two main situations a design debug mode needs to cater for: Images that are altered for debugging, and images that are only used for debugging.
For images that are altered for debugging, I try to separate the alterations into their own layers or groups, and tag the name with “debug”. That way I can search to easily enable or disable them all before exporting.
For images that are only used for debugging, prefix the export name with “debug-”, and have a Hazel rule to optionally remove them. This means they’re always exported, but if the rule is active, they will also be deleted (for the “release” mode).
Toggling release mode on and off is a single click in Hazel.
I’ll continue to experiment with design debugging, but so far the technique has been pretty helpful. Feel free to ask me questions about this article.
Published 27 Apr 2016.