Reshaping the design process with code – Part 2

In Part 1, we dug into how we began dreaming of a new and different design process at Layerise. How we feel the current process was too cumbersome. If you haven't already, please read Reshaping the design process with code – Part 1

As we concluded in part 1, our goal was to move from a rigid waterfall process to a more fluid and team-wide process. To achieve this, we added some milestones on how to accomplish this:

One source of truth. No more requests for newest version or work with an outdated design package version.

Setting up version control (Semver). Help the team get familiarised with the changelog and provide complete autonomy over the upgrade process.

Quick prototyping. Promote quick prototyping is essential and should be possible both through code and visual editors.

Dedicated playground. Have one place to showcase, document, and test the design system.

One source of truth

This is something every designer, product manager, and developer has experienced. It is not unusual to see memes and jokes about design files called final1.psd, final2.psd, thisisthefinal.psd. As we talked about in part one, there is no such thing as a final design. Design is iterative; hence having a file representing a design version isn't a good idea.

We looked into the developer tooling and solution landscape to seek out a solution. We were impressed by how open source and package registries allowed for a more open, shared and interactive truth without the loose of control or degradation of the truth.

However, going down this route meant a quite big mindset change. Moving away from only visual editors into a programming editor is a big switch. Nonetheless, by utilizing a package registry, we can publish and update our *one source of truth* and allow the individual user the right amount of granular control by targeting specific versions. Furthermore, this allows for a much closer relationship with our developers since they can create a design issue or make a pull request which is in line with how they work.

Version control

Many designers have hopefully been introduced to some version control, though usually, it's only the major version, like 1.0, 2.0, etc. In most cases, this is because design used to be done in a more vacuum-based process, where only UX, Product Managers, and Project Managers participated, and the end goal was a huge chunk of views/screens that needed to be updated and delivered.

This needed to change, as having an one source of truth powered by a team-broad always-active design process, the number of major versions would naturally inflate. At the same time, the need for minor and patch updates are needed to allow for a more iterative process. Moreover, with an increase of version roll-out frequency, it is good practice that the participant of the design system understands what's been updated in each version. So whenever a major or minor version is bumped, looking into the changelog is required. On the other hand, with patch version bumps it is recommended to read up on changelogs as patch updates are pushed accessibility issues, bugs, and small visual tweaks. The official guidelines for Semver are defined as:

(1.0.0) MAJOR version when you make incompatible API changes.

(0.1.0) MINOR version when you add functionality in a backwards-compatible manner.

(0.0.1) PATCH version when you make backwards-compatible bug fixes.

Quick prototyping

While having one source of truth stored as code packages is suitable for control and sharing, the need for a quick prototyping ability is still very essential in the design process. The need for scaffolding many different variations and flows for the user experience exist and is in many ways where the design team's most crucial task is. Yet, these prototyping methods are spread across many different levels of fidelity.

The lowest level of fidelity is pen and paper or drawing on a whiteboard. This level allows the whole team to easily participate and is usually more of getting a common idea of what's needed, like a rough scoping. Depending on your teams' size, there can be multiple levels of fidelity after the first one, like wireframes.

At Layerise, we still have the wireframing step, but it might be a bit different than other teams. Our wireframe step is merged with the design handoff step since we're have created a continuous integration with our design tools. If your visual editor of choice is Framer X, you can grab the newest design packages through our shared store, which auto-updates on every new version. Using Sketch or Figma? Then you can download the latest version of each design component through our design system platform (We'll dig into this further in the next paragraph). By having a continuous integration, we allow quick prototyping in visual editors with the newest design version available.

The design platform

In a traditional design process, the design usually lives in files. Though, this isn't the case with our setup. Since our interface and components live as code we needed a different solution. We're using Storybook which allows us to document, test and design our design system. Storybook has add-ons built-in which in return allow us to test with real data, test for accessibility issues and responsiveness.

With the way we use Storybook to handle our design library, the individual Layerise team member can learn about how to use each component, in which context and what tweaks that are available. Moreover, since our design now lives in Storybook, members of our team have the newest design at hand anywhere. In essence, the whole team can now instantly get the newest design whether its a component or a color tweak. They can furthermore read the changelog and get notified for new changes.

Our new design process has been under development for the last year, and we're still tweaking the process to come closer to our goal of having one source of truth while the whole team can participate. We're very close and look forward to letting you get a deeper look into what the daily workflow looks like in part 3.