Hi guys, I have a question How do we start a design system? Should we go forward or backward? For example, should we design the basic things like color, typography, spacing first though we don't know how it works (forward) OR we design the component first and then secondly we design the basic? thanks =)
Here's my advice - don't worry about planning it that much, just start designing. Iterate fast, and see what works.
Start with a full complicated page, make multiple attempts, decide what parts work, cut the rest, repeat. Eventually you'll notice a system appearing.
This is a good starting point
wow, the "start with a full complicated page" was the best part, thank you so much
We faced the same challenge at Panera Bread over a year ago. We wanted to start our own Panera design system that could scale across all of our digital (and potentially in-café) experiences.
The answer that we found is that there is no right answer. @Eliot Slevin's point about iterating is spot on. At Panera we decided to utilize Google's Material Design system as our own starting point. Through our design process we constantly iterated and evaluated what parts of MD worked for us, and which parts didn't. Over a year later we have something that is pretty decent. It isn't perfect, but there's a structure to it that has really been working for us!
A few other existing design systems: Airbnb Design, Apple's iOS/macOS Human Interface Guidelines, IBM Design Language, Microsoft's Fluent Design System.
Remember that creating a scalable, flexible, and future-proof design framework takes a lot of time and hard work. So embrace the challenge and enjoy the process of carving out your own design system, one step at a time
thank you @Vincent Ngu, i get it, the point is iteration =)
Just curious, what made you guys start with MD instead of something else?
Curious: how did you involve developers and how were the iterations done?
I'm super curious about design systems that are iterated internally (ie. design team only) compared to how teams handle iterating upon a component that may be out in the wild already.
there's no formula, or specific design process to do it. ideas come and go, when it appears you'll notice!
You can start by sorting out all the small details and then go from that. or you can just sketch a page or some editorial, and go from that. use what you like, take off what you don't and go from that.
You need to find out, how (you or your team) works better. Don't make rules for it!
thanks for your advice! =)
if you get really stuck, find a few examples of sites you really like and start designing your project from those. Along the way, you'll probably want to change things, and eventually, you'll have your own!
thanks for your advice =)
We’ve had most success designing the foundations first and then approaching chunks (which then feeds back into the foundations).
The biggest thing here is make sure you align with development and DevOps (if the team has that capability). It’s important to have one single source of truth that can be iterated upon both in terms of front end dev and product design team members.
You could also start with a ‘hero’ project if the redesign is large/enterprise scale, (to prove the value of living design systems).
Any questions, let me know, happy to add further detail.
i have a question, what is the hero project looks like?
A ‘hero’ project is a smaller or simpler chunk of a larger platform, service or system, that is used to exemplify excellence.
For example, a human capital management platform might have many different digital products or platforms. The idea here would be to pick one and redesign (using a user-centred approach and design system thinking) to exemplify what good looks like and prove that the design system works seamlessly with DevOps.
I realise that this is mainly the case with enterprise projects. Not necessarily needed for smaller projects.
Hope that helps!
the biggest struggle I've had with any system or style component is alignment with development and developing a single source of truth.
What is your 'single source of truth'? and how did you iterate upon that? Is an iteration upon this source expected to affect all contexts that it's used in?
To answer your last question, the single source of truth is usually JSON files in Git repo. This is the single source of truth that then syndicates any changes to the entire product portfolio. There are many ways to do this, but it’s getting easier with the latest version of Sketch app.
I guess the most important thing to do is align with development from the off. This way they can start finding out the most efficient way of bringing in UI elements from Sketch App or Figma.
After a while development should have the base JSON to create elements that you can then start composing, (a bit like this: https://airbnb.design/painting-with-code/ ).
The aim is to pair your design ops with dev ops. I’ve only had experience creating this from scratch, but a few folks are starting to create UI kits that really help development e.g. http://reactsymbols.com
If you are struggling with aligning development, these are great resources to share with your design and dev team:
Thanks so much for the insight Stu, I'd seen that "Painting with code" article, and totally forgot about it.
Our org may not be totally equipped to do that, but knowing how one org does this helps us understand where we should be striving for.