[HN Gopher] Design Token-Based UI Architecture
___________________________________________________________________
Design Token-Based UI Architecture
Author : mpweiher
Score : 165 points
Date : 2024-12-17 22:04 UTC (1 days ago)
(HTM) web link (martinfowler.com)
(TXT) w3m dump (martinfowler.com)
| svachalek wrote:
| It seems like there are some good ideas in here but the
| terminology is utterly alien to me. Not sure if it's me or this
| is just deeply wrapped in consulting jargon.
| panic wrote:
| The core idea seems to be putting visual parameters in a single
| place that can be shared across platforms. That way you can
| tweak the design everywhere without having to edit N different
| platform-specific implementations.
| nikolayasdf123 wrote:
| same. I don't understand what he is talking about. is he
| working in front-end? sounds like tons of "consulting" talk.
| iLoveOncall wrote:
| It's because you can sell "Token-Based UI Architecture" for
| $1,000 an hour, but you can't sell "CSS variables", so they try
| to make it sound as complex as possible.
| MrMcCall wrote:
| What they are calling "tokens" are just their design elements.
|
| They have abstracted the design elements into their 'tokens' so
| that they are defined parameters/variables/model-elements that
| can then be reified at some point before deployment.
|
| This is a fancy way of encompassing a system's design decisions
| into a model, which can then be used either abstractly or
| concretely to proliferate them into the entire system, as
| needed, at the latest possible point the actual values are
| needed.
|
| It really looks like top-shelf work, but I think their deciding
| to use the word "token" was an unnecessary mistake.
| skybrian wrote:
| The term "design token" seems to have been invented at
| Salesforce as part of their design system a decade ago.
| Apparently the "token" part is the value of a configuration
| property and at minimum you need a key-value pair defining the
| property. There is an ecosystem where configuration files are
| used to exchange data between design tools for standardizing
| things like colors.
|
| It's kind of wild that this whole ecosystem evolved without
| previously coming up much on Hacker News, but that's just how
| it goes. Inventing jargon isn't bad. There is certainly a lot
| of programming jargon that we inflict on others.
| nsonha wrote:
| what is so "architecture" about constants?
| CaveTech wrote:
| The millions of websites designed without using them. This
| insight was lost at some point, even if it seems obvious in
| retrospect.
| HexDecOctBin wrote:
| Consultancy money. Why should Robert Cecil Martin have all the
| fun? Other Martins want in.
|
| There should be some research into how many code bases have
| been ruined by these panacea peddlers.
| motorest wrote:
| > what is so "architecture" about constants?
|
| I'm all for simplifying the indecipherable, but this is a case
| where things need to be made as simple as possible, but not
| simpler. Design systems determine how everything looks and
| feels, and this means specifying a number of things together,
| such as what colors a button has, how it looks when pressed and
| hovered, how dialogs look, what is dark mode or light mode,
| etc. Calling this "constants" is simplistic and a sign you are
| commenting on problems you know nothing about.
| skybrian wrote:
| Compare with Cue, Jsonnet, etc. Systems for sharing
| configuration settings can get pretty elaborate when it's done
| at scale.
| nikolayasdf123 wrote:
| someone should write an article explaining this in folk language
| astr0n0m3r wrote:
| In one sentence: Design tokens are a standardized way of
| defining constants used in a design system.
|
| If most developers haven't heard of them, it's because most
| developers don't create design systems. Even when you use a
| design system, the actual use of design tokens would likely be
| hidden.
|
| Material Design uses them.
| https://m3.material.io/foundations/design-tokens/overview
|
| Fluent UI uses them. https://fluent2.microsoft.design/design-
| tokens
| HexDecOctBin wrote:
| So, basically #define?
| nikolayasdf123 wrote:
| yeah, still don't get what is all the fuzz is about.
| defining symbols systematically (e.g. with some hierarchy)
| and having constants mapping symbols to values - all is a
| no-brainer
| aaronbrethorst wrote:
| The fuzz is about writing 2,000 words on a simple concept
| in impenetrable jargon in order to better demonstrate the
| thought leadership of your practice and the need for deep
| consultation to translate the aforementioned impenetrable
| jargon into simple language so mere plebes can implement
| the advice.
| tinix wrote:
| This kind of comment isn't welcome here...
| nsonha wrote:
| Said who, a consultant?
| aaronbrethorst wrote:
| Why do you say that?
| motorest wrote:
| > This kind of comment isn't welcome here...
|
| Not true. This kind of comment is exactly why most of us
| flock to this site. It's important to point out when the
| emperor wears no clothes. There's already an army of
| self-promotipn types forcing this nonsense onto everyone.
| arkh wrote:
| Well you could distill most "modern" methods to one
| subtitle of The Mythical Man-Month book: Plan the system
| for change.
|
| TDD, DDD, extreme programming etc come from the same
| observation: the client does not know their needs. Even
| if they do, those could change. So you want to build
| systems which are easy to change. And we still get
| thousands of pages published in the form of books or blog
| post for something written and explained in a book almost
| 50 years ago.
| Jarwain wrote:
| I mean it's kinda jargony and yeah kinda like #define, but
| I think the idea is specifying a namespace and specific
| types with a focus on UI/UX design.
|
| In C you'd maybe do it by prefixing all the relevant macros
| with DESIGN_foo but I think part of the goal of this is
| outlining all the potential "Foo"s and utilizing it to
| maintain consistency across a large organization
| kookamamie wrote:
| It's just the usual over-engineered BS that can be expected
| from the domain in question - my 2 cents.
| kaelig wrote:
| Hi, I'm the founder of the Design Tokens W3C Community Group, we
| are writing a spec to help with interop across design and
| developer tooling [1]
|
| There's a whole movement bringing DevOps and SRE thinking to
| design/UX, essentially working on design infrastructure. Design
| Tokens are a part of it.
|
| Ask me anything -- this may be confusing to some folks ("isn't it
| just... variables?") and I'm happy to say more.
|
| 1: https://tr.designtokens.org/format/
| spankalee wrote:
| Why does the format use $-prefixed keys? That's pretty weird as
| far as JSON schemas go.
| Jarwain wrote:
| Not just weird, it kinda overlaps with json schema builtins
| like $schema, $ref, $id, etc
| kaelig wrote:
| The reserved prefix $ answers the question: "how can we let
| people name, structure, and nest their tokens however they
| want, while future proofing the spec?". More on that
| rationale: https://tr.designtokens.org/format/#character-
| restrictions
|
| As for the "pretty weird" aspect -- it's definitely uncommon
| but it's been seen before: the $ prefix is also used by the
| JSON Reference ($ref): https://www.ietf.org/archive/id/draft-
| pbryan-zyp-json-ref-01... -- and just in case, we ran this
| syntax past Ben Hutton (inventor of JSON Schema) to ensure we
| weren't doing anything silly.
| spankalee wrote:
| You can usually do this by only being additive with the
| spec, and by never mixing user-defined keys and spec-
| defined keys in the same object.
|
| I've only ever seen $ used before with meta properties that
| work across all schemas like the $ref you mentioned and
| $schema.
| kaelig wrote:
| There are multiple ways to solve this, we've explored a
| few and we found that clearly differentiating user inputs
| from the spec keys was the right way to go for this use-
| case and our audience.
|
| That said, there definitely are other valid ways to solve
| it.
| AdieuToLogic wrote:
| > Ask me anything -- this may be confusing to some folks
| ("isn't it just... variables?") and I'm happy to say more.
|
| How do Design Tokens along with the article's identification of
| "Translation Tools" differ from existing template-based code
| generation techniques?
|
| In other words, what problems do Design Tokens solve which
| cannot be satisfied with sh[0] and sed[1]?
|
| 0 -
| https://man.freebsd.org/cgi/man.cgi?query=sh&apropos=0&sekti...
|
| 1 -
| https://man.freebsd.org/cgi/man.cgi?query=sed&apropos=0&sekt...
| kaelig wrote:
| It's first and foremost a methodology that plays into your
| design infrastructure. Whatever tooling floats your boat is
| absolutely fine, but the difficulty comes when you have to
| scale your design decisions across SVG, Sass, Tailwind, React
| Native iOS, Android, Figma, various prototyping tools, and
| for several company brands, dark mode, high contrast mode,
| etc.
|
| At a certain scale, design and brand teams need
| infrastructure to drive change. These teams rarely have
| sufficient engineering headcount (if any) to build such
| tooling and delivery pipelines all the way to the user.
| Having interoperable formats brings alignment across design
| and engineering toolchains. The industry needs this
| methodology to be baked in, rather than requiring folks to
| build their own tooling.
| starbugs wrote:
| > At a certain scale, design and brand teams need
| infrastructure to drive change
|
| What does this mean?
|
| Do you have a concrete example of where this actually
| solves a real problem? And what problem would that be?
| kaelig wrote:
| Let's take a very atomic example, that becomes a problem
| at scale: say you want to change the primary button color
| across all your apps (for accessibility reasons, for
| example). If you have 50 codebases where this color is
| applied in many different ways (naming, color format...),
| it's a real struggle. You're going to waste time, miss
| spots, and the user experience will be inconsistent.
|
| Now imagine rolling out dark mode across an entire suite
| of products, or perhaps a brand refresh.
|
| Having a single source of truth and tooling that supports
| it end to end from design to engineering helps roll out
| changes fast and on brand. In turn, it's good for the
| user!
|
| I know a lot of folks here may come from a more backend
| background so it may help to think of it as: a way to
| unlock continuous delivery for your design decisions.
| starbugs wrote:
| What you describe sounds like a config dictionary. What
| benefit does it offer to standardize that for this very
| special (and probably rare) use case?
|
| I don't know many companies that could actually have the
| problem of scaling a design change up to 50 apps, because
| most don't have 50 apps. But I would guess that those who
| actually have to solve this problem are staffed properly
| to implement a shared configuration for design
| parameters.
|
| If you want such a hard dependency and kind of automation
| in this case is another question. I could imagine a lot
| of special cases where this would cause another set of
| issues with, e.g., accountability (which part of the
| codebase belongs to which maintainer and so on).
| baq wrote:
| > But I would guess that those who actually have to solve
| this problem are staffed properly to implement a shared
| configuration for design parameters
|
| This is never a priority, so it never gets done. When it
| suddenly becomes a priority, you get all the problems
| described above.
|
| A large company doesn't mean there's a team to handle
| everything. It just means there's a lot more people to
| talk to before you can start work on anything.
| whilenot-dev wrote:
| It sounds like a config dictionary _with a continuous
| pipeline and good integration into design tools_ to me.
| UI design decisions are rarely artifacts in any
| deployment pipeline, so more power to the design team
| then, which is a good thing imho.
|
| I know many companies (enterprises) that actually have
| this problem of scaling a design change up to 50 apps.
| These apps are either new products, rewritten parts,
| outdated "legacy", or stuff that has been outsourced
| previously. Now these companies are in demand for
| "rebranding for the digital age". It all depends on how
| well design tokens integrate into those situations and
| its used design tools.
|
| A problem I see is also that such enterprises rarely make
| use of a better ratio than having 2 designers for the
| whole company, which then, in turn, suffer from opinion
| overload by various stakeholders. The UI design process
| produces visual artifacts and good designs always feel
| simple. I seen it various times that stakeholders
| therefor wrongly conclude that the design process must be
| simple, and that's the never ending circle of a designers
| life. That brings me to another concern...
|
| Since design tokens open up the automation possibilities
| with specific design pipelines that might find their way
| into a deployment to production, and it isn't uncommon
| stakeholder-thinking that "designs are easy" - all that
| while LLMs are on the rise, mind you - I can also imagine
| some kind of horror scenarios finally playing out,
| especially when changes aren't well tested (responsive
| design, accessibility etc.).
| andybak wrote:
| > It sounds like a config dictionary with a continuous
| pipeline and good integration into design tools to me.
|
| I wish you were responsible for writing the article. This
| is a much better explanation.
| kaelig wrote:
| The role of the spec is to have alignment throughout
| proprietary and open source toolchains, from design tools
| to CI build scripts to UI frameworks, so everyone working
| on an experience can speak the same language, have high
| fidelity end to end, and reusable automations.
|
| The idea that this can be solved through accountability
| doesn't scale in my experience. So much of this work is
| maniacal and low-value, there's very little incentive for
| teams to prioritize it... But in aggregate, UI
| inconsistencies bring death by a thousand papercuts.
|
| Companies with design infrastructure teams and mature
| design cultures have automations in place. The goal is to
| bring such power even to those without design infra teams
| and early on their design maturity journey.
| starbugs wrote:
| > early on their design maturity journey
|
| I would argue that it's not in anyone's interest to add
| such kind of complexity when it's not needed.
| kaelig wrote:
| Correct, I'm fact I've advised a few teams to only
| introduce layers of abstraction they needed and could
| actively document & support.
|
| It's very tempting to copy fortune 500 companies because
| they're the ones with design & engineering who'll have
| written the most about this... but most folks just need a
| pretty simple token setup.
| itronitron wrote:
| How about instead we just start making companies smaller
| but have more of them?
| whilenot-dev wrote:
| The UNIX philosophy doesn't play well with the ego of
| ones business, unfortunately.
| s2l wrote:
| > or perhaps a brand refresh.
|
| Doesn't brand refresh often includes new components and
| new design language? In creative space, every design
| agency tries to sell something different to the
| organization and thus brand refresh will discontinue any
| prior design tokens and come up with new one.
| kaelig wrote:
| "it depends"
|
| When working on products that can last decades, you can't
| just throw away all styling and start from scratch. In
| this case, design tokens are essentially styling hooks
| that allow teams to propagate design changes at scale
| without rebuilding everything.
| anentropic wrote:
| "isn't it just... variables?"
|
| I guess this was my thought - a language/framework-agnostic
| format for a bunch of variables, but also with some opinion
| towards how they should be structured
| (option/decision/component layers) ?
|
| And then standardising it provides opportunities for interop
| between tools and multiple frameworks etc
| kaelig wrote:
| Yes to everything you say, except for
| "option/decision/component" as that's up to the users.
|
| The spec is acting just like how CSS doesn't tell you how to
| name and nest classes.
| rendaw wrote:
| Why call it tokens instead of variables?
| kaelig wrote:
| A few names, including "design variables", were
| considered in 2014 when Jina Anne and Jon Levine
| (Salesforce) coined the term.
|
| I wasn't in the room when they made the decision, but
| perhaps they'll pop into this thread and tell us!
| meiraleal wrote:
| because they are constants, not really variables?
| seanhunter wrote:
| Why not call them constants then?
|
| Tokens is a really terrible name given the strong
| expectation that anyone with a computer science
| background has around the meaning of "token".
| rendaw wrote:
| Yeah... auth tokens, resource tokens, rate limiting
| tokens, monetary tokens, LLM tokens, parser tokens,
| etc... you might as well name it "thing". It's about as
| bad as "node".
| kaelig wrote:
| They can be constants, but not always: a design token can
| mutate based on device, light/dark/high-contrast mode,
| viewport size, user preference, locale, brand, product,
| theme, etc. This mutation can happen at runtime or at
| build time depending on the use-case.
|
| Examples: - "primary button background color" may be
| different across light and dark mode - "header height"
| can vary across small and large viewports - "user avatar
| background" may be defined by the user themselves -
| "brand primary" may change for re-usable UI components
| based on the brand they're used for
| hombre_fatal wrote:
| New jargon lets you avoid overloading existing terms and
| it adds specificity.
|
| When someone says design token, you know they're talking
| about this. They don't have to say "variables" or
| "constants" + extra explanation that narrows the
| reference to the TFA concept every time they want to
| refer to the concept.
|
| We do this so often in programming that you take it for
| granted. You're using dozens of words that weren't used
| 10 years ago.
|
| Hydration is a good example of one of those words in the
| webdev space.
| anentropic wrote:
| ok, so the concept of layers is built in but not which
| layers
| et1337 wrote:
| Is the goal to be able to change a design token and see that
| change reflected across all your various UIs? How do you ensure
| people remember to use the design token instead of hardcoding
| the value? Won't you still have to check every nook and cranny
| of the UI to make sure the change doesn't break anything?
|
| And if that's not the goal, what is the goal?
| kaelig wrote:
| > Is the goal to be able to change a design token and see
| that change reflected across all your various UIs?
|
| That's exactly it! (with various degrees of immediacy:
| depending on the tooling it can be in real time, or deferred
| via a PR for example)
|
| > How do you ensure people remember to use the design token
| instead of hardcoding the value?
|
| A combination of great docs, education (onboarding,
| training), autocomplete, and linting. In design tools, it's
| baked in to the UI so adoption is less of a problem.
|
| > Won't you still have to check every nook and cranny of the
| UI to make sure the change doesn't break anything?
|
| Yes, and that's where visual regression testing comes in and
| proves valuable to not just developers, but also designers.
| mcrider wrote:
| For us the killer feature is being able to build the UI once
| with design tokens and then transform it radically into
| different themes. In our case the themes serve different
| brands (of the media company I work for) but more commonly
| this is a great way to build out light and dark modes.
|
| Our tokens are integrated into the designer's tooling and we
| have a build pipeline that allows them to update the frontend
| with minimal developer supervision, which has been a huge
| time saver and QoL improvement for both developers and
| designers.
| bung wrote:
| > Our tokens are integrated into the designer's tooling and
| we have a build pipeline that allows them to update the
| frontend with minimal developer supervision, which has been
| a huge time saver and QoL improvement for both developers
| and designers.
|
| Like did you integrate into figma, or write a gui for them,
| or something else?
| mcrider wrote:
| We use a Figma plugin called Tokens Studio, which stores
| its source of truth a (a big JSON file) in our github
| repo. Designers manage all of the token values there and
| push updates to a branch and create their own pull
| requests which developers then do a minimal review on.
| Long story short, the tokens are converted to CSS
| variables, which we consume in our styles (we use Vanilla
| Extract which makes this very nice). The tokens in Token
| Studio can also be used in the Figma designs, but its a
| little clunky.
|
| Figma recently launched their own native solution (called
| Figma Variables) which is more slick and better
| integrates into the design tooling, but it is mostly
| locked behind an enterprise-level plan (which lots of
| folks aren't happy about)
| seanwilson wrote:
| Can you explain the challenges in standardizing this? I don't
| mean to say it's simple, but curious which parts were easy to
| standardize and which part are most contentious.
|
| I appreciate the standardization efforts here so thanks! So
| I've been working on an accessible color palette creation tool
| (https://inclusivecolors.com/) and wanted to add export formats
| that were easy to import into other tools.
|
| For Figma, amazingly there doesn't seem to be any
| official/standard way to import variables yet, and instead lots
| of semi working/broken/abandoned import plugins that support
| different formats. I ended up adding DTCG, Style Dictionary,
| and CSS export so the user had some options to try different
| Figma plugins.
|
| It would have been great if there was a single well supported
| format that was reliable to use here, instead of having to code
| several export formats that are all roughly the same. Do you
| know if Figma will adopt DTCG?
| mrr500 wrote:
| The thread reminded me of exactly designtokens.org. We've made
| this part of our design vertical. The question is how do we get
| engineering utilizing frameworks like MUI to implement this?
| jastuk wrote:
| I was super happy learning about design tokens a couple of
| years back, and eager to use them, but since then my enthusiasm
| fell as it seemed to "never get there". Figma implemented
| something which is okay-ish, but completely useless for our
| needs, while Penpot announced their collab efforts and then
| radio silence for roughly 2 years now.
|
| I could be out of the loop a bit, but I see that this spec is
| also still a draft. As somone who'd love to evangelize and
| implement design tokens internally, when do you see this
| stepping into the spotlight in a meaningful way? Is there a
| roadmap of some kind that's available to the public?
| kaelig wrote:
| It's certainly been a longer journey than I'd anticipated to
| get to a "V1", but the current snapshot of the spec does have
| good penetration, allowing us to see what works and what
| doesn't in the wild.
|
| The main areas that need work for us to publish a "V1" are: -
| colors (it's almost there, we almost entirely reworked this
| part of the spec in depth over the past 2 years) - "modes"
| and "themes": the Tokens Studio team proposed the "resolvers"
| module, based on their user research and empiric evidence
| that it solves theming needs. We're editing it right now.
| Once it's in the spec, Figma will be in a position to support
| the spec natively.
| noworriesnate wrote:
| Isn't the concept so generic that it's kind of hard to
| standardize? I.e. some of the values are structured (e.g.
| margins can have four values), some are colors and some are
| pixels or rem or whatever... why no just use an existing schema
| language like JSON Schema?
| kaelig wrote:
| Colors can be expressed in many ways. For example in Android
| it's common to see hex codes as #AARRGGBB, but in CSS the
| alpha is at the end (#RRGGBBAA). With wider gamuts (lch,
| dcip3...), there are separate channels and alpha is expressed
| separately. We also need to provide ways for folks to codify
| dark mode / light mode / high contrast values.
|
| Another example is what we call "aliases" or "references": a
| token can reference another one. Their resolution process
| needs to be specified (as in: when exactly does an alias get
| resolved in the lifecycle, and how tools must process them,
| whether it's okay to rasterize them in the CSS/XML/JS/..
| output, etc).
|
| Note that we intend to provide a JSON schema, and the
| community has already published a few TypeScript type
| definitions, linting tools, and build tools based on the
| spec.
|
| > some are pixels or rem or whatever
|
| The 'or whatever' part is what we're trying to tame. For
| example an Android app may need to consume 'dp' values, web
| 'rem', iOS 'pt'... There are tons more examples where
| platforms differ in how they would express dimensions,
| typography, color... The spec provides a way to encode the
| source tokens, and then translation tools handle the
| conversion to platform-specific values.
| motorest wrote:
| > Ask me anything (...)
|
| Can you explain what problem you are trying to solve, and how
| do you think is the best way to solve it?
|
| The main take from this discussion is that this talk about
| "design tokens" is that this is a non-problem fabricated by
| self-promotion types that is trying to find something for which
| it can be conceived as a solution. So far it seems it's very
| hard to even put into words.
| kaelig wrote:
| A few members and myself have commented to explain in various
| ways what we're solving.
|
| This methodology is being used by most frontend and design
| teams at medium/large companies. There's a real need for a
| way to communicate design decisions between humans, teams,
| and tools at scale. it requires a lot of custom plumbing at
| the moment and smaller teams don't always have that luxury.
|
| The spec is here to unify the tooling landscape around a
| single format, which in turn will accelerate innovation in
| this space, and democratize the methodology all the way to
| smaller teams.
| motorest wrote:
| I'm sorry, you wrote words but they don't say anything.
| They sound like machine-generated nonsense.
|
| Can you actually provide a concrete example of a concrete
| problem you want to solve with the token-based UI
| initiative? Write your answer following the STAR format,
| and leave the buzzword bingo out.
|
| If you cannot explain your problem then this is a very
| clear tell that it might not exist at all.
| kaelig wrote:
| > They sound like machine-generated nonsense.
|
| Fair! Perhaps I should have used an LLM to de-bullshitify
| my message...
|
| Let's walk through a common scenario:
|
| Design tool A has brand colors coded in hexadecimal,
| those have no name, they're just hex values.
|
| Design tool B has colors named in CamelCase, values in
| HSL.
|
| Codebases A, B, C have colors in RGB, named the same as
| in Design Tool B.
|
| Codebase D has colors in Hex8, with their own naming
| convention.
|
| 100s of developers copy/paste values from old and new
| designs over the span of several years.
|
| Codebases now have 50 shades of the "primary blue"
| scattered around. Now user experience feels disjointed at
| best, confusing and hostile at worst.
|
| Engineering design collaboration is tough as no two tools
| and teams speak the same "design language".
|
| Say a team wants to implement a new feature across
| multiple codebases where styling and naming are all
| different.
|
| Lacks of re-use and poor communication leads to entropy,
| which leads to poor quality and slower delivery.
|
| Design tokens are the interoperable layer that help
| define a common language across people and tools and
| improve what I described above. (for those familiar with
| DDD, there are a lot of similarities)
|
| The spec itself is baking this into the entire toolchain
| so it's available to teams by default, without requiring
| as much custom tooling.
|
| PS: the scenario above may seem extreme to some, but it's
| _extremely_ common at medium to large companies with no
| established design/engineering processes.
| bmelton wrote:
| Great answer. In your scenarios, let's say OrangeCorp has
| their 'brand-orange' color token. They've defined it as
| the hexadecimal `#FFA500`.
|
| Engineer Bob implements it as `hsl(39, 100%, 50%)` in a
| web project because the loading state requires shifting
| the color values, and he has a library that works with
| HSL but doesn't work hex.
|
| What do you store for the source of truth? Are we just
| storing the hex value, and deriving translations from
| that? Or are we storing 'brand-orange' with a map of
| "hex: FFA500" and "HSL: 39, 100, 50"? Does the
| specification have an opinion?
| kaelig wrote:
| The "fun" part with HSL is that RGB->HSL->RGB conversion
| doesn't always land back on the initial value (and that's
| why I discourage using HSL altogether).
|
| In orgs without design tokens, I forgot to mention
| there's also number of folks using the color picker from
| their OS to grab what they think will be the right color,
| sometimes even on lossy images like a PNG, JPG, GIF...
| and that's how you end up with the 50 shades of blue.
| pavlov wrote:
| CSS didn't support constants and derived values for a long time,
| so a generation of web designers grew up thinking this is
| something quite difficult to achieve.
|
| And now there's a layer of design consultants who sell
| complicated ways to think about organizing constants and
| computing derived values, and it's not in their interest to make
| it look any simpler.
| bradhe wrote:
| I agree and was going to comment something similar: Like
| entropy, design systems are getting ever more complicated. This
| virtue of having infinitely updatable design systems is a bit
| lost. For most people this is an exercise that's done extremely
| rarely, is difficult to advocate for because the ROI is
| perceived to be low, and there's tons of stakeholders you have
| to align due to the risk to the brand.
|
| Front end engineers love to opine over amazingly flexible
| design systems, though.
| kaelig wrote:
| This is fair, I've also seen design systems grow in
| complexity. Sometimes for good reasons, but also because
| "design systems professionals will... systematize".
|
| That said, it's not just about "updatability" of systems,
| it's in great part about scaling a design language across
| multiple surfaces, products, modes, locales, and sometimes
| even multiple brands.
|
| The orthogonal complexity of design decisions can be pretty
| high, and does requires powerful interoperable tooling to
| handle. Hence the need for this methodology and a spec.
| yowzadave wrote:
| Yes, and also design changes never seem to align precisely
| with the parameters you anticipated at the beginning. I.e.,
| you don't just need to update one color variable, you need to
| update that color AND add a secondary accent color AND change
| the positioning of the logo with respect to the company name,
| etc.
| seanwilson wrote:
| > CSS didn't support constants and derived values for a long
| time, so a generation of web designers grew up thinking this is
| something quite difficult to achieve.
|
| I think it's more that design tools didn't used to support
| constants like this. Now tools like Figma do, designers are
| taking advantage of them and figuring out how to best to share
| constants/tokens with developers.
|
| Most web design is probably done by designers and not
| developers too, so it's not likely to be CSS variables (which
| have been available in CSS tooling like Sass for ages) that is
| driving this. I agree it doesn't need to be over complicated
| though.
| seanwilson wrote:
| Here's my developer-targeted summary of layered design tokens for
| those that are skeptical of the value or think this is just
| obvious. The general idea is to maintain a set named constants
| that are built up in layers that web/UI designers use in their
| design apps (like Figma), AND the developer uses the same
| constants in their code when coding up the designs:
|
| 1. You first have a "base" layer of constants e.g. constants for
| a small number of font sizes like text-base=18px and text-
| large=24px, and shades of gray/blue/red/green ranging from grades
| 1 to 10 like green-1=#defbe6 and green-7=#0e6027. These should
| not be used directly in designs or styling code.
|
| 2. You have a "semantic" layer of constants that can only
| reference the base layer e.g. color-success-foreground=green-7
| and color-success-background=green-1, where you pick these colors
| knowing they will have readable contrast.
|
| 3. You then have a final "component" layer of constants for use
| in UI components that can only reference constants from the
| semantic layer. So my "alert" component that shows a success
| message inline on pages can use "color-success-foreground" for
| the text, and so can my "toast" component that shows pop-up
| messages.
|
| Some of the benefits are visual consistency (e.g. you avoid
| having 20 slight variations of green spread between designs,
| implementations of those designs, and across different apps),
| accessibility (e.g. you can do accessibility checks at the
| semantic layer and all your components benefit), communication
| (e.g. gives designers and devs a shared language), ease of
| updates (e.g. update the colors in the base layer, and it spreads
| to all your designs and coded apps), and faster design + dev
| (because you're picking from a small number of predefined
| choices).
|
| I agree if you're a developer, articles on this can look like way
| too much text, including the frequent elaborate discussions on
| how do you just name the constants but... this stuff is brand new
| to many dedicated designers!
|
| UI design apps like Figma have only in the last couple of years
| started including ways to manage layers of variables like this,
| so many are just getting to grips with it because where else
| would they have seen elaborate layers of variables before?
|
| Developers have been discussing and practicing for decades how to
| name variables and modules, how to architecture/layer stuff like
| this, and how we should use named constants over magic numbers,
| so the above is going to look more obvious to developers.
|
| The base/semantic/component layering isn't completely obvious
| either, and really does help with organization as the number of
| constants do build up. The three layers is overkill for simpler
| apps, but just having the base and semantic layer is helpful for
| even basic UI/web designs with custom brands, especially for
| keeping accessibility in check.
| tuzemec wrote:
| We use Tokens Studio Figma plugin [1] to export the tokens that
| the designers defined to a github repo. We have a few front end
| projects that consume them - one is sass based, the others are
| emotion/theme-ui and we have different style dictionary[2]
| scripts that transform the source tokens for the relevant
| projects.
|
| Everything was working great until the designers decided the
| existing tokens were insufficient, and new designers joined who
| simply chose not to use them (because... reasons).
|
| My point is that tokens work well when there is full alignment
| between the design and engineering teams. However, it requires
| extra effort from both sides to consistently "follow the rules".
|
| [1] - https://tokens.studio/plugin
|
| [2] - https://amzn.github.io/style-dictionary/#/
| martinsnow wrote:
| Of course. If you don't design your system right and enforce
| consistency it will be a mess. That's programming and pretty
| much engineering in a nutshell.
| block_dagger wrote:
| "Tokens" makes me think of crypto/blockchain. Suboptimal naming.
| kaelig wrote:
| For context, this name was coined 10 years ago, before the
| crypto/blockchain craze.
| GiorgioG wrote:
| > There's a whole movement bringing DevOps and SRE thinking to
| design/UX
|
| Heaven help us. Hope this dies a quick death.
| kaelig wrote:
| Say more
| GiorgioG wrote:
| > DevOps and SRE thinking
|
| DevOps thinking is exactly what got us into this IaC mess
| we're in now. Back in the day (like 15 years ago), things
| were actually simpler - you were either dev or ops, period.
| But then K8s and all that jazz came along, and suddenly we
| need this whole army of "DevOps engineers" just to keep the
| lights on and make everything 10x more complicated than it
| needs to be. And please don't say "yes but the cloud changed
| everything" - no someone made the cloud more complicated than
| it needed/needs to be and thanks to ZIRP, companies just kept
| hiring DevOps 'engineers'.
|
| I've seen this multiple times: Management looks at this
| circus and goes "Let's make all each dev team handle their
| own DevOps crap." Meanwhile, they're telling the actual
| DevOps engineers to go back to focusing on ops. What was even
| the point of this whole transformation if we're just creating
| more specialists and dumping more complexity on developers'
| plate?
|
| The whole thing has basically turned into its own monster
| that needs constant feeding. We didn't need all this overhead
| before, but here we are, drowning in YAML and dealing with
| infrastructure that's way more complex than the actual
| problems we're trying to solve.
|
| I can't wait for Design Token Engineers to become a thing /s
| kaelig wrote:
| Thank you for sharing -- sounds like we've had different
| experiences but I can absolutely see how poorly implemented
| devops is worse than well-implemented ops.
|
| I've written about operationalizing design and
| design/engineering collaboration for a while now, and work
| at a frontend cloud PaaS... So I appreciate hearing from
| folks outside of my own bubble!
|
| The path from idea to production was arduous for frontend
| and design back in these days. I for one appreciate being
| able to deploy frontend changes to production in just a few
| minutes, which the cloud + SRE + DevOps mindsets have
| helped democratize.
| MrMcCall wrote:
| This work looks to be rather excellent, apart from their deciding
| to coin their own term "token" for what I take to be a "design
| element".
|
| Here is my slightly edited comment from below:
|
| What they are calling "tokens" are just their design elements.
|
| They have abstracted the design elements into their 'tokens' so
| that they are defined parameters/variables/model-elements that
| can then be reified at some point before deployment.
|
| This is a fancy (but seemingly excellent) way of encompassing a
| system's design decisions into a model, which can then be used
| either abstractly or concretely to proliferate them throughout
| the entire system, as needed, at the latest possible point the
| actual values are needed.
|
| It really looks like top-shelf work, but I think their deciding
| to use the word "token" was an unnecessary mistake of
| nomenclature.
| einsty wrote:
| I think the term token had been used in some UI products for
| quite a while now. The first time I heard it felt a little
| awkward but it is really quite natural now.
| MrMcCall wrote:
| Thanks. That's not my workspace, so it makes sense that I
| would be unaware of it, my just being a programmer.
| strogonoff wrote:
| "Design token" is an accepted and widely used term (see
| Amazon's Style Dictionary, Adobe's Spectrum, etc.) that might
| even be standardized[0] by W3C at some point soon. Unlike
| "design element", it refers to a more general concept; there is
| less confusion when you refer to a color, or to a measure, as
| "token" rather than "element".
|
| (The term "variable" may be more fitting, but it is on the
| other hand _too_ generic and conflicting with a different idea
| in implementation domain: CSS or JS variables can mean the same
| thing, but not always.)
|
| [0] https://github.com/design-tokens/community-group
| MrMcCall wrote:
| Thanks. That makes sense, even if my old-school brain finds
| the term less than optimal.
| strogonoff wrote:
| As an old-school designer, I didn't like the term at first,
| but to be honest it is winning me.
|
| I was taught design in terms of design models and design
| systems, so there was not much of a leap to "design token"
| as referring to a building block.
|
| I am not 100% sure how I feel about it in general. If I was
| a designer who was only given freedom to operate within a
| set of tokens, I would certainly feel like my hands are
| tied. At the same time, I can see how even while using
| tokens it is entirely possible to design a bad interface.
| However, I also see value of them when it comes to
| maintaining consistent and intuitive UIs.
| MrMcCall wrote:
| > I also see value of them when it comes to maintaining
| consistent and intuitive UIs
|
| Absolutely. It's like the proper legacy of the GoF's
| "Design Patterns" book, whose lack of importance and
| acceptance has bewildered me for close on 30yrs now. Of
| course, it also means I have rich fields to till for my
| own work, so bwahaha :-)
|
| [Note that the actual design patterns described in their
| book are not the important part; their understanding that
| we must implement software using patterns is their most
| important concept.]
| arkh wrote:
| You can already imagine OS vendors publishing their
| design tokens to let you "easily" integrate your
| applications even if not using their UI libraries.
| whoisstan wrote:
| This makes sense to me, but it seems to contrary to the current
| utility-based css wave. For example 'text-red-100' for error
| message text wouldn't be in style dictionary like that, it would
| be 'text-color-error' since using 'text-red-100' would always be
| red 100 and not able to change the text-yellow-500.
|
| Point being isn't that a route back to semantic styling? I much
| prefer the maintainability cycles of semantic styling over the
| onslaught of classes in i.e. tailwind.
| strogonoff wrote:
| Part of the reason I like design tokens is that they are a
| middle ground between the chaos of utility classes[0] and
| impracticality of pure semantics, while being in a way better
| defined than either of them.
|
| Want a token for a colour with negative semantics? Sure! A
| token for chartreuse-200? Be my guest! At least, chartreuse-200
| on your page will be the same as chartreuse-200 on my page, so
| that the look is consistent and without distracting incidental
| variation in hue.
|
| [0] When it comes to CSS--of course, design tokens reside on
| another layer of abstraction, not tied to any particular
| implementation.
| whoisstan wrote:
| Agree, you tap into the rigidness of a semantic color and
| type hierarchy, while allowing utility classes for specifics
| of a platform/environment.
| ActionHank wrote:
| It makes sense, but I struggle to see the value outside of
| whitelabel products that you may look to rebrand, but with the
| same UI.
|
| Generally UI is built around a singular look and feel at a
| given point in time. Trends change, people change, ideas and
| features change.
|
| You eventually end up with a rebranding and along with that
| some sort of UI refactoring.
|
| This approach is incredibly valuable when building something
| that won't change drastically when you are changing those
| tokens.
| whoisstan wrote:
| It has to be useful for large organizations like for example
| IBM who need to maintain consistency on various domains,
| displays and media types. But I suspect it also can stiffle
| innovation.
| kaelig wrote:
| It also helps small teams build faster. A shared language
| around color, spacing, typography makes design/engineering
| collaboration way smoother, and reduces rework.
|
| A good first step is to have your color palette in your
| design tool of choice consistent with the variable names
| used in CSS.
|
| > But I suspect it also can stiffle innovation.
|
| Like any system: it can both be empowering or the opposite.
|
| It's a tough balancing act. Let's say you're Adobe, and you
| want Photoshop/Illustrator/InDesign to feel like a single
| family of products across web/iOS/iPadOS/Windows: where do
| you want to let feature teams innovate, and where must they
| adhere to the system so users can navigate seamlessly
| across these products and platforms?
| whoisstan wrote:
| Its like parenting, be loose and strict in the same way.
| You have to find a good balance given the team
| composition and corporate restrictions.
| jillesvangurp wrote:
| Some of the examples look a lot like tailwind. Was this inspired
| by the that or is tailwind actually attempting to implement some
| of these concepts? Anyway, I'm using tailwind more and more and I
| am liking that.
|
| Not hard coding colors, margins, etc. is definitely a nice thing.
| And being able to reuse definitions for those across multiple
| projects, software stacks, frameworks, design tools, etc. would
| be nice as well. Does something like that exist at all? Because
| the last thing companies should be doing is building a lot of
| internal crap to support this probably.
| c-hendricks wrote:
| It's not like this is a new concept, here's bootstrap almost 15
| years ago:
|
| https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/as...
|
| https://github.com/twbs/bootstrap-sass/blob/v2.0.0/vendor/as...
| aridiculous wrote:
| Seems like a lot of the comments are not getting it.
|
| The purpose of tokens is be able to have a single language-
| agnostic source of truth for the core bits of the design
| decisions.
|
| Let's say you have a website, an iOS app, an Android app, Figma
| templates, and documentation. Let's also say your main brand
| color is currently a certain shade of green.
|
| When your brand evolves to a different shade of green, you update
| one value in one place. All of the above surfaces are updated at
| the same time.
|
| This was not a thing with Bootstrap, and it's not a thing with
| CSS variables and derived values. This is an organizational tool
| that increases in value as a multi-platform company grows.
|
| It's true that most websites and apps probably don't work this
| way today. I've worked in a lot of them, and they were not
| pleasant developer experiences burning up way more developer time
| than necessary. They become unwieldy at any kind of scale,
| producing all kinds of visual bugs and incongruencies on every
| single engineer PR.
|
| An interesting question would be: "how much does it matter that
| the visual language is consistent across a company's assets?".
| But the answer to the question of the utility of the design
| tokens is obvious if you do decide that design systems are
| important for a business.
| psygn89 wrote:
| I think people get hung up on the term "tokens" and imagine
| something more. They should've kept it simple and called it
| design variables or something.
| lyu07282 wrote:
| if this is the first time you heard that term then you will
| be hopelessly lost, but these concepts are a decade old by
| now and used by UI teams in every medium/major company in the
| world. It's well established terminology, if people never
| heard about it before they should question the validity of
| their opinions on the matter.
| Joker_vD wrote:
| > When your brand evolves to a different shade of green
|
| This is such a funny line to read. I just can't help but
| imagine a brand like a small bulbasaur that evolves into big,
| strong venosaur which _of course_ involves changing its shade
| of green.
|
| > An interesting question would be: "how much does it matter
| that the visual language is consistent across a company's
| assets?"
|
| An even more interesting question would be "if we keep changing
| the colours/shapes/general theme/etc. of our brand's logos
| every nine months or so, _do they even matter_ , really?"
|
| My suspicion is that the answer is "no, not really, that's why
| we can afford to meddle with them since it's a mostly
| consequence-free environment, and it distracts busybodies from
| breaking some actually important aspect of the business".
| kaelig wrote:
| Joke aside, there are truly valid reasons why you'd want to
| change a single color across dozens of codebases, for what
| can amount to tens of thousands of occurrences. For example:
| adjusting link color contrast for accessibility compliance.
|
| Salesforce (where the term "design tokens" was coined) is
| akin to an operating system for the web, with its own app
| ecosystem. Developers building Salesforce apps can blend into
| the Salesforce ecosystem thanks to their design system and
| design tokens.
|
| And I recommend reading
| https://m3.material.io/foundations/design-tokens/overview to
| see how Google allows Android app developers to build
| incredibly expressive and user-personalizable UIs using
| design tokens.
| yakshaving_jgt wrote:
| Fortunately, computers are already really good at finding
| and replacing strings.
| kaelig wrote:
| You can try automating search/replace on hex/hsl/rgb
| values across all your codebases, but targeting "primary
| button backgrounds on hover" is only possible with some
| more advanced tooling in place.
|
| And there's an important runtime aspect when it comes to
| theming, so it's not just about finding/replacing
| hardcoded values.
| BoorishBears wrote:
| Why is Material UI still so comically awful?
|
| M3 is an upgrade but even the "header carousel" component
| there had me straight up pause and study all the ways it's
| terrible
|
| From the ripple effect that overflows depending on how wide
| the text underneath is.
|
| The "back button" which is actually for going from one
| section to the next
|
| And the way it behaves as I click from section to section
| using those buttons is "top tier jank" for the lack of a
| better term
|
| The way it also randomly seems to align or not align the
| currently selected heading resulting in weird clipping of
| text that just looks confusing and broken.
|
| The shadow indicating the elevation chance as it goes
| sticky also looks and feels straight out of Windows 95
|
| Why can't Google just make an aesthetically pleasing UI? It
| almost feels like Apple and the "modern SaaS template ala
| WorkOS" guys stole the only two good looking directions for
| modern UI aesthetics and now Google is stuck pushing along
| their hideous (but identifiable!) aesthetic along side
| them.
| seanwilson wrote:
| > This is such a funny line to read. I just can't help but
| imagine a brand like a small bulbasaur that evolves into big,
| strong venosaur which of course involves changing its shade
| of green.
|
| Facebook updated their main brand blue and other colors in
| 2023, partly for accessibility:
| https://design.facebook.com/stories/redefining-facebooks-
| bra...
|
| Wise also had a rebranding with accessibility in mind:
| https://the-brandidentity.com/interview/how-the-ragged-
| edge-...
|
| Figma recently changed their colors too:
| https://www.figma.com/blog/figma-on-figma-evolving-our-
| visua...
|
| It won't be just a single color either, but a whole palette
| for them. It's not practical to do a search/replace of color
| hexes across all designs and code, because it can depend on
| context which color is appropriate to use where, especially
| for accessibility.
|
| It's also the norm I would say for startups and small
| companies to launch with minimal/good-enough branding (often
| with poor color contrast for the main brand colors because
| people love bright colors on white), and then they
| change/refine it later when it's more important.
|
| Not saying you need design tokens at all stages, but brands
| do evolve.
| motorest wrote:
| > This was not a thing with Bootstrap, and it's not a thing
| with CSS variables and derived values. This is an
| organizational tool that increases in value as a multi-platform
| company grows.
|
| Perhaps I'm missing something, but Bootstrap does support this,
| doesn't it?
|
| https://getbootstrap.com/docs/5.2/customize/css-variables/
|
| Please explain why you feel this usecase hasn't already been
| supported for years.
|
| Also, other tools such as sass also support this feature.
|
| https://sass-lang.com/documentation/variables/
|
| Can you elaborate why you think this problem isn't a solved
| problem?
| have_faith wrote:
| The point of design tokens is that they sit above your
| framework and library choices, so it's not possible for
| bootstrap to solve this as it's a down-stream library.
| Bootstrap is a consumer of design tokens in that they might
| be fed into bootstraps css variable system. But in a design
| token system you wouldn't use bootstrap as a source of truth
| for these tokens, you want something more flexible and
| programatically portable than CSS.
| kaelig wrote:
| Bootstrap and Sass are for the web. They don't solve the
| interop problem for Figma/Sketch/Framer/iOS/macOS/Windows/And
| roid/TVs/Watches/Fridges/Cars and what have you.
|
| And that's not even accounting for web styling solutions that
| don't use CSS variables.
| motorest wrote:
| > Bootstrap and Sass are for the web.
|
| Cool, so we establish that the likes of Bootstrap and Sass
| already solve this problem for the web.
|
| > They don't solve the interop problem for
| Figma/Sketch/Framer
|
| That's irrelevant, isn't it? I mean, do you run apps
| straight out of Sigma/Sketch/Framer? Do you also think it's
| reasonable to call out Photoshop/Gimp/MSPaint?
|
| > iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars
|
| You're trying to refer to platforms/OSes, aren't you? Do
| you think it makes any sense to bundle everything together?
| Those who work on
| iOS/macOS/Windows/Android/TVs/Watches/Fridges/Cars would
| certainly look at you perplexed just for suggesting that
| specifying color schemes even registers as a concern in the
| whole cross-platform discussion.
|
| >
| kaelig wrote:
| > Bootstrap and Sass already solve this problem for the
| web.
|
| In a vacuum, sure. But products aren't all built in a
| web-centric vacuum.
|
| > That's irrelevant, isn't it? I mean, do you run apps
| straight out of Sigma/Sketch/Framer? Do you also think
| it's reasonable to call out Photoshop/Gimp/MSPaint?
|
| Figma/Sketch/Framer are design and prototyping tools.
| They are _very_ relevant in how we build products. The
| back-and-forth between design and engineering leads to
| better outcomes if both sides speak the same language,
| and their tools allow them to do so.
|
| (Photoshop/Gimp/MSPaint aren't so relevant un product
| design)
|
| > Do you think it makes any sense to bundle everything
| together?
|
| Not everything. You generally want folks using your
| products across iOS, their car, their TV, and a web
| browser have a coherent experience. This doesn't mean
| that everything needs to look exactly the same. It means
| that key design decisions can be distributed across the
| board.
| groby_b wrote:
| > This is an organizational tool that increases in value as a
| multi-platform company grows.
|
| That sounds impressive enough for the UX sales presentation.
| Meanwhile, how is it any different from "don't just use
| numbers, use an agreed-upon set of constants"?
|
| > When your brand evolves to a different shade of green, you
| update one value in one place. All of the above surfaces are
| updated at the same time.
|
| Awesome. And I assume all contrast issues fix themselves? So do
| color clashes? No? Designers still need to consider their
| change in context? So, again, how is it different from a set of
| agreed-upon constants?
|
| CSS variables and derived values are a way to implement those
| constants. Not the only one, but a decent one. Yes, you need to
| properly resolve dependencies/propagate values, but you need to
| do that with any other implementation as well.
|
| Sure, call it design tokens instead of constants - but is there
| any difference? I'm really trying to understand how this is
| contributing anything on top of symbolic referents. Something
| that at least on the engineering side is well known since
| before the infamous "should the value of pi change" manual
| entry.
| kaelig wrote:
| It's not too different, as the concept was heavily influenced
| by localization libraries.
|
| That said they're not always constants. A design token can
| mutate based on device, light/dark/high-contrast mode,
| viewport size, user preference, locale, brand, product,
| theme, etc. This mutation can apply at runtime or at build
| time depending on the use-case.
| lyu07282 wrote:
| I suspect commenters already don't quite get the point of
| design systems in the first place, this UI architecture idea
| goes several steps beyond that. Design systems are already
| really hard to pull off depending on the people involved, any
| effort at systematizing that approach are very well worth it,
| but is going to be met with opposition.
|
| I suspect if you wrote about atomic design[1] for example you
| would get similar comments.
|
| Also here[2] is an example of a design system to better
| understand how to extrapolate the "brand color" example.
|
| [1] https://atomicdesign.bradfrost.com/chapter-1/ [2]
| https://atlassian.design/components/tokens/all-tokens
| taeric wrote:
| As I get older, I have grown to really distrust any technological
| choice of having a "single source of truth" and "Cross-
| Disciplinary" concerns.
|
| Having a tool reconcile data across sources makes sense. Having a
| single source, sadly, does not. Especially not when you are
| forcing stakeholders/users to either use a new tool for this, or
| worse, to change their vocabulary and tooling to support it.
|
| So, I get the desire. It would be nice to have a way to say "this
| color red is always used for whatever reason." But then you will
| have people try and layer that on with "for other reasons, things
| of another type will always be darker by about 4 shades." Someone
| will see one of these interactions go poorly, and add whatever
| emphasis they can to the rule they care about. Then the
| obfuscations begin.
| hammock wrote:
| What is the alternative? "Having a tool reconcile data across
| sources " ? Is that more or less hard?
| taeric wrote:
| Most realistically, the main alternative will be processes
| focused on product release. With a statistical acceptance of
| mistakes. Consider that Coke has a specific shade that they
| have used for a long time.
|
| My main problems with efforts like this is that they cannot
| distinguish between different organizational priorities on
| design considerations and they make virtually no allowance
| for what different practitioners are using today.
|
| That later point is the one that drives me the most crazy. We
| have very few tools that can help reconcile a graphic design
| to a website. Most of what we have are attempts to change how
| graphic designs are created so that they can be more directly
| transferred.
| kaelig wrote:
| > processes focused on product release
|
| +10000
|
| As I mentioned in a couple of my other messages, beware of
| people over-systematizing and over-centralizing, as it can
| come at the cost of delivery efficiency and defeats the
| point of operationalizing design. Plus, it creates a
| growing maintenance burden on the team maintaining that
| single source of truth.
| meiraleal wrote:
| > beware of people over-systematizing and over-
| centralizing, as it can come at the cost of delivery
| efficiency and defeats the point of operationalizing
| design
|
| Yes but also be aware of systems (or lack of) that people
| deliver crap fast (which is only better than delivering
| crap slowly).
| kaelig wrote:
| You're right in that the "centralized single source of truth"
| actually rarely is a thing at scale.
|
| It's common to adopt a mixed approach: some design tokens make
| sense to centralize (like global brand colors), and others are
| local, such as tokens for a specific product or sub-brand.
|
| For example, a web app can build its own token architecture
| based on an existing foundation shared with iOS and Android
| apps. They share _some_ concerns, but technical implementations
| differ they may offer different theming features, too.
| braden-lk wrote:
| Design-first thinking with tokens is a game-changer for an org
| building a product that needs to adapt to multiple clients. It's
| still useful for a singularly-branded product just for
| separation-of-concerns reasons, but maybe less useful.
|
| Design tokens aren't concerned with implementation. (CSS vars,
| constants, etc.). Design tokens are an abstraction for
| standardizing and communicating the values in your design system,
| regardless of where they show up. Yes, you might implement your
| design tokens as CSS variables, but not necessarily.
___________________________________________________________________
(page generated 2024-12-18 23:01 UTC)