For decades, the creative process from ideation to execution relied heavily on ecosystems that favor one side or the other. Either designers had to sacrifice and go into developer grounds or developers had to tread carefully around designer’s playgrounds.
While this on its own causes enough friction, sharing such vital information on a fully outsourced environment brings in further departments for rightful security reasons. What if a middle ground, where not only you set the boundaries but also where developers and designers BOTH feel at home, was possible?
The status quo
Bringing designers and developers closer has been a long-standing challenge for digital product teams. This disconnect often manifests when teams become sidetracked trying to resolve isolated issues stemming from either the design or development side.
Frequently, these conflicts originate from the process of translating designs into programming languages, especially when using design software that doesn’t seamlessly integrate with development workflows. Imagine a system where the difficulties of converting design to code are removed, creating a mutually advantageous environment. This is where Declarative Design comes in.
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.
Imperative Design, on the other hand, evolves around the very step-by-step, state-by-state, exact ways and measurements. To continue, unless you want your designs to be concept art or a mock-up, never to become real software. You have to extensively document such an interactive user interface for development.
Why? Because, traditionally, software design tools have prioritized the feeling of control even at the cost of effectively bringing the work to life. And, as you might imagine, an obsessive, control-oriented process won’t get you where you want to go. While design tools might frame this process as the pursuit of quality, it’s simply not the case.
Problems that cause further problems
As a result of all the friction and unmatched approaches, we see multiple issues arising within the creative process. Let’s briefly mention some of the usual suspects…
- Lack of clarity
- Whether it comes to documentation about instructions or the very internal communication between the team.
- Lack of familiarity with the tooling on either side
- One side always has to compromise. It’s usually the developers who have to go through “hand-off” and figure things out in a very designer-oriented environment.
- A similar story is also seen when designers have to dip in and out of the code world.
- Lost in translation moments
- As a result of the two points above, there are multiple incidents where instructions become lost in translation, and further clarification documents, calls, and meetings needed. Sound familiar?
- The need for a single source of truth
- Being able to rely on a single source of truth without the need of update multiple sources constantly, is a dire need. Currently there is a lot of manual work going into keeping things up to date to match and maintain parity across design and code.
- This pain point also affects other stakeholders when it comes to reviewing, commenting, and bringing things to third parties.
- What you design is quite often what you don’t get
- Whether due to limitations or finding close to no representation of things in code.
- The pseudo hierarchy between designers and developers based on the tooling
- That unsettling feeling where you feel like you are walking around someone else’s territory, all the meanwhile there was no preconception of territories at all.
- A sense of familiarity is often the underlying cause for this, and that eventually introduces this non-existent sense of hierarchy between stakeholders based on which platform you are working on.
Last, but not least, intellectual property ownership, data security, and transparency…These have been a recurring topic, especially in recent months or even years. As design’s value and ownership increase, so does its need for security. As a result, even more problems pop up:
- Who owns my data? Do I get to keep it?
- If somehow I own my data, how do I securely store it without relying on third parties for some very first party data…
- What if something happens and we lose access to the third party? While relying on them does the job for now, does it really mean my creations are future-proofed?
Although all of the problems listed above can be intimidating, the very first step when it comes to a solution is…openness…
Reclaiming the reins
Let’s tackle the existing problems from bottom up, as ownership can be referred to as the bigger headscratcher, as even the terminologies are still not set in stone. However, The European Commission has the following take on it:
“The overall conclusion is that intellectual property rights can apply to data, but in many instances, the legal threshold for the application of intellectual property rights is not met. In those instances, data ownership by proxy (via intellectual property rights rather than by owning the data as such) is not possible either.
Moreover, data ownership is a concept that lacks nuance. The essential question for data is not who owns it (if anyone), but who has the right and ability to access and use it.”
The paper then repeatedly mentions open data communities, as well as the importance of transparency when it comes to access to intellectual property, more importantly, the right to access and control access to intellectual property. While we can, for now, leave the EU Commission to define and regulate, we can take this mini detour as the basis of the very first step towards solving the problems.
Luckily for us, today’s software industry offers us plenty of choices in regards to security, ownership, and storing our own data. The common theme for these qualities often points to Open Source software. Mainly because they use open standards, they offer private hosting, local hosting, forking, transparency, and most importantly, a never-ending community support.
Open Source thrives on the active participation of diverse contributors, including designers who bring unique perspectives and skill sets to the table. While developers play a pivotal role in coding and functionality, designers contribute equally essential elements such as user experience, interface aesthetics, and accessibility. This then fosters a deeper, fresher take on designers and developers collaborating openly to create great products. A full circle moment with a clear focus on…middle grounds…
Meet me in the…middle
In order for this new way of collaboration, yet better alliance, to pan out as expected, we see four main principles coming into play:
1.) Declarative Design as a way to onboard developers into the Design Process
Developers tend to use declarative paradigms in their code. By adapting things to declarative design, you can eliminate the pain of translating things from imperative design to declarative design.
2.) Open Source and Open Standards for an Interoperable Ecosystem
When combined with Open Standards, Open Source turns the generosity of sharing the code into greater products, all safe and secure.
3.) Non-biased tooling that can be customized by opinionated mindsets
We need to be moving beyond the mindset of what is the best, not just for me, but for everyone else. There needs to be a distinction between tooling that fully favors one side or tooling that fits all sides.
4.) Accessible & inclusive tools and workflows so everyone can be a part of the creative process
We need to think beyond features or capabilities here. It’s more about the experience of being part of the whole thing, in an impactful way. Everyone can and should have a say…
Factoring in all discussed, is there a secure, private, open-source way for designers and developers to collaborate and create great products together? Enter Penpot…Penpot is the first open-source design tool for design and code collaboration. Designers can create stunning designs, interactive prototypes, and design systems at scale, while developers enjoy ready-to-use code and make their workflow easy and fast. And all of this with no hand-off drama. Available on browser or self-hosted, Penpot works with open standards like SVG, CSS, HTML and JSON, and it’s free! With Penpot, not only do you get to reclaim the reins/ownership of your designs, you also start experiencing that “deeper, fresher take on designers and developers collaborating, openly.”
At the end of the day, both designers and developers deserve choices, new and fresh takes, better means to design and code great products, together…
