[HN Gopher] It's weird how design systems are so rote, yet so di...
___________________________________________________________________
It's weird how design systems are so rote, yet so difficult
Author : qkeast
Score : 123 points
Date : 2023-12-13 14:17 UTC (8 hours ago)
(HTM) web link (quinnkeast.com)
(TXT) w3m dump (quinnkeast.com)
| mkl95 wrote:
| > A lack of actual (not assumed) alignment within teams and
| leadership around what a design system is, what problems it
| solves, and how it will provide value.
|
| I would describe it as "design systems are difficult because
| people are difficult".
|
| Working with the average SaaS component can lead you into a muddy
| spaghetti rabbit hole where you can tell every dev who has worked
| with it was not following any particular way of doing things
| other than "making it work". Including yourself.
| danielvaughn wrote:
| I've been following the design system space for a while, and it's
| mildly entertaining to watch from the perspective of an engineer.
| Because you see designers fall into the exact same traps and
| encounter the exact same issues that engineers have long faced.
|
| Optimize for flexibility and you'll end up with something that's
| way too complex. Optimize for speed and you'll regret it down the
| road. Everything's a tradeoff, but the only guarantee is that at
| some point, you'll feel a distinct urge to throw it all away and
| start over.
| qkeast wrote:
| Agreed. I think part of the challenge is that design systems
| are inherently owned across design and engineering (not just
| the design team), but the overall understanding of what a
| design system is means that few folks involved really
| understand where and how to make decisions about those
| tradeoffs.
| danielvaughn wrote:
| Yep. As for what a design system "is", one thing I've always
| disagreed with is that it's referred to as a _thing_ , like
| it's an artifact or output. I like to think of it as a
| process, as in _designing systematically_. I also think that
| the notion of systematic design comes into play even at very
| small scale - it 's not something that's only relevant to
| large teams. I call it vertical vs horizontal design.
|
| Before the digital era, designers typically worked on things
| like posters, advertisements, book covers, etc - scenarios
| where you have a single context and multiple graphical
| elements that need to co-exist in harmony. This is vertical
| design - one context with multiple elements.
|
| For digital applications, another dimension is introduced.
| Because now you'll have multiple pages, views, etc, with some
| repeating elements. So like a button that exists on both the
| signup page as well as a checkout page. You may not need the
| buttons to look exactly the same, but they need to co-exist
| in harmony with one another just as they do in their
| surrounding context. So now you have one element with
| multiple contexts - what I call horizontal design. This
| second dimension is what requires a shift in thinking from
| designers to an approach I would call "systematic."
|
| Figma is the first product that takes horizontal design
| seriously, with the introduction of variants and variables
| and all that. But there hasn't really been a tool that bakes
| it in from the beginning.
| bobthepanda wrote:
| There is a bit of history in this; Pantone made a whole
| business out of color consistency across media for
| branding, coming out of any possible print shop or factory
| or whatever. And fonts have a similar history.
|
| Now, the brand is so much more than that.
| waldothedog wrote:
| You might be interested in "Integrated branding" and/or
| visual identity systems, including the use of "parametric"
| design, grids, and variables, going back at least 50 years.
| You're 100% right that there is a tension between the
| outputs/artifacts and the generator (process/logic). This
| often is a challenging aspect of design education programs.
| Figma's explicit structure, and certainly their community
| as well as the rise of design within software, have made
| this more visible and tangible. But this is an old tension
| rather than a new one.
| danielvaughn wrote:
| Interesting, will check it out. I've done some research
| on parametric design, but from what I've read, it's
| mostly been applied to architecture and some aspects of
| 3D modeling. Which is kind of a shame, because it's
| really neat. I'm actually building a "programming
| language" for designers that is essentially a parametric
| design language.
| chrisweekly wrote:
| Agreed. I'd take it even further, framing it as more of a
| 3-way venn intersection of design/ux + engineering + product.
| I have lots of related experience and many more thoughts to
| share, if others are interested....
| xdennis wrote:
| This is similar to linguistics. People often rank languages in
| terms of difficulty, but in reality complexity is just moved
| around.
|
| For example in English words are often uninflected. Languages
| like Hungarian/Turkish have a lot of prefixes/suffixes. You'd
| think that means they're a lot more complicated, but in reality
| their prefixes/suffixes are very predictable whereas English is
| all over the place. Is it noninflected, disinflected,
| deinflected, ininflected, flected?
| solardev wrote:
| Not being a linguist, what is a flec?
| PeterisP wrote:
| Having a set of related wordforms of a single word
| expressing various grammatical features by (usually
| systematic) modifications of the word, such as the English
| 'work'->'worked', but on a much larger scale for most
| languages worldwide. See
| https://en.wikipedia.org/wiki/Inflection
| andrewflnr wrote:
| Isn't that why English is usually the near the top of
| language difficulty rankings? I mean, your point is true, but
| I don't know of anyone actually confused about it.
| duderific wrote:
| See: through, rough, cough, bough, dough, all of which are
| pronounced differently. My 5-year-old daughter is learning
| to read, and trying to explain all this is...challenging.
| taeric wrote:
| Are you truly starting with those words for a 5-year-old?
| Curious why?
|
| Hands down, teaching phonics is far and away the fastest
| route to being able to decode words. Similarly, reading
| to your kids is the fastest way to get them interested in
| reading. Using the motivation to learn to get going on
| the phonics is more than adequate to teach reading.
|
| And don't expect things outside of spelling/reading to be
| any more "logical." Try explaining the rules of any sport
| in a way that isn't dominated by the exceptions.
| taeric wrote:
| Is it objectively at the top, or is that more an easy thing
| people love to assume is truly difficult? I don't think we
| have any evidence that kids are slower to learn in any
| particular language, do we? (Oddly, we do have evidence
| that moving away from a primarily phonics based teaching
| method was a terrible idea, but I haven't seen much to
| compare with other languages at the same ages.)
| DonaldFisk wrote:
| How difficult you'll find a language depends on what
| languages you already know, and the teaching materials
| available for it in your own language. These pages
| distinguish between first languages:
|
| https://blog.rosettastone.com/what-is-the-hardest-
| language-t...
|
| https://www.reddit.com/r/languagelearning/comments/87jy70/r
| a...
| rohan_ wrote:
| I was reading about the design decisions made when building the
| shadcn library. It's actually pretty fascinating:
| https://manupa.dev/blog/anatomy-of-shadcn-ui
| gchamonlive wrote:
| There are approaches that try to get the best of both worlds.
| Interestingly, the micro-services architecture is just like
| that, but it gets a bad reputation for being easy to devolve
| into a distributed monolith anti-pattern. Another cool model is
| maybe the propagator model. The point is maybe to find a way
| that you don't have to opt either for generic or specific
| implementations, but have many models of the same domain
| through different lenses operating cooperatively.
| theamk wrote:
| Microservices are 100% in the "Optimize for flexibility and
| you'll end up with something that's way too complex"
| territory.
|
| (I am watching this right now at my workplace: team next to
| us has updated the microservice in repo A, and accidentally
| made incompatible change, so that integration tests in repo B
| which make calls to that microservice are now falling. Is it
| a solvable problem? Certainly. But back before we had
| microservices, this problem just could not occur, as
| client/server versions were always identical)
| danielvaughn wrote:
| Yeah, I've only seen microservices used in a couple of
| places, but in both cases I felt they were introduced far
| too early. The first time I saw them was for a 2 page note-
| taking web app, and it had something like 65 microservices.
| pcurve wrote:
| Adoption is a big issue with design systems. More complex it
| is, the less adoption you're going to see (or incorrect usage).
|
| It's amusing to see deeply nested and abstracted components
| with fancy properties in a design system. Makes you wonder who
| they're building the system for.
|
| If you look at mature publicly available design systems, they
| have all evolved over the years towards more simplicity and
| flatter structure. Google, Atlassian, etc.
| detourdog wrote:
| From a designer's perspective we are equally amused at watching
| engineers discovery the same system lessons designers have
| faced for years.
| moritzwarhier wrote:
| > Optimize for flexibility and you'll end up with something
| that's way too complex. Optimize for speed and you'll regret it
| down the road. Everything's a tradeoff, but the only guarantee
| is that at some point, you'll feel a distinct urge to throw it
| all away and start over.
|
| Very well-put, quoteworthy!
| esafak wrote:
| I think it's like designing an API. Create the wireframe
| components you need and use them for a while before codifying
| them into a design system (API).
|
| In other words, observe the function in order to allow form to
| follow it.
| no_wizard wrote:
| The biggest problem I see with design systems implementations
| is too much variation, which I think stems from the fact
| designers have not actually thought out what the User
| Experience is going to be and how the design system is suppose
| to facilitate that, _for the whole product line_
|
| Yes, the _whole product line_. If you want consistency in a
| product, it has to start with deciding what UX modalities you
| want to adopt, and sticking to that. Less is more, usually. Don
| 't add a new component until you have actually exhausted the
| ability to use the ones you started with, if you decide to
| pivot UX you need to pivot _wholesale_ etc.
|
| Getting people to _stay on the rails_ as it were, is seemingly
| impossible, but when you can, it works very well.
|
| I'm abridging a bit (its a iterative process, start with
| wireframes over full flesh designs and other things) however
| this does, in a nutshell, work and has a forcing function of
| actually focusing on the user and product rather than design in
| and of itself
| gedy wrote:
| I have some experience in the space as a developer, and it's
| challenging mainly because design systems and component libraries
| are an abstraction, and frankly, most people aren't great at
| generalizing. Designers especially are rarely ever taught how to
| think reusable patterns and components, but they are frequently
| the ones "put in charge of" this type of work.
|
| It's closely related to this quote:
|
| > A lack of ... alignment within teams and leadership around what
| a design system is, what problems it solves, and how it will
| provide value.
|
| I like working with UX and designers, but more often than not,
| "we need a new design system" basically means "we want a cool,
| new theme"
| qkeast wrote:
| Yep! This often happens when design systems are thought of in
| narrow terms of design tooling--component libraries and such in
| apps like Figma, without a connection to the implementation.
|
| Edit--Responding to an edit in the OP:
|
| >I like working with UX and designers, but more often than not,
| "we need a new design system" basically means "we want a cool,
| new theme"
|
| This isn't so much an issue with UX and designers as a
| discipline, but rather points at larger issues in the
| organization around process, culture, expectations, and
| strategy, the perceived role of design in that organizational
| context, and the specific folks you've worked with.
| ethanbond wrote:
| Tailwind gives you almost all of the upside of a design system
| with almost none of the downside. I will not be taking questions.
| qkeast wrote:
| I think Tailwind is phenomenal for implementing a design system
| on the engineering side, but it can't inherently solve many of
| the other reasons a design system exists: capturing and
| defining the patterns a specific product uses, creating
| consistency across the product, accelerating the design team
| and engineering team...
| ethanbond wrote:
| But most design systems fail to actually solve those problems
| too, and consume a fuckton of time and energy in doing so
| psygn89 wrote:
| I think you're mixing design system with css frameworks.
| danielvaughn wrote:
| There's Tailwind as a technology, but then there's Tailwind
| as a set of reasonable defaults. The original comment is
| referring to the latter, not the former.
| ethanbond wrote:
| That's correct^
| eviks wrote:
| reasonable defaults within a very limited scope vs a proper
| design system
| k__ wrote:
| Tailwind allows you to build a design system, but it certainly
| doesn't come with one out of the box.
|
| Bootstrap on the other hand does.
| robertlagrant wrote:
| Tailwind allows you to create a component library whose spec is
| a design system.
| charlie0 wrote:
| This stems from a metaproblem, the average is mediocre. I've
| noticed better tools that have supposedly allowed us to simplify
| things have just made us to build more complex things. This all
| stems from a lack of talent. The problem is if everyone got 50%
| more talented over night, new things would get made, and a new
| average established and we'd still complain. This is because an
| average is relative and not absolute. Things that are "easy", on
| average never will be so. The trick here is to level up and try
| to join a better company.
| eternityforest wrote:
| I think part of it is really smart coders have different
| expectations.
|
| If you love simplicity and tend to think about how stuff works,
| you'll be bothered be the fact Etcher is 80MB.
|
| If you're a user... you'll just say "Wow, only a 1 minute
| download and I'll never have to worry about wiping my disk with
| dd again!"
| eddd-ddde wrote:
| This is really true. Simply different people value different
| things. Try to get multiple people to work together and
| disagreements are inevitable.
| aditgupta wrote:
| Governance is always a bigger challenge than creation.
| danielvaughn wrote:
| It's the difference between raising your hands in the air, vs
| keeping them in the air indefinitely.
| datadrivenangel wrote:
| "A tendancy to over-optimize for future flexibility, rather than
| immediate need and impact, which eventually sabotages momentum."
|
| A choice between shooting yourself in the foot later or later.
| qkeast wrote:
| Yep. It's an inevitable choice, but I find that in the context
| of design systems, we don't usually end up making that choice
| intentionally, and instead default to over-optimizing up front
| without consideration of other approaches.
| karaterobot wrote:
| > The mere existence of a design system warping the design
| process and the value of design as a discipline.
|
| Despite having a lot of experience making them and using them,
| and despite them being a keyword a lot of companies ask for in
| job postings, I took any mention of "design systems" out of my
| resume because I would prefer to work for a company that didn't
| index on designers who rely on design systems. I've just seen
| them used as bludgeons too often, i.e. "why would we implement
| this design when it doesn't match our design system?" well,
| because it's the right way to do it in this new case we've never
| seen before. I think design systems and component libraries
| become a way to reuse existing work instead of rethink and
| rework, which is convenient but often antithetical to doing the
| right thing in a changing environment. I understand that product
| teams have to move quickly. I'm here to do work I'm proud of,
| which sometimes brings me into tension with the organization's
| desire to save time and labor, which is to say money. Design
| systems--not the theoretical idea of them, but the way they are
| applied in the real world--are becoming a symbol of that for me.
| robertlagrant wrote:
| It's a double-edged sword. Design systems constrain designers,
| so each greenfield project isn't a delightful creative
| experience for designers and a hard slog for the engineers
| making another similar-but-different interface. However, this
| constraint can be over-applied.
| starkparker wrote:
| And even you have multiple projects or products at one
| company, and they don't talk to each other, and they work on
| different aspects of the same problem, and each of them has
| their own designer, they all invent similar tools with
| different, inconsistent designs that are a nightmare to use.
| Spivak wrote:
| The things you list as criticism are exactly the reason places
| implement design systems. You're clearly an east coast school
| of thought person who takes pride in building the "right
| thing." But people who implement design systems are taking the
| worse is better approach on purpose. They see it as better to
| be clunky and contort functionality into the existing
| components and ship than spend time doing something custom.
| n8cpdx wrote:
| And unless the design system is really bad it shouldn't be
| that clunky. Design is design, not art, each new app in a
| product suite should not be a unique snowflake, but a piece
| of the puzzle.
|
| People are acting like there are actually new never-before-
| seen scenarios in CRUD web apps. I've only ever seen
| situations where the designer _thought_ they needed to break
| the mold, never where it was actually necessary.
| enhdless wrote:
| genuine question because I've never heard this phrase, and
| search engines did not yield useful results: what do you mean
| by "east coast school of thought"? and then is there a
| corresponding "west coast school of thought"?
| esafak wrote:
| The two schools of thought here:
| https://en.wikipedia.org/wiki/Worse_is_better
| enhdless wrote:
| Thank you, TIL!
|
| I will admit I was briefly even more confused reading
| that the "west coast" model includes New Jersey (an east
| coast state) and the "east coast" model includes Stanford
| (a west coast university)... but whatever lol.
| Waterluvian wrote:
| A very realistic step of my design system is to go back and
| update the design to match the assorted minor differences
| discovered as ideal during implementation.
| spoonjim wrote:
| It all depends on how much the customers depend on uniformity
| between use cases. One thing that a strong design system does
| is force uniformity between products which can be a boon to
| confused customers.
| msum wrote:
| This article aligns with a lot of my person experience. I'd add a
| few of my own observations on design systems:
|
| 1. The team making the design system needs to be really
| passionate about making a design system specifically
|
| 2. Everyone on the design system (DS) team needs to be pretty far
| in their careers, and have a few failed or quasi-successful
| attempts in their past experience.
|
| 3. Everyone's skills should overlap but each individual should
| bring their own depth/area of expertise.
|
| 4. I've never seen a "contributing back" model work, really.
| There can be some collaboration, or specific asks, but when you
| have a really cohesive DS team, they took the time to become that
| cohesive and it shows.
|
| 5. No matter how good the docs are, there will always be people
| who don't read the docs. I'm tempted to go as far as to say that
| I think there should be an onboarding course on how to use the
| design system that teams have to take before they can use it. (I
| legit don't know how else to reasonably solve this issue).
|
| 6. Make it compliant with accessibility requirements (at least
| bare minimum WCAG Success Criteria). I've seen that alone drive
| adoption for design systems.
|
| I've been creating for web for 25+ years now, and I've only seen
| 1 or 2 successful design systems. It's so easy to get it
| completely wrong, or get off track.
| SamoyedFurFluff wrote:
| On a point 5, never underestimate the amount of labor someone
| is willing to undergo in order not to learn something.
| Educators everywhere share your struggle!
| Perz1val wrote:
| You should also take into consideration that reading docs
| takes time. If a different designer (marketing guy) is
| supposed to do a simple 30m task (draft that Merry Christmas
| popup real quick), they probably won't get those extra 5
| hours to read the docs
| suzzer99 wrote:
| And after those 5 hours you spend another 5 hours beating
| your head against the wall until you finally realize the
| docs are out of date.
|
| Stale docs are worse than no docs. IME (at non-FAANG, non-
| tech darling companies) docs *always* go stale pretty
| quickly. No one wants to take on the thankless, unbudgeted
| task of keeping the docs up-to-date, or browbeating all the
| other devs to update the docs when they make changes.
|
| The only docs I push for are stuff like swagger where the
| documentation is also living code. Otherwise I say just put
| it in the readme, and every repo has a clear owner
| responsible for keeping that readme up-to-date as
| necessary.
| marcos100 wrote:
| I believe the future will be to feed all your docs into a LLM
| for people to query.
| locuscoeruleus wrote:
| I think this is an expectation thing. People expect to be
| able to figure it out in time x. They expect they'd have to
| use y time to find the solution in the docs. And people will
| most often estimate that x <<< y, having been burned by bad
| documentation before. People will often be disappointed that
| their search through the docs didn't get them any answers and
| most people will have strong memories of "figuring it out
| eventually" by throwing spaghetti at the wall long enough.
| josefrichter wrote:
| As someone who often held the job title of "design systems
| specialist" (usually mobile) many times, one thing that always
| helped was:
|
| This is what standard iOS vs. Android elements look like out of
| the box, this is how navigations works out of the box, this is
| how some ux patterns (like various pickers) work out of the box.
| Now this is easy to change, this is more difficult to change, and
| this is something you should never change.
|
| There you go, we have a good spine for a design system (and not
| just a component library), and we have a good starting point to
| fix the relationship between designers and developers, which is
| broken way too often, and hinders progress way too much.
|
| It does require serious time spent in XCode and Android Studio
| actually writing at least hobby projects, but that knowledge pays
| off tremendously in building trust between teams.
| giantg2 wrote:
| I've found that Android development is actually fairly easy due
| to the way the system handles the different display tags and
| how standardized they are. For web it seems like there are
| multiple layers of possible options - html, css, whatever
| framework, then the libraries and content management systems.
| I'm sure this exists to some extent in Android projects, but it
| doesn't seem to be as much spaghetti.
| ctenb wrote:
| "Design" here means user interface design for software, rather
| than design in general.
| valand wrote:
| As someone who delved with both system design and ui design,
| yes, this name overloading is frustrating
| aridiculous wrote:
| One of the few un-nuanced takes I have is that every component
| library/DS should be built on top of Radix or React-Aria or some
| other thorough but extensible library. If you're implementing
| your own tooltips and menus, you've lost the plot. We need to
| stop reimplementing bad versions of commoditized bits of UI that
| overlook accessibility, appropriately generic prop APIs, boundary
| detection, composability, documentation, testing, etc.
|
| It pains me to see dev teams spending time on rebuilding solved
| problems. I understand brownfield constraints, but the greenfield
| situations are particularly painful.
| crooked-v wrote:
| It's painful sometimes to think of the sheer number of man-
| hours wasted because browsers have never added a combobox or
| any way to style select dropdowns.
| joduplessis wrote:
| Let me be the first to object to the "rote" classification.
| Design systems are hard in a way that good design is hard. For
| the folks in the comments (and in the article) comparing UI libs
| to design systems, they are completely different.
|
| EDIT: Evidently, the person writing the article seems to have a
| very cursory understanding of design systems & component
| libraries. Maybe better left as a tweet than a full article IMO.
| qkeast wrote:
| I think you're missing some of the nuance in the article. Rote
| here means that on the industry level, they can feel like an
| established, everyday, ought-to-be-easy thing--not that they're
| actually easy.
|
| I'm curious, though: what gives you the impression that the
| person writing the article "seems to have a very cursory
| understanding of design systems & component libraries?"
| joduplessis wrote:
| For me I think the definitions were quite "high level" &
| broad? Stuff like:
|
| > A design system is really a high-level concept uniting
| various things together around shared objectives.
|
| That isn't really true or accurate - design systems aren't
| abstract things. They're a set of aesthetic
| relationships/rules that govern appearance.
|
| I think maybe a small gripe was the inclusion of component
| libraries - those are always lumped into the same bucket as
| design systems by folk who don't really understand design
| systems. Saying that though, happy to admit I may be wrong.
| dkarl wrote:
| > A lack of actual (not assumed) alignment within teams and
| leadership around what a design system is, what problems it
| solves, and how it will provide value.
|
| Definitely. In a retro recently I heard, "We need a design
| system!" followed shortly by, "We already have a design system!"
| and "What's a design system?" Speaking as a developer, this
| discussion is slightly out of my lane, but I appreciate the
| article's discussion of when to start investing in a design
| system and what you might get in return.
| brotchie wrote:
| Design systems following the philosophy "Strong Opinions, Weakly
| Held" are the sweet spot.
|
| Having a consistent reference for stuff like "what's the standard
| color gradient for a Generative AI placeholder" is hugely
| valuable, BUT UXD / Engineering must have leeway to interpret the
| spirit of the system and not be forced into pixel-perfect
| adherence.
|
| Experienced this 1st hand with earlier version of Material
| Design. SO MUCH WHITE SPACE! This is fine for some use-cases, but
| when you're building an internal tool for technical users who
| need an information-dense experience, following padding / margin
| guidelines is sub optimal.
| cjcenizal wrote:
| My very modest claim to "fame" is having founded the Elastic UI
| Framework [1]. My experience with these kinds of design systems
| taught me two lessons:
|
| 1. You'll iterate towards the most useful version of your design
| system in the least amount of time if maintainers spend time
| consuming it, and vice versa.
|
| 2. Code is the source of truth, in the form of the component
| library. It's an unhelpful fiction to treat the non-code design
| system (whether that's in Figma, Sketch, or wherever) as the
| source of truth. This is because people build out new parts of
| the UI by copying, pasting, and modifying the code of the
| existing UI. If you want to make a change to the design system,
| it has to go into the code to make a difference.
|
| [1] https://elastic.github.io/eui
| blazerunner wrote:
| > Code is the source of truth, in the form of the component
| library
|
| Amen. No point living in a Figma dreamland if what you're
| shipping doesn't resemble it.
| drewcoo wrote:
| > When I say rote, I'm thinking about how parts of the underlying
| toolkit have become really easy, how pretty much any designer can
| work on one, and how the general idea of a design system has
| become understood such that it's a reasonable expectation that a
| team will have one.
|
| As opposed to, you know, the meaning of the word "rote."
| ska wrote:
| Sure it's a solecism, but they communicated what they actually
| meant.
| duped wrote:
| I'm just a lowly systems guy, but the definition of "what is a
| design system" is really confusing.
|
| Is it a UI library? Like if you get a team of people together to
| build one, what is the actual deliverable?
| cheschire wrote:
| The article describes it pretty well. If it's still not
| resonating, I know it might come off disingenuous but really I
| would suggest pasting the description from the article into
| chatgpt and asking it to describe it to a "lowly systems guy"
| as you refer to yourself.
| duped wrote:
| If you can't explain it concisely and clearly, then do you
| understand it?
| cheschire wrote:
| How much more concise do you need than this?
|
| "Design system: A complete set of standards and principles
| to manage design at scale. It can include, but isn't
| limited to, the visual design language, typography, colour
| palettes, components, copywriting guidelines, and other
| elements that create a cohesive, scalable look and feel for
| the product."
| eviks wrote:
| The deliverable would be documents with "standards and
| principles". It's not a UI library as it also includes rules
| for the content itself
| vpribish wrote:
| same. i'm fairly conversant in lots of 'design' things and this
| is remarkably opaque. The discussion is so generic, so removed
| from specifics, that it looks like it's architecture
| astronautics.
|
| "A design system is really a high-level concept uniting various
| things together around shared objectives"
|
| so it's a concept - uniting things - around objectives.
|
| so it's everything and therefore nothing.
|
| back in the real world this is just graphic design and user-
| interface guidelines and standards on how to present
| information - even to the extent of actual software components
| you can use to implement software. sure, cool, yay.
| esafak wrote:
| The design _language_ is the look, and the design _system_ is
| its reusable implementation.
|
| https://en.wikipedia.org/wiki/Design_language
|
| https://en.wikipedia.org/wiki/Design_system
| ShadowBanThis01 wrote:
| I find it depressing how design systems, which come and go pretty
| quickly it seems, suffer from profoundly shitty design. Figma is
| certainly no exception.
|
| Also disappointing is the state of design-system support for
| programming. I know not everyone wants or believes in code
| generation, but I find it incredible that this also still sucks.
| I'm building the front and back end for a new application now,
| and the amount of manual syncing between them hasn't changed in a
| decade.
|
| A while ago I had to design a new API for a company's products.
| After some research, I defined it with OpenAPI. I then wasted
| weeks or months trying to find
|
| A. Tools that actually supported the current version (3.1), which
| is the only one that's acceptable because of glaring gaffes in
| previous specs.
|
| B. Code-generation tools that supported the languages we needed
|
| C. Code-generation tools that worked at all.
|
| It is an absolute shitshow. None of those things is available or
| works. The moral is that common problems faced by lots (if not
| most) of us programmers or system designers are still not solved.
| Don't assume that you're the problem. I made that assumption, but
| in the end no... the tools and ecosystem were simply shambolic
| and I would just have to write my own or just strap it on and do
| the tedious manual work.
| SnoozingBoa wrote:
| Based on some experience (designer and developer), here's some
| thoughts I currently have about them:
|
| - high-level idea is usually understood, although mixed with
| design tooling - practical usage rarely straightforward - most of
| the activities are surface level and trivial - required effort to
| maintain and develop often underestimated - maturity level rarely
| reaches the potential - "component" is not an easy concept,
| especially in multi-product setting - too often design driven,
| when implementation driven would make more sense - generates
| meetings on many meta-dimensions - not necessarily rewarding
| exercise for the maintainer due to various organisational and
| political challenges - does not actually help on design-to-
| development e2e flow as much as advertised - even with all the
| work put in, does not guarantee good product
| alxmng wrote:
| The challenge in my experience is getting buy-in to use the
| system for everything, consistently. None of the benefits of a
| design system and UI library matter unless it's used, and used
| consistently.
| mattchamb wrote:
| I've seen it go wrong where there is a design system, but none
| of the designs that come in actually match it, so we need to
| extend the standard components or create whole new ones; but
| timelines are set as if it's all off the shelf stuff.
| nitwit005 wrote:
| > Not using or recognizing the design system as an internal
| source of truth.
|
| My experience has been that engineers and designers try, but
| can't do so. New projects tend not to be fully covered by the
| design system. This is almost tautological. New things are new.
|
| Yes, maybe they thought about what they want calendars to look
| like, but only for the case of picking a date, not displaying a
| weekly schedule.
|
| At one company this meant they kept gluing new things onto the
| design system, and at another company it meant we met with them
| every release and got told not to worry about it.
| ipnon wrote:
| Design systems seem to be due to oversupply of designers and
| frontend engineers in the tech industry. You get enough of them
| together in a company and there's not enough for them to work on.
| So a design system is hatched so that they can work on things
| that never get used!
|
| I jest somewhat but I do feel a design system is an "org smell"
| for all but the largest engineering organizations. My estimate is
| that you don't need that unless you have 4 digit engineer count.
| Smaller companies with design systems usually are putting the
| cart before the pony, so to speak.
| ipnon wrote:
| To put it another way, a company with inconsistent design is
| likely in a better position in terms of income and culture than
| a company with a design system!
___________________________________________________________________
(page generated 2023-12-13 23:00 UTC)