Getting designers and developers on the same page can be tough for digital product teams. Things get especially tricky when the focus is just on fixing little things here and there instead of looking at the bigger picture together.

Translating designs into programming languages often causes conflict, especially when design software doesn’t integrate well with development. What if we used a system that benefited both design and development by removing the difficulties of this translation? This leads us to the concept of 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.

Declarative design prioritizes trusting predefined rules for UI behavior over micromanaging every possible interaction. This approach shifts the focus from explicitly controlling UI behavior in all circumstances to relying on established, external implementations.

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 final aspect is critical and underlies numerous communication breakdowns and “handoff” problems. Frankly, the common use of the term “handoff” itself reveals a significant issue.

Illustration showing two smiling characters

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?

To bridge the gap between design and code, how can development contribute in a way that encourages design creativity without imposing limitations?

A primary obstacle to collaboration is the difference in language. Is it possible to establish a shared understanding of layout rules, both visually and in code, to facilitate better communication between developers and designers?

Let me introduce you to CSS grid layout.

Examples of different layouts using the same underlying structure

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.

While the concept of declarative design predates CSS grid layout (and even CSS itself), its widespread and practical application within team environments has become truly achievable with the advent of CSS grid. When coupled with the alignment capabilities of CSS flex layout, teams are well-equipped for successful declarative design implementation at scale.

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.

Illustration showing the interaction of code and design

Onto new horizons

When in February 2020 we announced the birth of Penpot, we knew we were enjoying a radically different scenario than those of other design tools. Today, we are happy to be offering native CSS Grid Layout for UI design for the first time. This is a bold move driven by our mission to unite designers and developers around a common language.

Developer tools shown next to the design to allow a two way editing process

In order to bring this declarative programming power to a declarative design interface, we had to consider not only how a designer would benefit from CSS Grid Layout, but also how all this could be used with CSS Flex Layout and other more traditional layout and alignment options.

The result? With Penpot, no matter what you build as a designer, there’s always a 1:1 match between design and code. Designers and developers can work together in better harmony and keep collaborating on grounds that are familiar to both sides.

Other interesting articles:
CSS
See all articles