Continued from Part 1

What components to standardise (and what not to)

It can sometimes be hard to know where to start and stop with standardisation so it’s worth developing a process for making the decision on a per-component basis. Over time I've defined a rough decision tree template that works as a starting point:

This process is not one-size-fits-all and will probably need tweaks to fit your use case but having a defined process forces you and the wider team to really think about the component in question and avoid the pitfall of over-standardisation and unnecessary complexity.

Stay out of debt

Design systems can quickly grow over time based on the projects’ needs and build up design and tech debt in the process, so finding ways to avoid the backlog getting out of hand from the get-go is pivotal.

Practices that can help:

• Avoiding over-standardisation. Look at What components to standardise (and what not to) above for more.
• Design system mini sprints. Dedicating time (ideally a week) each quarter to design & tech debt can be massively beneficial to your system's long-term health, rather than chasing your own tail and trying to update the system alongside the product's development.
• Being decisive. Making regular incremental iterations on your standards or components due to indecision can pile up work, so instead spend a little extra time on your initial sign-off to get it right, and then release spaced updates to the system in bigger chunks going forward.
• Design team alignment. Regular flowing communication and clear documentation on the system can avoid inconsistencies in use or misapplication of styles and components. See Be inclusive along the way below for more.
• Preventing tight deadlines. Rushing the design process can lead to many issues like design standards being misused or creating duplicate components which will inevitably build debt and waste valuable time when the mistakes have to be corrected.

Be inclusive along the way

The best practice to adopt  for your design system from the start is communication, because working in a silo can be the downfall of even the best of systems. If no one knows how the system works it’ll inevitably be misused, misimplemented and in the worst cases, not used at all. This has become a bigger risk with the rise of remote working so it's worth following some guidelines to keep on top of things:

• Regular check-ins. Book weekly or bi-weekly design system check-ins with the design team to review updates, gather feedback or new requirements and allow for questions.
• Include development. Include your lead front-end dev on component sign-off calls for their insights on technical limitations or problematic styles.
• Share the know-how. Set up optional knowledge sharing or mentoring sessions for your design team to teach the inner workings of the system.
• Clear documentation. Ensure documentation is crystal clear, for both designers and developers to understand.
• “What’s new” summaries. When your design system is in flow, consider sending out short regular summaries on new additions and changes to the design and front-end dev teams.

Keep your developer(s) happy

Clear design handoff for the systems styles and components is critical to a successful system setup. Minimising as many misunderstandings before implementation should be the goal. The onus of clarity is on you so here are a couple of tips for a clean hand-off:

• Communicate with your developer(s). I’ve always highly valued face-to-face or video call conversations to explain designs directly to a developer. Making yourself approachable to your dev(s) is the single best way you’ll avoid mishaps in implementation.
• More annotation. Annotate the hell out of components, highlighting subtle styles, explaining intended behaviours and answering anticipated questions around edge cases. (you can’t anticipate everything and if you have good devs they’ll probably find questions you haven’t thought of)
• Recorded prototypes. If time permits, attaching a video to the ticket that clearly shows the component in use and its intended look & feel can go a long way.
• Define “nice-to-haves”. When working on fast-paced projects it’s valuable that you identify parts of a component that are not crucial to its functionality (like complex animations) so you can make compromises for a first version if needed.

Developers aren’t designers so don’t expect them to be

It’s easy to get frustrated when things go wrong and blame a botched implementation on the developer, but more often than not we haven’t communicated our design well enough and we need to look inwards at how we can refine our hand-off process.

Don’t suffocate creativity

When you’re given the reins to define standards for an entire design team you have to be considerate of the fact that other designers don’t think like you and don’t design like you. If you're not cognisant of that you can end up stifling creative thinking forcing standards that are too strict and rigid.

This often hurts most in your pattern library, as it can dictate standard layouts for your pages. Tread carefully when setting these patterns, only defining things that should stay consistent (like navigation) and making sure they’re flexible enough to encourage creative thinking.

For us designers, the purpose of the design system is to help us be more efficient when solving a design problem but not to solve the problem itself. It would be a massive disservice to call us designers if all we were reduced to was dragging and dropping preset layouts from a design library and calling it a day.

Conclusion

Design systems are inherently complicated and will always throw up a couple of surprises that you couldn't foresee but when the proper amount of time and care is taken to build one, it’ll unlock the potential of your product & team. Hopefully, some of these learnings and guidelines help set up your system for success.

Thank you for reading!