Delay your design system
Note: For startups. Having mature methods almost always will become a requirement as the company scales to avoid UI level problems and engineering rework. That's also when your app will be a white sheet with floating text and elements in a grid or list layout."
Design system rarely does any good to designers except make them lazy. It should rather be pitched by engineering. All teams irrespective of the size define a surface, spatial, type, color, etc anyway with no need for DS. At an early stage “just enough” works better.
One overly used argument I get is “Design System helps bring consistency”. While absolutely true, but don’t build a DS for that, paying attention to details as a team with shared underlying rules works as much and is rather low on cost and effort.
At most places, if you want to standardize your appearance across copy, marketing, & product - building a Brand Language System with a centralized creative library is a good approach. Duolingo does this great. design.duolingo.com
First, DYOD - do your own design. You have the data, you have your team, you know your requirements, you bet on things, you move the metric either way. You compile learnings and repeat or change strategy. You do it all ruthlessly.
Once the product is stable enough to treat activation as “one of the” problems, time to stop working on PRDs and start working with your PM. That’s also the transition from a customer-centric to a user-centric team. This should be a good time to start thinking towards a systematic way to design across verticals.
By this time, all teams across different lines of businesses have created enough ambiguities and have made themselves aware of the same that a pitch to work together and unify structure sounds very helpful. Alignment comes easy even in areas owned by no one.
An early product team at any time is opinionated. You work on software making & breaking things to define your “this works but we won’t do it” and "let's double down and productize this". Unless you have uncovered the extent of business you can do, and with what values, you need to be experimental and inconsistent to survive.
So till the time you are establishing market fit, creating a DS isn’t the best use of design’s time. Standardization robs your team of the ability to explore. That well is just part of the problem. Even if you build a DS, the second problem is to figure out who’ll own it.
It costs innovation. Become a boring place to work before building a Design System. What bugs me is also the fact that most good examples of DS come from enterprise software. And Atomic Design is too heavy of a framework to guide development for consumer tech where platform engagement is a never-ending project and often demands pattern-breaking iterations.
© Divya Kant Singh
Software & Interaction Designer
Delay your design system
Note: For startups. Having mature methods almost always will become a requirement as the company scales to avoid UI level problems and engineering rework. That's also when your app will be a white sheet with floating text and elements in a grid or list layout."
Design system rarely does any good to designers except make them lazy. It should rather be pitched by engineering. All teams irrespective of the size define a surface, spatial, type, color, etc anyway with no need for DS. At an early stage “just enough” works better.
One overly used argument I get is “Design System helps bring consistency”. While absolutely true, but don’t build a DS for that, paying attention to details as a team with shared underlying rules works as much and is rather low on cost and effort.
At most places, if you want to standardize your appearance across copy, marketing, & product - building a Brand Language System with a centralized creative library is a good approach. Duolingo does this great. design.duolingo.com
First, DYOD - do your own design. You have the data, you have your team, you know your requirements, you bet on things, you move the metric either way. You compile learnings and repeat or change strategy. You do it all ruthlessly.
Once the product is stable enough to treat activation as “one of the” problems, time to stop working on PRDs and start working with your PM. That’s also the transition from a customer-centric to a user-centric team. This should be a good time to start thinking towards a systematic way to design across verticals.
By this time, all teams across different lines of businesses have created enough ambiguities and have made themselves aware of the same that a pitch to work together and unify structure sounds very helpful. Alignment comes easy even in areas owned by no one.
An early product team at any time is opinionated. You work on software making & breaking things to define your “this works but we won’t do it” and "let's double down and productize this". Unless you have uncovered the extent of business you can do, and with what values, you need to be experimental and inconsistent to survive.
So till the time you are establishing market fit, creating a DS isn’t the best use of design’s time. Standardization robs your team of the ability to explore. That well is just part of the problem. Even if you build a DS, the second problem is to figure out who’ll own it.
It costs innovation. Become a boring place to work before building a Design System. What bugs me is also the fact that most good examples of DS come from enterprise software. And Atomic Design is too heavy of a framework to guide development for consumer tech where platform engagement is a never-ending project and often demands pattern-breaking iterations.
© Divya Kant Singh
Software & Interaction Designer
Delay your design system
Note: For startups. Having mature methods almost always will become a requirement as the company scales to avoid UI level problems and engineering rework. That's also when your app will be a white sheet with floating text and elements in a grid or list layout."
Design system rarely does any good to designers except make them lazy. It should rather be pitched by engineering. All teams irrespective of the size define a surface, spatial, type, color, etc anyway with no need for DS. At an early stage “just enough” works better.
One overly used argument I get is “Design System helps bring consistency”. While absolutely true, but don’t build a DS for that, paying attention to details as a team with shared underlying rules works as much and is rather low on cost and effort.
At most places, if you want to standardize your appearance across copy, marketing, & product - building a Brand Language System with a centralized creative library is a good approach. Duolingo does this great. design.duolingo.com
First, DYOD - do your own design. You have the data, you have your team, you know your requirements, you bet on things, you move the metric either way. You compile learnings and repeat or change strategy. You do it all ruthlessly.
Once the product is stable enough to treat activation as “one of the” problems, time to stop working on PRDs and start working with your PM. That’s also the transition from a customer-centric to a user-centric team. This should be a good time to start thinking towards a systematic way to design across verticals.
By this time, all teams across different lines of businesses have created enough ambiguities and have made themselves aware of the same that a pitch to work together and unify structure sounds very helpful. Alignment comes easy even in areas owned by no one.
An early product team at any time is opinionated. You work on software making & breaking things to define your “this works but we won’t do it” and "let's double down and productize this". Unless you have uncovered the extent of business you can do, and with what values, you need to be experimental and inconsistent to survive.
So till the time you are establishing market fit, creating a DS isn’t the best use of design’s time. Standardization robs your team of the ability to explore. That well is just part of the problem. Even if you build a DS, the second problem is to figure out who’ll own it.
It costs innovation. Become a boring place to work before building a Design System. What bugs me is also the fact that most good examples of DS come from enterprise software. And Atomic Design is too heavy of a framework to guide development for consumer tech where platform engagement is a never-ending project and often demands pattern-breaking iterations.
© Divya Kant Singh
Software & Interaction Designer