[HN Gopher] Ship faster by building design systems slower (2023)
___________________________________________________________________
Ship faster by building design systems slower (2023)
Author : ohjeez
Score : 78 points
Date : 2024-02-25 15:22 UTC (7 hours ago)
(HTM) web link (bigmedium.com)
(TXT) w3m dump (bigmedium.com)
| thefourthchime wrote:
| 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 wrote:
| Ad hominem was not really the strongest argument but I agree
| with your stated reason in the second paragraph.
| twisteriffic wrote:
| 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 wrote:
| Almost argued against this for example then space industry, but
| it seems SpaceX is doing and progressing well and well within
| normal budgets
| ebiester wrote:
| 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 wrote:
| > 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
| dasil003 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > _Not doing something is not the same as not being able
| to do something_
|
| This is a vacuous statement. We can only look at what
| they write, not what they're thinking inside their head
| when they write it, so too for understanding whether they
| can _actually_ explain something or not. Telling someone
| to contact the author when the author themself can
| just...write it down in the initial article is
| uncharitable.
| moritzwarhier wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| zer00eyz wrote:
| I dont know that word has or hasn't killed any one.
|
| Excel and its piss poor interface has caused quite a bit
| of loss:
| https://www.computerworld.com/article/2533631/excel-
| error-le... (for your amusement, you should not feel bad
| for any one involved in this).
|
| And you're going to say "well they should have known
| that..." except that you, me, the average HN reader has a
| different relationship with tech than Joe and Jane
| average public.
| nostrademons wrote:
| 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 wrote:
| You are talking Agile.
| julienreszka wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| tuyiown wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| <cough> AUTODESK <cough>
| tomek_ycomb wrote:
| 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!
| gonzo41 wrote:
| I agree, however I would extend it too be even more pragmatic
| and say, just use html5. You can do everything you want with
| html5 for simple crud work. There's not need to be extra, and
| the main benefit of html5 is everything's really easy to use
| and accessible.
| kidfiji wrote:
| On the other hand, some companies really value design, or
| perhaps even find value out of good design :)
| jupp0r wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2024-02-25 23:00 UTC)