This article originally appeared on onepixelout.com.
After the launch of a beautiful new product, or even the gradual improvements over time, you may find that the design begins to feel scattered and inconsistent. these are normal side effects of working and iteration over the same thing over a long period of time. This is when the Design System starts to get mentioned.
When you have multiple designers working on a single project, depending on the types of designers, you can encounter silos within the team.
Creating a Design System
If you find that your design team is growing, or there is interest in building new products at a rapid pace, investing time into creating a design system is incredibly worthwhile. The problem with the previous statement is the word “invest” — because this does require investment. A considerable amount.
I’ve worked in places before where it was mentioned numerous times how beneficial a design system would be, but there was no capacity to carry one out. This will require it’s own project management life-cycle — it will need to go on the kanban or scrum board. This is it’s own project, not something that will get done by itself. The team leads need to see this as a worthwhile investment, and you can help convince them so.
When done correctly, a design system can save a lot of time. But the work itself will take time.
So now that we’ve discussed the pros and cons of a design system, let’s look at 5 times that you can use today before you get started.
1. Do a Comprehensive Design Audit
Delegate someone from the team, or schedule a day yourself, to take screenshots of everything. This includes any system or promotional emails that are sent out, modals, interim states like loading icons and spinners, and error and empty states such as when the user doesn’t have access to wifi. Try to be as thorough and cover as much ground as you possibly can.
As we’ll see later, it’s best to just stick to the componenets that are currently being used in your products. Don’t stray too far from the existing implementation to keep the project scope manageable. The key to being able to do this is, of course, a comprehensive design audit.
Start gathering the different components and group like with like.
In the above example, we might take ‘form elements’ — and itemise the different elements in that category. Start at the top, and work your way down towards the details. Create the design system for the different kinds of input fields, the radio buttons, steppers, sliders, primary and secondary calls to action, drop down components and checkboxes.
When you have the input field design, work through the different states of that field — error, active, inactive, mandatory, optional…
2. Agree on the Final Documentation
Think about who the end user will be for this design system — will it be other designers on your team? Or external designers from an agency? Is it suitable if the design system only includes Sketch symbols? Or will front end code be required.
Outline this at the beginning and use it to help define the deliverables that will be required when the project is done.
Package your work to suit the end user. It may require more of a ‘read me’ type file to accompany the design assets if it is going to be used by an external agency. If it’s just within the in-house design team, you can schedule a session to introduce the system to any new designers who have joined the team.
3. Create Your Own Taxonomy
A lot has been written and published regarding design systems. There is a lot of great wisdom out there, but there is no ‘one size fits all’ scenario. Every project is different. Apps and websites all have a different critical user journey, a different suite of functionalities that require a different level of scope.
If you’re designing an ecommerce product, most of the design system will be focused on the product details pages and the checkout part. This is the bread and butter of any ecommerce platform.
If you’re designing for a food ordering website, showing the content in the menu, the customization options and the items in the order are your primary concern.
When creating a taxonomy, don’t get bogged down in the details just yet. Start at the top, and work your way down towards the details, and only build what you currently need.
4. Build What You Need
The biggest problem I have faced in the past when creating design system is the scope. I once was part of a team that set about designing for every possible component under the sun, and the project quickly spiraled out of control.
This shouldn’t be an impossible project. Keep the scope of the project under control by only building what you need, and nothing else.
Keep the scope of the project under control by only building what you need, and nothing else.
Limit the scope by only including the elements that are currently in your product. There is time for making it future proof later, but to make this project manageable, do what is necessary at this point. Adding new elements can come later, during the maintenance phase.
If you want to check out other design systems, by all means it’s a great way to get inspired, but take them with a grain of salt. Not every interface will include every single item.
The team leads will be grateful if you can keep the work under control. The sooner the investment starts to pay off, the better for everyone.
The greatest possible outcome of this project is to have an early working version of this system in production as quickly as possible, and you can then set about regularly updating and maintaining it.
5. Schedule Maintenance
Whenever a new feature gets added to the product, it needs to get added to the design system. If there are changes to the existing project, this also goes into the design system.
Products are always evolving and changing to improve the experience for the end users, and design systems can quickly go out of date if there is no elected team member who can oversee the maintenance of the files. Keep the system up to date. It is a valuable piece of information for any new designer starting the team, and is a time saving asset for building new features into the existing product.
In my experience it’s best to elect a single person who is responsible for committing changes to the design system.
Schedule maintenance sessions with the team every few weeks (or what ever frequency is best — every project is different) to reflect any changes that have been made, but only one person should make and save the changes.
It’s best to start small and get something together quickly, and grow it from there with regular maintenance sessions, than get bogged down with a daunting project from the start. Get things moving quickly and keep the team updated on your progress. Keep the momentum going. Be clear about what the final deliverable needs to look like, and things should hopefully go well.
Have you tried to create a design system? Did it go well, or did it fall apart? I would love to hear how it went. Please get in contact! You can usually reach me on twitter.