Often, the root of the conflict can be found in translating the design into programming languages — this is particularly the case when the design is created in software that doesn’t naturally plug into the development process. So what would happen if we adopted a mutually beneficial system that eliminated the friction points of translating design into code? Enter Declarative Design.

Declarative Design can be defined as a way to "describe what is to be done rather than command how to do it" when dealing with user interfaces.

So, in practical terms, you're doing declarative design if you're less interested in having total control of how your UI behaves in almost every possible situation and more interested in trusting a set of rules defined and implemented elsewhere.

Declarative Design is everywhere!

Let's take a look at an example of Declarative Design that’s not about technology: road signs.

Whenever you are driving and see a STOP sign, you know what needs to be done (the car must be stopped upon reaching the STOP sign), but you are free to decide how you want to do it. I, for instance, like to change down gears before using the brakes, while other people might progressively brake the car until full stop or even let their self-driving cars do everything for them. The STOP signs couldn’t care less!

If we applied an imperative design mindset to this STOP sign, we would need to be very explicit about how the driver should arrive at the desired state (that is, speed of zero and brakes on) with specific instructions that consider that particular road portion.

The road sign system acknowledges the fluidity (read unpredictability) of both the environment and agents involved and welcomes a certain level of uncertainty in how these rules will be observed. It’s picking its battles.

The other bit of genius in STOP sign design is the universality of its applicability. You could be driving a motorcycle, a car, or a bus, for all that matters.

Taking a page from Declarative Programming

This is not a new system. In fact, web developers have been enjoying this worldview for quite some time now by using modern CSS. Let’s see a typical example:

.button:hover {
  background-color: purple;
}

This snippet will make any HTML element tagged as class=”button” appear purple whenever you place the mouse pointer over it (hover).  The size or position of the button, the number of them, when they appear, or even whether they look like actual buttons is irrelevant. The browser’s implementation of CSS rules ensures all of that for us.

Of course, a more imperative approach to this is perfectly valid. A web developer would typically turn to Javascript programming language to exert control over the behavioral micro-interactions, including explicit “reset” or “default” cases that are not needed with the above CSS code.

Here, the STOP sign behaves similarly to background-color: purple; and you, behind the steering wheel, are the browser.

When to use Declarative Design

There’s no right or wrong when it comes to using Declarative or Imperative principles while designing. Sometimes, it’s just a matter of pragmatism.

Consider Declarative Design if:

• You find yourself experiencing diminishing returns the more time you spend deciding how something should look.
• You can live with some uncertainty around corner use cases.
• You need to build large and scalable designs that constantly evolve.
• You need to share your work and make it intelligible to developers already using Declarative Programming.

This last point is crucial and sits at the core of many misunderstandings and “hand-off” issues. To be honest, the fact that we’re used to speaking of a “hand-off” process is already quite telling.

Very often, this “lost in translation” hand-off nightmare is just a symptom of the transfer  from Imperative (Design) to Declarative (Programming).

Developers spend too much time figuring out the inherent behavior rules that stem from a particular design. This is where a lot of design translation gets lost. By adopting a Declarative approach to design, designers can help teams speed up the development cycle.

What’s the best Declarative Programming can offer to designers?

If we are to build bridges across the great divide between design and code, what can development bring to the table to sweeten the deal without restricting design creativity?

One of the main reasons for this perceived divide is a language barrier. Could there be a way to share layout rules visually and in code so that devs and designers aren't speaking different languages?

Let me introduce you to CSS grid layout.

CSS Grid Layout is a two-dimensional grid-based layout system that completely changes the way we design user interfaces compared to any web layout system of the past. It was created specifically to solve the layout problems we’ve all been hacking around for decades.

CSS Grid Layout is relatively new, first released in 2019, so very few people (and even fewer designers) have explored its potential. But it might be one of the keys for a seamless integration between design and code workflows.

Now, it would be dishonest to state that declarative design was born with CSS grid layout (or CSS in general). However, practical declarative design, one that you can really exercise at scale in a team, can be finally unlocked thanks to CSS grid layout. Combine it with the previously existing CSS flex layout, optimized for alignment, and you’re set up to success!

The compactness and responsiveness of declarative design versus the verbosity and rigidness of imperative design makes the former a much more exciting subject matter within teams. So yes, I would argue that Declarative Design leads to superior collaboration.

But…

Yeah… there’s a but. For this miracle to happen, designers should not be forced to revert to code if they don’t want to. Unfortunately, this is exactly what every single CSS grid layout tutorial for designers out there asks them to do, moving them away from their canvas to a code editor.

Why is that? Perhaps design tools are averse to declarative design? Sometimes it seems like they were proud of creating their own abstractions and vocabulary even if it’s at the cost of further isolating designers. Many of us think designers deserve better, they deserve choice.

I’m so excited to soon be sharing some truly wonderful news about what we’ve been building for Penpot around this very topic. Stay tuned!

Update! You can now read the second part of this post.