9 ms·

Ship faster by building design systems slower (2023)

134 points by ohjeez 3y ago

thefourthchime 3y ago
This text was authored by an individual who travels globally, educating people on interface design. Previously, he was a weightlifter and worked as a producer for PBS. I mention this because I find myself in complete disagreement with the article in question. It left me questioning the author's expertise in software, as it overlooks what I consider to be the cornerstone of software development: the iterative process. Contrary to the author's views, I advocate for minimal design upfront and urge rapid engagement with users. This is because requirements frequently evolve, often resulting in a project that differs significantly from its initial conception.
- iwontberude 3y ago
  Ad hominem was not really the strongest argument but I agree with your stated reason in the second paragraph.
  - twisteriffic 3y ago
    In my experience, following the advice given in the second paragraph is a good way to end up with both unmaintainable software and unhappy users. Having a design system upfront encourages consistency in visual and interaction design, and tends to nudge towards a consistent implementation. Consistent implementation is usually easier to iterate on, and tends to remain consistent with lower effort in the face of changing requirements. I've used products and worked on projects that were built using the "pure" iterative approach they're espousing. You can always tell, and it's never been positive.
- szundi 3y ago
  Almost argued against this for example then space industry, but it seems SpaceX is doing and progressing well and well within normal budgets
- ebiester 3y ago
  I think there are multiple phases of a product. At one end, you have a startup still searching for product market fit. You shouldn't have a design systems team in such an organization. Consistency doesn't matter because you might only have one instance of many design elements. However, would you feel the same if you were using Kayak and each page had a separate set of components? How would it feel if Slack had different dropdowns on their direct messages page than their channels? At some point, your users expect standardization and consistency, and you don't need every team deciding their buttons will be slightly different sizes and colors because of the team designer's tastes. It really is a spectrum; as your product matures and your brand identity finds success, the advice of the article becomes more and more important.
- Archelaos 3y ago
  > I mention this because I find myself in complete disagreement with the article in question. You are absolutely right. The article reminds me strongly of what Harry Frankfurt refers to in "On Bulshit".[1] If someone is not even remotely able to explain what moving fast actually means in his context, then everything and nothing follows from this. [1] https://en.wikipedia.org/wiki/On_Bullshit https://en.wikipedia.org/wiki/On_Bullshit
  - dasil003 3y ago
    How do you draw the conclusion that the author can't explain what he means by moving fast? Just because it wasn't adequately explained for someone with your worldview and experience doesn't mean that it's bullshit. Other possibilities are that if you had a face-to-face conversation he could explain it to you, or that you lack the domain experience and context to understand it. Personally as someone with 25 years web product engineering experience and working very closely with design at large companies, I can quibble with a lot of the details and phrasing, but the overall message makes a lot of sense, and I have personally witnessed the dysfunction of trying to evolve DLS elemtns at the same speed as day-to-day product design on more than one occasion.
    - Archelaos 3y ago
      > How do you draw the conclusion that the author can't explain what he means by moving fast? He just doesn't. Quote the passage were he does!
      - Jtsummers 3y ago
        Not doing something is not the same as not being able to do something. That should be pretty obvious to most people. Reach out and contact the author and find out rather than assuming that he's unable to explain what he means. His contact info is linked from the article page, click on his name.
        satvikpendem 3y ago
- moritzwarhier 3y ago
  Can't the author's view be fitted into an interative process though? Like, the design version of avoiding premature abstraction. He mentions "product teams" moving faster than the design system, which creates pressure to extend the design system. This can lead to flawed implementation of the design system. So maybe the product team should go with some band-aid during development if needed, and explicitly pass the requirements to the design system team, who can then refine and extract reusable components. Add of course, steady communication between people implementing features and people implementing design components should accompany this process. I am not sure if that's what TFA means, because I haven't read the whole thing. But I think design systems should be polished, simple, and provide a rock-solid API, and I think that the way to achieve this really might require patience. It's not even needed to have these tasks be distributed among strictly separate teams to follow this line of thought, right? Could be the guiding principle even of one single developer.
- Mtinie 3y ago
  The concept of “pace layers,” to me, is a way to describe the iterative process: 1. Determine the base requirements. 2. Build the first draft. 3. Determine what parts of the first draft are useful. Capture those in a design guide. 4. Iterate on the parts that were useful but not fully fleshed out. 5. Add refinements to the design guide. 6. Define adjusted and new requirements. Pull in elements from the design guide as applicable, design and build new elements when they don’t exist. 7. Repeat. (Note: I’m sure I truncated some steps you can fit in the flow) Design systems are living documentation and a lagged record of solutions that work in context. They are incomplete and will always be missing things but with each subsequent iteration they should continue to evolve and adapt. The design system moves at a slower velocity than the product development which informs it. This is why the phase layer model works well for me to help describe this iterative process. This compliments your desire for minimal design upfront and rapid development with engagement and validation with the people who are putting it to use. Addendum: Added note about layer velocities. Addendum 2: Fixed a few typos
- jjcm 3y ago
  Design systems PM for Figma here. What the author is saying here is correct for enterprise-scale companies. To your point where you urge for rapid iteration, if Microsoft launched a new product and needed all buttons to have a dropdown for said new product, would you update MS Word’s buttons to also have that dropdown? Of course not, and that’s the authors point. Product teams should move and iterate faster than the core design platform. They should be free to break from it for their exploratory needs, and these platform teams shouldn’t bend over backwards to support them. Another way I like to frame this is the following - a design systems team should support 90% of the use case needs of its products, not 100%. Adding support for that additional 10% often bloats the components and reduces usability and consumption. It’s often not worth that effort. New products are often rapidly evolving, and dwell in that 10% land quite a bit. Let them cook and experiment. If other teams end up adopting the same patterns, that’s when you bring it into the system.
  - zer00eyz 3y ago
    This mentality, of covering over software at the edge, is how we got the first crop of 737 max crashes. Bad software, shitty UI and a go fast culture. Its how were so capable of evolving dark patterns quickly... product creep mentality has trained the user base to go go go and not think. And the costs happen at the other end: it's the mental workload that happens when check boxes are toggles now. You can frame this however you want. In most cases it's unqualified people making expedient decisions that are just confusing to users outside the bubble of tech and PM that they live in. The people who are developing these projects keep jamming AI into everything... it doest matter that ML isnt ripe, that end users dont care, that it's not fit for purpose. I can point to massive piles of product innovation, design and feature creep that exists solely to pad the resumes of bad UX, product and engineering teams. Slow the fuck down and do some basic usability on your stupid idea. You might learn it sucks before it's in production further numbing your user base to your bullshit.
    - nostrademons 3y ago
      MS Word is dramatically different from a 737. If MS Word doesn't work quite right, people spend 5 minutes looking up a work-around, or live with not-quite-as-prettily-formatted documents. If a 737 doesn't work quite right, hundreds of people die. Basic table-stakes for having any sort of decision-making authority at a company is understanding the context of your decisions. A word processor that tries to get everything right hasn't launched yet. A airliner that moves fast and breaks things...well, breaks things.
- nostrademons 3y ago
  I think you're actually more in agreement with the author than you think you are. He's not arguing against iterative development at all. Rather he's arguing that product should evolve quickly and iteratively, and the design system underlying that product should move slowly and carefully, only systematizing aspects of the design once they have a large number of motivating examples. I think some of the confusion is a misunderstanding of what design systems (and each of the layers in the authors' diagram) is. It's different from design. "Design" is "This button should be 56px wide, have 8px of padding and be colored #4590ff". "Product" is "We are are building an app to let users listen to podcasts, and we should show a list of recommended next podcasts with a button beside each to play, but default to autoplaying the next one if no user interaction happens." "Product research" is "Our users frequently listen to podcasts in the car, so they may need hands-free interaction and will want to listen to the next track without user intervention." "Visual brand" is "Across all of our products, we like to use a simple white background, with dashed-line dividers between list items and #4590ff primary call to action buttons, each of which has 8px of padding and 4px rounded corners." "Design systems" is "Across all our products, use a list whenever you have a collection of homogenous items. If the list represents an audio multimedia track, use this music icon that we have uploaded to the general library. The currently playing audio track should have a moving audio signal display to indicate its selected status." Notice the increasing level of abstraction across each of these categories. Design is rules for users. Design systems is rules for designers. And that's exactly why it should move slowly - you cannot build good rules until you have seen many instances of problems in the real world and have a chance to gather data across many instances of the pattern. In my experience, design should iterate ~daily. Product ~monthly. UXR ~quarterly. Visual brand ~annually. And design systems every 2-3 years. The differing cadence is a rough indication of how many examples of each lower level you need to build a general pattern, eg. you may have 20 or so individual design decisions to make to ship a feature, you might ship 3 features from each UX insight, you might refresh the whole product's UI roughly each year as the market changes, and you need experience from 2-3 full visual refreshes to understand what sort of patterns need to form guidance for the next generation of designers.
- begueradj 3y ago
  You are talking Agile.
julienreszka 3y ago
Design is really NOT a big deal. It has been overhyped over the last decade. It is NOT a competitive advantage and if anything it hinders innovation. Please STOP putting such a high importance on design. Much more important aspects of products that have been widely neglected over the past decade: - data portability - privacy - reliability - extensibility
- jawns 3y ago
  I think you might be using "design" to refer to visual design or UX design. But this article is about system design, which encompasses the factors you've described above.
  - jsunderland323 3y ago
    It’s not about system design. It’s about design systems, which are custom UI component libraries used across a product or set of products to enforce UI consistency and code re-usability.
- jahewson 3y ago
  Design = thinking things through. If that’s not a competitive advantage, I don’t what is. You must see the irony in advocating for 4 things that the market has proven it doesn’t particularly value as being some kind of advantage?
  - julienreszka 3y ago
    I think you missed my point entirely. The value of design is in a bubble (hype) and the data portability, privacy, reliability, extensibility are undervalued. There is a huge market distortion caused by incumbent big companies who benefit from the bubble and the undervaluation of data portability, privacy, reliability, extensibility.
  - yencabulator 3y ago
    I've yet to see a web designer or graphic designer think things through. My experience is that they're entry level freelancers that perform the exact task requested, nothing else, and e.g. consistency has to be handled above their pay grade. I don't think I can agree to your definition of the word design. Checking https://en.m.wiktionary.org/wiki/design https://en.m.wiktionary.org/wiki/design, these two sound like what you're talking about: > 1. A specification of an object or process, referring to requirements to be satisfied and thus conditions to be met for them to solve a problem. > 2. A plan (with more or less detail) for the structure and functions of an artifact, building or system. But these sound like what a web designer or graphic designer do. And they are more about being artistic than about thinking things through: > 3. A pattern, as an element of a work of art or architecture. > 4. The composition of a work of art. > 6. The shape or appearance given to an object, especially one that is intended to make it more attractive. > 7. The art of designing > Danish furniture design is world-famous.
tuyiown 3y ago
This is personal branding designed to awe and audience with little actionable advice. Like everything in the like, there are some truths: mindset based around path with incremental improvement fares better that holistic-first approaches. The abstract concepts with false depth doesn't help on the key subject. I would paraphrase the entire article by saying that the only way to ship fast and good is to in depth on designed simple reusables, build your product around an integration of those simple reusables, take measure of the complexity of the result, and then go on understanding how to improve while keeping and eye on overall complexity.
kabes 3y ago
Companies should just stop thinking they need their own design system. There's zero value in reinventing how buttons and inputs should look like. I've worked for many companies, big and small, and they all had the arrogance to believe they need their own component libraries, reinventing the wheel out of ego. My advice: you're not that special, just pick a component library and spend your precious time building actual value.
- jupp0r 3y ago
  They can use a headless component library and style it to their liking. I generally agree with you though. I've seen some really really badly made home grown component libraries that could have just been MUI (or others like it) with custom styles for a fraction of the cost and with much better results.
- PTOB 3y ago
  <cough> AUTODESK <cough>
  - tomek_ycomb 3y ago
    I'm not sure, is Autodesk a good answer? Wouldn't they be in the business of design and perhaps not a standard company that shouldn't do custom? Maybe I misunderstood the point though!
  - yencabulator 3y ago
    Autodesk's CAD stuff started life in the early 80s and needed to do plenty of trailblazing on fundamental concept of CAD user interface. They have a well-established client base that rely on intricate details of the interface. By its very nature their product is aimed at experts well educated in their domain. Meanwhile, companies that burn most effort into "design systems" seem to be heavily B2C, and mostly concerned about getting their colors to pop, fonts to be fancy, and buttons to be rounded. (Or old ancients like IBM that are just so big that they probably are among the few exceptions to the rule and actually need a design system![1]) Not a great comparison. [1]: Love me some slashed or dotted-0 fonts. Thank you IBM for popularizing that.
- 3y ago
jupp0r 3y ago
This article is stating the obvious about any software abstraction: Don't over generalize up front but look at commonly used patterns and create abstractions from there that fit many use cases. At the same time, there are common patterns that people expect to be there (a button component), and I'm always shocked when design system teams spend tons of money writing their own vs reusing other existing component libraries. On top of this all: component libraries need to take tons of non functional requirements into account nowadays (SSR compatibility, lazy loading data for paginated tables and how components interact with hybrid sever/client data loaders, offline caching of rendered components in service workers, etc), so not having some really good actual software engineers on the "design system team" can end in total disasters.
navane 3y ago
I see this more and more, overly generic team and function names: design system. System engineer. Words like system and design are meaningless, could mean anything. We're all working in a context, so we're all part of a system, everything is a system. None of us are stacking bricks in a predetermined shape, we are all designing.

134 points by ohjeez 3y ago

This text was authored by an individual who travels globally, educating people on interface design. Previously, he was a weightlifter and worked as a producer for PBS. I mention this because I find myself in complete disagreement with the article in question. It left me questioning the author's expertise in software, as it overlooks what I consider to be the cornerstone of software development: the iterative process. Contrary to the author's views, I advocate for minimal design upfront and urge rapid engagement with users. This is because requirements frequently evolve, often resulting in a project that differs significantly from its initial conception.

iwontberude 3y ago
Ad hominem was not really the strongest argument but I agree with your stated reason in the second paragraph.
- twisteriffic 3y ago
  In my experience, following the advice given in the second paragraph is a good way to end up with both unmaintainable software and unhappy users. Having a design system upfront encourages consistency in visual and interaction design, and tends to nudge towards a consistent implementation. Consistent implementation is usually easier to iterate on, and tends to remain consistent with lower effort in the face of changing requirements. I've used products and worked on projects that were built using the "pure" iterative approach they're espousing. You can always tell, and it's never been positive.
szundi 3y ago
Almost argued against this for example then space industry, but it seems SpaceX is doing and progressing well and well within normal budgets
ebiester 3y ago
I think there are multiple phases of a product. At one end, you have a startup still searching for product market fit. You shouldn't have a design systems team in such an organization. Consistency doesn't matter because you might only have one instance of many design elements. However, would you feel the same if you were using Kayak and each page had a separate set of components? How would it feel if Slack had different dropdowns on their direct messages page than their channels? At some point, your users expect standardization and consistency, and you don't need every team deciding their buttons will be slightly different sizes and colors because of the team designer's tastes. It really is a spectrum; as your product matures and your brand identity finds success, the advice of the article becomes more and more important.
Archelaos 3y ago
> I mention this because I find myself in complete disagreement with the article in question. You are absolutely right. The article reminds me strongly of what Harry Frankfurt refers to in "On Bulshit".[1] If someone is not even remotely able to explain what moving fast actually means in his context, then everything and nothing follows from this. [1] https://en.wikipedia.org/wiki/On_Bullshit https://en.wikipedia.org/wiki/On_Bullshit
- dasil003 3y ago
  How do you draw the conclusion that the author can't explain what he means by moving fast? Just because it wasn't adequately explained for someone with your worldview and experience doesn't mean that it's bullshit. Other possibilities are that if you had a face-to-face conversation he could explain it to you, or that you lack the domain experience and context to understand it. Personally as someone with 25 years web product engineering experience and working very closely with design at large companies, I can quibble with a lot of the details and phrasing, but the overall message makes a lot of sense, and I have personally witnessed the dysfunction of trying to evolve DLS elemtns at the same speed as day-to-day product design on more than one occasion.
  - Archelaos 3y ago
    > How do you draw the conclusion that the author can't explain what he means by moving fast? He just doesn't. Quote the passage were he does!
    - Jtsummers 3y ago
      Not doing something is not the same as not being able to do something. That should be pretty obvious to most people. Reach out and contact the author and find out rather than assuming that he's unable to explain what he means. His contact info is linked from the article page, click on his name.
      - satvikpendem 3y ago
moritzwarhier 3y ago
Can't the author's view be fitted into an interative process though? Like, the design version of avoiding premature abstraction. He mentions "product teams" moving faster than the design system, which creates pressure to extend the design system. This can lead to flawed implementation of the design system. So maybe the product team should go with some band-aid during development if needed, and explicitly pass the requirements to the design system team, who can then refine and extract reusable components. Add of course, steady communication between people implementing features and people implementing design components should accompany this process. I am not sure if that's what TFA means, because I haven't read the whole thing. But I think design systems should be polished, simple, and provide a rock-solid API, and I think that the way to achieve this really might require patience. It's not even needed to have these tasks be distributed among strictly separate teams to follow this line of thought, right? Could be the guiding principle even of one single developer.
Mtinie 3y ago
The concept of “pace layers,” to me, is a way to describe the iterative process: 1. Determine the base requirements. 2. Build the first draft. 3. Determine what parts of the first draft are useful. Capture those in a design guide. 4. Iterate on the parts that were useful but not fully fleshed out. 5. Add refinements to the design guide. 6. Define adjusted and new requirements. Pull in elements from the design guide as applicable, design and build new elements when they don’t exist. 7. Repeat. (Note: I’m sure I truncated some steps you can fit in the flow) Design systems are living documentation and a lagged record of solutions that work in context. They are incomplete and will always be missing things but with each subsequent iteration they should continue to evolve and adapt. The design system moves at a slower velocity than the product development which informs it. This is why the phase layer model works well for me to help describe this iterative process. This compliments your desire for minimal design upfront and rapid development with engagement and validation with the people who are putting it to use. Addendum: Added note about layer velocities. Addendum 2: Fixed a few typos
jjcm 3y ago
Design systems PM for Figma here. What the author is saying here is correct for enterprise-scale companies. To your point where you urge for rapid iteration, if Microsoft launched a new product and needed all buttons to have a dropdown for said new product, would you update MS Word’s buttons to also have that dropdown? Of course not, and that’s the authors point. Product teams should move and iterate faster than the core design platform. They should be free to break from it for their exploratory needs, and these platform teams shouldn’t bend over backwards to support them. Another way I like to frame this is the following - a design systems team should support 90% of the use case needs of its products, not 100%. Adding support for that additional 10% often bloats the components and reduces usability and consumption. It’s often not worth that effort. New products are often rapidly evolving, and dwell in that 10% land quite a bit. Let them cook and experiment. If other teams end up adopting the same patterns, that’s when you bring it into the system.
- zer00eyz 3y ago
  This mentality, of covering over software at the edge, is how we got the first crop of 737 max crashes. Bad software, shitty UI and a go fast culture. Its how were so capable of evolving dark patterns quickly... product creep mentality has trained the user base to go go go and not think. And the costs happen at the other end: it's the mental workload that happens when check boxes are toggles now. You can frame this however you want. In most cases it's unqualified people making expedient decisions that are just confusing to users outside the bubble of tech and PM that they live in. The people who are developing these projects keep jamming AI into everything... it doest matter that ML isnt ripe, that end users dont care, that it's not fit for purpose. I can point to massive piles of product innovation, design and feature creep that exists solely to pad the resumes of bad UX, product and engineering teams. Slow the fuck down and do some basic usability on your stupid idea. You might learn it sucks before it's in production further numbing your user base to your bullshit.
  - nostrademons 3y ago
    MS Word is dramatically different from a 737. If MS Word doesn't work quite right, people spend 5 minutes looking up a work-around, or live with not-quite-as-prettily-formatted documents. If a 737 doesn't work quite right, hundreds of people die. Basic table-stakes for having any sort of decision-making authority at a company is understanding the context of your decisions. A word processor that tries to get everything right hasn't launched yet. A airliner that moves fast and breaks things...well, breaks things.
nostrademons 3y ago
I think you're actually more in agreement with the author than you think you are. He's not arguing against iterative development at all. Rather he's arguing that product should evolve quickly and iteratively, and the design system underlying that product should move slowly and carefully, only systematizing aspects of the design once they have a large number of motivating examples. I think some of the confusion is a misunderstanding of what design systems (and each of the layers in the authors' diagram) is. It's different from design. "Design" is "This button should be 56px wide, have 8px of padding and be colored #4590ff". "Product" is "We are are building an app to let users listen to podcasts, and we should show a list of recommended next podcasts with a button beside each to play, but default to autoplaying the next one if no user interaction happens." "Product research" is "Our users frequently listen to podcasts in the car, so they may need hands-free interaction and will want to listen to the next track without user intervention." "Visual brand" is "Across all of our products, we like to use a simple white background, with dashed-line dividers between list items and #4590ff primary call to action buttons, each of which has 8px of padding and 4px rounded corners." "Design systems" is "Across all our products, use a list whenever you have a collection of homogenous items. If the list represents an audio multimedia track, use this music icon that we have uploaded to the general library. The currently playing audio track should have a moving audio signal display to indicate its selected status." Notice the increasing level of abstraction across each of these categories. Design is rules for users. Design systems is rules for designers. And that's exactly why it should move slowly - you cannot build good rules until you have seen many instances of problems in the real world and have a chance to gather data across many instances of the pattern. In my experience, design should iterate ~daily. Product ~monthly. UXR ~quarterly. Visual brand ~annually. And design systems every 2-3 years. The differing cadence is a rough indication of how many examples of each lower level you need to build a general pattern, eg. you may have 20 or so individual design decisions to make to ship a feature, you might ship 3 features from each UX insight, you might refresh the whole product's UI roughly each year as the market changes, and you need experience from 2-3 full visual refreshes to understand what sort of patterns need to form guidance for the next generation of designers.
begueradj 3y ago
You are talking Agile.

julienreszka 3y ago

Design is really NOT a big deal. It has been overhyped over the last decade. It is NOT a competitive advantage and if anything it hinders innovation. Please STOP putting such a high importance on design. Much more important aspects of products that have been widely neglected over the past decade: - data portability - privacy - reliability - extensibility

jawns 3y ago
I think you might be using "design" to refer to visual design or UX design. But this article is about system design, which encompasses the factors you've described above.
- jsunderland323 3y ago
  It’s not about system design. It’s about design systems, which are custom UI component libraries used across a product or set of products to enforce UI consistency and code re-usability.
jahewson 3y ago
Design = thinking things through. If that’s not a competitive advantage, I don’t what is. You must see the irony in advocating for 4 things that the market has proven it doesn’t particularly value as being some kind of advantage?
- julienreszka 3y ago
  I think you missed my point entirely. The value of design is in a bubble (hype) and the data portability, privacy, reliability, extensibility are undervalued. There is a huge market distortion caused by incumbent big companies who benefit from the bubble and the undervaluation of data portability, privacy, reliability, extensibility.
- yencabulator 3y ago
  I've yet to see a web designer or graphic designer think things through. My experience is that they're entry level freelancers that perform the exact task requested, nothing else, and e.g. consistency has to be handled above their pay grade. I don't think I can agree to your definition of the word design. Checking https://en.m.wiktionary.org/wiki/design https://en.m.wiktionary.org/wiki/design, these two sound like what you're talking about: > 1. A specification of an object or process, referring to requirements to be satisfied and thus conditions to be met for them to solve a problem. > 2. A plan (with more or less detail) for the structure and functions of an artifact, building or system. But these sound like what a web designer or graphic designer do. And they are more about being artistic than about thinking things through: > 3. A pattern, as an element of a work of art or architecture. > 4. The composition of a work of art. > 6. The shape or appearance given to an object, especially one that is intended to make it more attractive. > 7. The art of designing > Danish furniture design is world-famous.

tuyiown 3y ago

This is personal branding designed to awe and audience with little actionable advice. Like everything in the like, there are some truths: mindset based around path with incremental improvement fares better that holistic-first approaches. The abstract concepts with false depth doesn't help on the key subject. I would paraphrase the entire article by saying that the only way to ship fast and good is to in depth on designed simple reusables, build your product around an integration of those simple reusables, take measure of the complexity of the result, and then go on understanding how to improve while keeping and eye on overall complexity.

kabes 3y ago

Companies should just stop thinking they need their own design system. There's zero value in reinventing how buttons and inputs should look like. I've worked for many companies, big and small, and they all had the arrogance to believe they need their own component libraries, reinventing the wheel out of ego. My advice: you're not that special, just pick a component library and spend your precious time building actual value.

jupp0r 3y ago
They can use a headless component library and style it to their liking. I generally agree with you though. I've seen some really really badly made home grown component libraries that could have just been MUI (or others like it) with custom styles for a fraction of the cost and with much better results.
PTOB 3y ago
<cough> AUTODESK <cough>
- tomek_ycomb 3y ago
  I'm not sure, is Autodesk a good answer? Wouldn't they be in the business of design and perhaps not a standard company that shouldn't do custom? Maybe I misunderstood the point though!
- yencabulator 3y ago
  Autodesk's CAD stuff started life in the early 80s and needed to do plenty of trailblazing on fundamental concept of CAD user interface. They have a well-established client base that rely on intricate details of the interface. By its very nature their product is aimed at experts well educated in their domain. Meanwhile, companies that burn most effort into "design systems" seem to be heavily B2C, and mostly concerned about getting their colors to pop, fonts to be fancy, and buttons to be rounded. (Or old ancients like IBM that are just so big that they probably are among the few exceptions to the rule and actually need a design system![1]) Not a great comparison. [1]: Love me some slashed or dotted-0 fonts. Thank you IBM for popularizing that.
3y ago

jupp0r 3y ago

This article is stating the obvious about any software abstraction: Don't over generalize up front but look at commonly used patterns and create abstractions from there that fit many use cases. At the same time, there are common patterns that people expect to be there (a button component), and I'm always shocked when design system teams spend tons of money writing their own vs reusing other existing component libraries. On top of this all: component libraries need to take tons of non functional requirements into account nowadays (SSR compatibility, lazy loading data for paginated tables and how components interact with hybrid sever/client data loaders, offline caching of rendered components in service workers, etc), so not having some really good actual software engineers on the "design system team" can end in total disasters.

navane 3y ago

I see this more and more, overly generic team and function names: design system. System engineer. Words like system and design are meaningless, could mean anything. We're all working in a context, so we're all part of a system, everything is a system. None of us are stacking bricks in a predetermined shape, we are all designing.