Those who have worked with me recently have probably heard me go on and on about the PaintCode application and the larger underlying shift in thinking when it comes to design delivery. If you’re among the even less fortunate ones, you may have had to sit through a full 30 – 45 minutes of me talking about this.
Disclaimer: I’m in no way affiliated with Pixelcut, nor did they ask me to write this, I’m just a longtime user of their product and I greatly appreciate its benefits.
More than just pixels and code
If Telekinesis isn’t already magical enough by itself, the potential impact of PaintCode goes much further. Back to the topic of design delivery… One of the main problems we have dealt with as designers since we started crafting software user interfaces, has been the ability to easily fine-tune the end result, or rather a lack thereof. This is especially true for desktop, mobile and embedded systems. Although we’ve mostly moved away from specification documents in favour of prototypes, we are still essentially creating alternate realities to the final product.
It can sometimes feel like we’re spending more time managing people and process, rather than fixing the product.
No matter how detailed your prototype and Jira/Pivotal stories, at some point there will be multiple conversations with whoever is implementing your design. And as long as someone else takes care of implementing what you created, there will be problems. Your mileage may vary, but things can get pretty tense. This is why we introduce certain tools, processes, and even people to help us manage these problems. And while there are arguments to be made for the hybrid designer/developer, that’s part of a larger discussion that I won’t go into here.
A few of my former Wire colleagues tried to address the issue with a tool for iOS and Mac OS called Hone, which was sadly discontinued last year. The thinking was simple, allow designers to fine-tune and tweak visual parameters while previewing the changes in a live version of the app running on a device. Sounds familiar?
The underlying principle is to separate the presentation layer from the internal complexities of the application itself. This is of course not a new concept, and especially in web design these capabilities have existed for a while. Even Microsoft has done some interesting things with Expression Blend, launched in 2007.
When you do both design and development like me, these tools are even easier to integrate into your workflow.
PaintCode is similar in that it enables any designer to firmly take control over the quality of the final product, at least visually. Where it differentiates itself is the user interface, it looks very much like the tools most designers already use today (unless you have not moved on to Sketch or Experience Design CC). This greatly lowers the barrier to entry, especially if the application dock on your Mac already looks a bit like this.
You are still dependent on frontend developers implementing the drawing code, and things will break if you add new styles, or remove elements that are in use. Once everything is in place however, you can tweak whatever is there to your heart’s delight, and this is where everyone wins in the end. Less requests to the developer team to change the appearance of a button, or change the colour of a label.
With PaintCode 3, there is an even greater benefit, one toolkit across multiple platforms. This may actually provide us with a partial replacement for those hard-to-maintain design libraries, which so many of us have worked on over the years.
The excellent design guidelines for the best Nokia phone that was not to be.
With Swift Playgrounds on iOS and Mac OS you can see a hint of what is likely to come, but for now, PaintCode does a great job at filling part of a gap that should ideally not be there in the first place. I’d like to see something for motion design as well, and managing values (constants) that live outside of your PaintCode drawings is still a messy affair on any platform, but it is another step in the right direction.