6 ms·

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 f

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.

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.