Theme Builder

Working on the meta level

The theme builder allows designers to define, test and publish styling solutions without having to establish new design decisions or knowing how to write robust production quality code.
In most current workflows this is simply not possible, the classic way of designers creating the plan and developers implementing that plan is still how most digital products are made.

As you can imagine, working in this waterfall fashion is neither fast, effective or flexible. What is the solution then?

Decouple design decisions from styling and programming.

That's it. Allow designers to work on styling and engineers to write code without either having to worry about the work of the other.

 

But... how?

You need to know about design systems, I have an article about that on this site if you are interested. Tl;dr: Tokens represent the physical reality, the palette of design possibilities. Themes are the application of these tokens into a coherent styling solution. Themes are then consumed by frontend components, which use a styling API. You can change up the styling however you like, as long as you don't mess with the API. And that is where the actual hard work is: finding agreement on naming and constraints.

Let's go deeper into some theme history, thoughts on product design and the place of themes.

 

Digital wellthemeing

Themes and skins themselves are not all that complicated. A digital thing exists, which is made of parts, these parts have a look attached to them, which follow a theme. I first learned about themes when I installed winamp on my computer in 1999. Skinning became an art and pushed winamps success so far, that Nullsoft set up the winamp skin museum to celebrate the millions of skins that were made. Art is displayed in a museum, which makes these skins artworks (there is a lot of bad art, too).

 

 

To change software appearance according to my taste was magic to me back then. Switch out some assets and there is a fresh coat of paint. I marveled at the professional looking skins and wondered how they made these beautiful designs. Since I was already making websites I applied the same logic to web interfaces. However changing bitmap assets is quite trivial compared to making themes for the web, and I started climbing the mountain that is CSS.

 

Cascading pixels, cascading problems

The brilliant Dave Shea gave us CSS Zen Garden, the place where a lot of eyes were opened to the possibilities of designing for the web. I spent years of picking through these and other pages until I finally gathered enough knowledge to participate and release my own websites. The tools caught up, firebug became available, visual design moved forward with adobe and macromedia software leading the way.

Designers found themselves working for many clients which required the same type of graphics, which led to a lot of duplicate work. The gap to the work of frontend engineers widened silently. Various conceptual tools appeared like style tiles, brand guidelines and pattern libraries, which in the end just meant more design maintenance work to keep them all reflecting the customer facing reality.

Finally, the web went multi-device, and responsive design became a thing. The work suddenly tripled, then quintupled, breakpoint requirements changed as fast as the device landscape. The gap from designers to engineers became a full blown canyon, since noone could keep up mastering the intricacies of devices, displays and the wild west of the javascript world at the same time. A change of thinking was required.

 

Disconnect from the past

The challenge to design good software has become quite sophisticated. Back then it was enough to dazzle users with juicy graphics, everything new and different to the drab Mac OS 9 and Windows 2000 look was coveted. Today the first thought is the end user, how does someone vastly different to you use what you make? What are their needs? What goal do they want to achieve? How can you emphasize with them and simultaneously combat your own biases?

After dealing with these questions you return to your craft: How do you communicate design intent across devices and channels, and still remain flexible with a solid foundation?

You seperate the concerns. Layout is seperate from colors and colors are seperate from type and sizing, as are themes. Every complex thing is built from simple things. Keep the concerns simple and digestible, arrange them into a flexible system and you can supply any level of complexity your product needs.

Of course that requires a change of mind: The classic way of drawing a picture of a page is not enough to build a product in todays world.