Sign in / Sign up

Done
Thanks for the suggestion!

Sign up for Playbook. We’ll let you know when questions like yours get answered.

We'll never post to Twitter or Facebook without your permission.

Share

Cancel
Cancel

Join Playbook

Playbook gives the design community one place to share knowledge.

Created with Sketch.

We value your data

We only use social login to gather your name, email, and profile photo.
Cancel

Sign in

Playbook gives the design community one place to share knowledge.

Created with Sketch.

We value your data

We only use social login to gather your name, email, and profile photo.

Sign in / Sign up

Done
Sign up to follow

Sign up to follow this goal and get notified when others answer it.

We'll never post to Twitter or Facebook without your permission.

Sign in / Sign up

Done
Sign up to save

Sign up to save this answer.

We'll never post to Twitter or Facebook without your permission.

Sign in / Sign up

Done
Sign up to like

Sign up to like this action.

We'll never post to Twitter or Facebook without your permission.

Sign in / Sign up

Done
Sign up to respond

Sign up to respond to this answer.

We'll never post to Twitter or Facebook without your permission.

Sign in / Sign up

Done
Sign up to follow

Sign up to follow this person and get notified when they share answers.

We'll never post to Twitter or Facebook without your permission.

Sign in / Sign up

Done
Sign up to follow

Sign up to follow this collection

We'll never post to Twitter or Facebook without your permission.
Join
Sam Soffes

Sam Soffes

Software Engineer at Lyft

iOS engineer on Design Systems at Lyft

9 action items

Build your design system to be consistent, yet flexible

  • Sam Soffes

    • Define what is flexible and what is rigid

      You should define what is flexible and what is rigid in your system. For example, fonts and colors are probably very rigid. You want everyone to always use your brand fonts and colors so the product feels like your product. Component details are usually a bit more flexible. If you had a button that was a specific size and someone needs to change it to be a bit smaller to fit in a new flow, that's probably okay and can still feel on brand. Maybe someone is adding a screen to take photos and they UI should be dark instead of light so they need to customize a bunch of components so work in dark mode. That's also probably fine.... See more

    • Provide ways to mix and match

      Defining multiple styles for the same component is a good way to make things flexible. You could have a "primary" and "secondary" style for a button component. You could also have a "normal" and "compact" size of the component. You could also allow team members to create their own styles or sizes. Allowing designers to mix and match sizes and styles can open up a lot of combinations that all feel consistent.... See more

    {{ answer_favs.includes(237) ? "Saved" : "Save" }}

Increase team member adoption of the design system

  • Sam Soffes

    • Build trust

      When there's a bug in part of the design system—either in a Sketch Library, engineering implementation, etc.—it can greatly impact the whole product. You should be responsive and fixing these issues as quickly as possible so your team can trust the design system.... See more

    {{ answer_favs.includes(254) ? "Saved" : "Save" }}

Address legacy code constraints when building a design system

  • Sam Soffes

    • Plan to coexist

      In a large legacy codebase, your fancy new design system code will have to coexist. Plan how the new things will interact with the old. Having the ability to rollout new things gradually instead of requiring a full rewrite will build confidence in the new system since it can prove itself as you rollout each new thing when it's ready instead of all at once at the end.... See more

    • Start to enforce best practices

      Jumping into a project with a legacy codebase can feel like the wild west. Bringing some consistency to the existing stuff with automated tools can help make migrating easier in the future. Source code linters to enforce best practice will make life a lot easier as you start migrating things.... See more

    • Replace as you go

      As you roll out new components, it will make things easier down the road if you can set aside some extra time to remove the legacy one and replace them with the new ones. This will remove any ambiguity about which one to use for new features.... See more

    {{ answer_favs.includes(255) ? "Saved" : "Save" }}

Keep design and engineering systems in sync

  • Sam Soffes

    • Always do a kickoff meeting

      When starting a new project, always do a kickoff meeting. It can be something as small as adding an icon to a button that previously only supported text or a huge new multiscreen flow. The designers and engineers working on the project meeting together before engineering starts to answer questions and iron out final details will make implementation go much smoother.... See more

    • Track changes for each team

      When you make a change to anything, it is important to track this in your task management system. Be sure to create a task for design to update their libraries and documentation as well as for engineering team to implement it on their platform. Being sure to create tasks for everything helps prevent things from getting list.... See more

    • Do regular audits

      Set aside time every month or so to audit all of the naming and features of everything in your system on each platform. Even if you are extremely diligent about keeping things in sync as you build it, it is very easy for things to start to drift away from consistency. Create tasks for each inconsistency for design and engineering and knock them out.... See more

    {{ answer_favs.includes(256) ? "Saved" : "Save" }}