Design Systems: Working with Developers

In the previous article, we have seen why it is important not to neglect the developers but on the contrary to associate them with the creation of your design system. Now it's time to see how!

If you want to dig deeper, you can also read Leslie Pochat's article:
The Design System in 10 steps !

Step #1: Co-design

Co-design is an approach allowing the end user to be involved in the reflection and development of a service or a product.
This approach can be widely used with developers since they are the users of your design system.

You might be surprised by their ideas.

Step #2: Documentation

A design system built without proper documentation won't survive. It's as simple as that. If you don't have any documentation or if it is difficult to use or access, you run the risk that the development team will go for the simplest thing… and do without your work.

To ensure its success, good documentation must, in my opinion, meet the following requirements:

1. Be easily accessible

It's simple as all but give a name to your design system and create a web address (easily memorable). This will provide a rallying point and make the project more tangible. By the way, avoid if you can the software that the developer will have to install, this would generate an unnecessary point of friction especially if his need comes down to consultation.
Finally, structure your site as finely as possible according to your needs. Most often, documentation takes the following form: * General guidelines (colors, fonts, metrics, etc.) * Components * Resources (illustrations, graphic charter, logo, etc.)

But you could very well also structure your documentation by use, business, etc. It's up to you to see according to the problems of the company and its internal organization.

2. Be easy to use

Give direct access to the exploitable code, the visual and the rules and prohibitions of use of each component. If you're not in charge of integration, work closely with integrators to make updates as smooth and fast as possible.

3. Manage special cases

Manage all special cases, especially for your smallest components (and therefore often the most used) such as buttons, links, pop-ups, titles or menus... Clearly indicate the behavior you expect and the rules to be followed. respect. Manage them from the first deployment and not later. These are the cases that push the developer to break free from your design.

4. Present examples and scenarios

If you want to leave more freedom to the developer and allow him to compose the screens himself from your design system, don't forget to provide many practical examples and scenarios. Such as: Forms, Action Bars, Expanding Panels, Pop-ups, Page Transitions, Data Loading, etc.

5. Encourage quick returns

Your documentation will be as perfect as possible, but don't forget to provide a means for the developers to quickly exchange with you to erase small misunderstandings.

6. Inform quickly and clearly of the changes made and their possible impacts

One of the advantages of the design system is to be able to modify an element quickly and globally. It is also a risk because the smallest evolution can have a huge impact (such as a change in font size). Notify your users of any changes whether general or limited to a single component. And don't forget to list the potential impacts.

Step #3: Stay informed

Daily, end of sprints or even coffee machine, there are plenty of opportunities to keep you informed of the problems encountered by developers. Do not neglect these moments because this is where you will get the best feedback and information on the problems encountered.

Step #4: Validation

To measure whether your design is understood by users, that it is liked, in short that it works, there is a whole range of services to measure, quantify, track, alert. And to evaluate if your design is correctly deployed by the developers? It's more complicated.
But there are still tools to help you in your task.

A few among others: Pastel toy box CSSPeeper Flawless App

Step #5: The Design Review Meeting

Your design system is starting to turn? This is the right time to set up Design Review Meetings! The principle ? Establish a moment punctuating the sprints to validate the screens already developed but also to identify the problems in those under development. By formalizing these moments of sharing, you will accustom each team to discussing the other's issues and the developers to exercise their critical eye on ergonomics and compliance with your guidelines.

To go further on QA for design: The “Design Review” between Designers & Developers

Hugo, UX-Designer @UX-Republic