UI Design Systems and automation for Lodestone Social.
Lodestone Social (acquired by Umbel in 2016) was a sports and live event media marketing company focused on in-person geo-located marketing campaigns using their proprietary CMS and platform.
The Initial Design
The basic design for Lodestone’s platform had been established. My day to day tasks were to take those established designs and customize them for various client comps and presentations.
The challenge of implementing the established designs was in two different areas of our client presentation. While the design itself was already set up, I sought to optimize and expand our execution of these designs using componentized and automated processes. Nowadays this approach would be referred to as “Design Systems” or “Atomic Design”, but at the time, I was just an intern trying to get out of doing a bunch of boring grunt work!
The two areas with which I was tasked in implementing our designs were
- Static client comps. New potential client comes in, I change some colors, switch out logos, customize the feature set available in the comp to what the client is looking for etc.
- A series of motion graphics presentations presenting the services that Lodestone could provide clients. In taking on these presentations I needed to translate the existing Lodestone Social brand identity to a motion graphics Adobe After Effects comp, and in the process build my comps in such a way that additional videos would be relatively easy to iterate on. Additionally, while I sought to create a flexible and powerful system for producing presentation videos, I also wanted to make sure that I made our work stand out from the zillions of paint-by-numbers app presentation kits that you could buy online from websites like VideoHive.
While my training in art had often emphasized the manual and specific execution of skilled craft, code as a field has an industrialized/automated paradigm at its core worldview. The genius and power of code is its ability to abstract things into functions/objects/libraries, freeing up the programmer to deal with the higher level architecture of the program.
Let’s say you write a piece of code that turns a red square into a blue circle. Instead of writing that piece of code over and over again, every place in a program where you need to turn a red square into a blue circle, you abstract that code into a self contained function that can then be invoked everywhere in the program you need that functionality. And this saves a lot of time, because, you can write a function once and then just invoke it wherever needed. Furthermore if later on you decide you want to change the red square into a blue triangle, you can modify you original function and the changes will propagate throughout the entire program!
As I was learning this, it occurred to me that the same thing could be done with our PSD comps in Photoshop. By breaking out individual parts into their own components, contained within Photoshop “Smart Objects”, I could speed up my future iteration speed and make it easy to customize things much more quickly. The CTA button needs to be blue? Just open up a smart object and edit it. Save. And the change is proliferated throughout the entire document and screens. This was literally years before I heard of Design Systems. I think it’s actually a fairly obvious leap to make once you become more familiar with code and code thinking, but I have to admit I’m a little proud of hitting upon this way of thinking, even if by accident, that is now so ubiquitous in the design world.
This change in our workflow greatly speeded up things and also helped to instill a greater level of rigour in our design system language.
The second challenge was to translate our existing branding over to an After Effects comp and to build it in such a way that it was easily iterated on using D.R.Y methodology. The actual D.R.Y. stuff is pretty straightforward, and not all that different from what I did in Photoshop. Adobe owns both programs so there’s a lot of crossover in their approach to things. What was a unique challenge to this issue was that in presenting our app, I wanted to make sure that we retained a human element. It’s pretty easy to buy a ready made app presentation video comp online and then just plug-in your pictures and render the result. I insisted that we actually film demos of people using our apps. This would be useful, because it would show off the unique features of our applications (which is difficult to do with ready-made comps) but would also humanize and contextualize our applications in the environments and the people who would use those apps.
It was useful then that I actually had a film background to do all the filming and editing.