Systems governance se marte hain, code se nahi
Failure ka pattern jaana pehchana hai: zabardast launch, saath component, andar aik chamakta hua demo — aur athara mahine baad chaar button variants library ke bahar zinda hain aur product teams chupke se usay fork kar chuki hain. Is mein taqreeban kuch bhi technical masla nahi hai. Masla yeh hai ke is sawal ka jawab kisi ke zimme nahi tha ke "mujhe aisi cheez chahiye jo system mein nahi hai, to jumeraat ko main kya karun?" System ko aik namzad owner chahiye jis ke paas asli ghante hon, aik documented contribution path, aur response time ka waada — 48 ghante mein haan, na, ya koi workaround. Yeh window miss hui to teams apna version launch kar deti hain, aur theek karti hain, kyunke un ki deadline hai. Yeh bhi publish karen ke system kya cover nahi karega. Jo system har cheez hal karne ka dawa karta hai, har cheez ka ilzaam usi par aata hai, aur "aik baar wale marketing layouts scope se bahar hain" kisi bhi lint rule se ziyada forks rokta hai.
Teen token layers, aik nahi
Flat token sets doosri theme ke aas paas scale karna chhor dete hain. Teen layers istemal karen. Primitives kachhe values hain jin ka koi matlab nahi juda hota: blue-600, space-4, aik literal hex. Semantic tokens primitives ko irade se jorte hain: colour-action-primary, colour-surface-raised, colour-text-muted. Component tokens semantics ko makhsoos hisson se jorte hain: button-primary-background. Product code sirf semantic aur component tokens reference kar sakta hai — jis lamhe koi component seedha blue-600 import karta hai, dark mode poore codebase par find-and-replace ban jata hai. Faida bilkul thos hai: dark theme add karne ka matlab aik semantic layer, taqreeban 40 values, dobara define karna hai, na ke 600 usages audit karna. Naming ko boring rakhen aur jahan ho sake machine-generated, usay aik hi source se CSS custom properties aur design-tool variables mein sync karen, aur donon ko kabhi alag alag haath se maintain hone wali lists mein bikharne na den.
Do-istemal ka usool
Abstraction doosre asli istemal par karen, pehle par nahi, aur teesre par bhi nahi. Pehle istemal par aap andaza laga rahe hote hain ke kaun se hisse badalte hain, aur ghalat andaza aisa component paida karta hai jis ke gyara props hon aur jo us markup se ziyada mushkil ho jis ki us ne jagah li thi. Teesre tak teen teams na-mutabiq variants launch kar chuki hoti hain aur consolidation aik migration ban jati hai. Do asli istemal wo nuqta hai jahan variation ka axis nazar aa chuka hota hai magar tabdeeli ka kharcha abhi kam hai. "Asli" ka matlab hai mukhtalif logon ne mukhtalif maqasid ke liye production mein launch kiya ho — aik hi page par do baar istemal hone wala wohi card aik hi istemal hai. Is se juri baat: kuch cheezon ko kabhi abstract nahi karna chahiye. Aik baar istemal hone wala layout, aik illustration, kisi aik page ki makhsoos animation. Copy-paste ghalat abstraction se sasta hai, aur duplicate block delete karna shared block ko suljhane se ziyada aasan hai.
Adoption ko sab se aasan raasta banayen
Adoption hukum se kabhi nahi milti; wo tab milti hai jab library kaam karne ka sab se tez tareeqa ho. Is ka matlab hai aik hi command mein installation, aik chalta hua example jo paste kiya ja sake, aur aise props jo logon ki maujooda soch se mel khate hon. Isay imaandari se maapen — aik script jo har repository mein library imports aur raw elements ginti hai, aap ko coverage number de deti hai, aur per team coverage bata deti hai ke system kahan fail ho raha hai. Wo number publish karen. Phir accessibility se faasla khatam karen: agar library ka select keyboard se navigate hota hai, screen-reader labelled hai aur focus-trapped theek se hai, to usay dobara banana aik aisa hafta hai jo koi kharch nahi karna chahta. Yehi asli moat hai. Aakhir mein, version soch samajh kar karen, breaking changes ke saath codemods bhejen, aur kisi team ko kabhi upgrade karne aur apna roadmap launch karne ke darmiyan chunne par majboor na karen.