While Stackbit is optimized for promoting collaboration between marketing and development, it can also be leveraged to work in concert with design. And it can be done in a more effective way than many of the tools working to solve collaboration between design and development.
Developers, designers, marketers, and other business teams can accomplish great things when they work together. But collaboration is hard.
To solve collaboration, many teams first work to improve their communication. While that will help, it won’t leave all teams feeling optimized. It is in creating and maintaining specific processes and tools that collaboration can be optimized, leading to fast iterative project cycles (minimal time to market), without sacrificing quality.
The Optimal Web Team
Typically, the primary unit responsible for ideating, creating, and enhancing a web experience are design, development, and marketing.
To combine these units into an optimized web team — where both the system and each unit operate with maximum productivity — requires the following:
- Every unit (design, development, marketing) must be able to operate independently, following their preferences and industry best practices.
- Collaborating — working together, along with handing off work to another unit — should be a seamless process that does not detract from individual productivity.
Consider the following example:
- Design: Uses their preferred application(s) to deliver clear and reasonable specifications to developers.
- Development: Works with their preferred language, tools, and configurations to write code the way they want.
- Marketing: Can quickly iterate to create new experiences on the web without the need for design or development.
The Gap in Today’s Market
The optimal web team sounds great in theory, but it’s elusive in practice.
Stackbit Sets the Collaboration Foundation
Stackbit’s visual editor is architected to solve collaboration between developers and marketers by allowing developers to focus on creating components the way they like with no restrictions, while marketers can use those components to build and edit websites independently.
Addressing the Gap between Design + Development
But that still leaves a gap between design and development teams. Typically, designers use tools such as Figma or Sketch to design components, then pass their designs to developers who convert them into code.
The problem is that if the design needs to be updated, the process repeats itself. Thus, there are always two sources of truth — the original design in the design application, and the component’s code in the web project. The way to achieve optimal productivity is to work toward a single source of truth.
2 Common Ways to Address Designer + Developer Collaboration
There are two approaches common among teams today for solving collaboration between design and development:
- Work with two sources of truth
- Use a code generator tool
Components with Two Sources of Truth
The most common approach is that the handoff works exactly as mentioned above — designers use their tool(s) to create a design, then hand it off to developers, who implement the design with code.
The benefit of this approach is that both teams have full control over their part of the process. Designers get to use their preferred tooling and processes, and developers can follow their preferences to optimize the code quality.
But, designs are fluid. They change during implementation. They evolve in future iterations. If developers adjust the functionality of a component, that may mean extra work for designers to update designs that have already been implemented. Or, when a change is prompted by design, developers have to keep their code up to date.
Working with Component Code Generators
There are two types of component code generators:
- Vector design applications (Anima + Figma, Framer) that enable designers to visually create components that can be exported to code for developers.
- Component-building tools (Plasmic, WixComponentStudio, Utopia, Drimz) that are built for designers and developers to collaborate building components with two-way syncing.
Component-building tools are getting closer to creating a place for designers and developers to collaborate throughout the life of a website. On the other hand, code-generating tools tend to sound great in theory, but rarely work for long in practice.
This is because these tools are designed for designers. While they may generate code, they take little consideration into the complexity and fluidity required in the development phase of a project, making the process feel more like a cool toy, rather than something that can solve production-level collaboration.
Code-Generation Challenges
There are a number of reasons why code-generating design applications don’t work in practice. Here are four specific examples.
Vector-Based Controls
Some of these code generator tools are vector-based (or plugins for vector-based tools). In these tools, shapes have no semantic meaning on the web.
Consider a checkbox. A designer is likely to build a checkbox as a square, with an SVG checkmark for the checked state.
When the generator converts this element to code, it remains a square — often represented by a generic HTML element like a <div>, and a checkbox represented by an <svg> or an <img> element. Practically, this should be exported as a <input type=”checkbox”> element.
Lacking Code Conventions
Code conventions and preferences differ from company to company and developer to developer. Often, a developer who sees a code style they don’t like either ignores it (back to two sources of truth) or rewrites it (a tedious process).
For example, there are many different patterns when it comes to defining styles for a component — plain CSS, conventions like BEM or OOCSS, pre-processor like Sass, JS-in-CSS libraries like Styled Components, or CSS modules.
And that’s just handling the styling. There is still the actual code to consider, which brings to mind much wider choices — functional vs class components, code conventions and patterns, shared utilities, third-party tools, etc.
Some tools — like Anima + Figma — allow developers to choose how to generate components. But the choices are still very limited and opinionated, and unlikely to adhere to the developer's preferred conventions.
Bi-Directional Code Changes
It is impractical to think that a design code generator could ever produce production-ready code. Developers are still going to have to write some code. This could include:
- Adding the business logic such as conditions to turn on and off specific elements,
- Iterators that create a list of dynamic values
- Attaching event handlers to elements that invoke business logic functions
- Add animation effects
If the designer decides to adjust the original design even slightly, the newly generated code will be missing all the developer-added pieces and will have to be manually merged with the code that was already adjusted by the developer. This is a tedious process at best, or, at worst, may require rewriting the added code.
Exposing Content as Props
It’s not just business logic and animation that needs to be added to components. Components are generally built to display dynamic and reusable content. Developers need to extract hardcoded values like titles, labels, paragraphs, images, and other content-based items and expose them as props to be consumed from the content source(s) (API, headless CMS, database, etc.).
All this work must be done every time the component design changes and new code is generated.
2 Ways to Maintain a Single Source of Truth for Components
Given the limitations and challenges with the tools available today, we’ve identified two approaches for maintaining a single source of truth for components. If we can achieve a single source of truth, designers, developers, and marketers can work the way they want with optimal productivity and flexibility.
Designing Low-Level Static Components
As we explored above, knowing and satisfying all conditions and preferences is nearly impossible for an automated tool (component code generator) to accomplish.
However, a design tool could create low-level, static, and semantic components in a separate library that developers import into their production site code. Being that it is a separate and external library, if its convention differs somewhat from the developer’s preference, it’s okay.
It’s more important that this automated component code has all the dynamic values exposed as props. Even if some of these components will need to be extended and adjusted, that process becomes more efficient by keeping these components static and simple.
Here’s an example of how it would work in practice.
- Designers design low-level, static components, then use their preferred tool to generate semantically-correct React components with dynamic values exposed as properties.
- Inside their design tool, designers specify which parts of components are dynamic and can be controlled externally by exposing them as props. This can include:
- Styles
- Content, such as text and images
- Iterators that receive a list of modeled items and generate repeatable components
- Click handlers, along with other event handlers as necessary and available
- Animation triggers
- Developers should practice minimal intervention with the exported code, treating the exported code as a source of truth for these simple components. Instead, developers would import these low-level components into higher-order components, with business logic that provides the necessary properties.
Developers Expose Style Properties to Designers
Alternatively, instead of requiring the design tool to generate code, developers could create a highly-customizable atomic and molecule component system.
These components would surface style properties that would allow designers to manipulate the component into the look and feel needed for some specific context. Using a visual editor like Stackbit, designers could then “lock” these component variations into reusable presets that could then be used by content editors (marketers).
This approach provides a great starting place for teams to work, as it allows developers to focus their changes on a very limited set of atomic components that can be used as building blocks by the rest of the team.
The tradeoff is that designers would have to use two different tools. The process would look like this:
- Designers produce atomic components (e.g. button, image, slider, form, etc.) in their preferred application.
- Developers implement the design with code, exposing style properties as content. (This can be done using Stackbit’s component styles.)
- Designers use Stackbit to create more complex components from the atomic components, using the exposed style properties to manipulate the look and feel of each component. Designers then “lock” the component and its styles into a preset.
- Marketers can use this preset to create fully-designed components with the proper guardrails to ensure they do not break the production site.
Closing the Gap on Collaboration
The power of Stackbit isn’t just in creating collaboration between developers and marketers. The design-to-development handoff is equally as important when building experiences for the web.
With a little process adjustment, Stackbit can be used to bring these design, development, and marketing more in sync, effectively reducing the time to market for each project cycle, while reducing the dependency each team has on one another.
