REWE Theme Editor
Empowering designers to own design decisions, liberating developers from CSS nudging.
The challenge
As described in the REWE Design System case study, the architecture in place at REWE required duplication of changes across microservice teams. To me this was an irresponsible waste of resources, so I took it upon myself to build a solution to fix it.
Success scenario
“Designers are empowered to own design decisions directly on production, including the responsibility to fix any mistakes that break the styling layer.”
Approach
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 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.
Naming things is one of the hardest challenges in computer science
I don’t believe in one general naming solution, as my experience taught me that it always depends on the local tribe you are engaging with. Designers talk differently from developers, and managers have a language entirely of their own. So I ran workshops including these parties and let everyone share their name and definition for a given UI primitive. Together we agreed on a list to go forward with.
How to actually solve it?
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 the styling however you like, as long as you don’t change the API. And that is where the actual hard work is: finding agreement on naming and constraints.
Seperating the concerns is the major part. Layout is seperate from colors and colors are seperate from type and sizing, as are themes. Gall’s law comes ino play here:
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
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.
This is where thinking and tools like these come in.
Outcome
The styling layer and component API consumed the theme files, in which the designers made their decisions with the theme editor. A change in the theme propagates through to the styling call on production, giving designers the power to preview, test and ship their own decisions.