Tervezési rendszer nélkül minden tervező és fejlesztő önállóan hoz apró döntéseket: kicsit más kék, új gombstílus, más térközérték. Egy év elteltével a terméknek több tucat, majdnem ismétlődő példánya van. A tervezési rendszer ezeket az ismétlődő döntéseket megosztott döntésekkel helyettesíti.
A legtöbb tervezési rendszer háromrétegű. A tervezési tokenek elnevezett értékek, például color.primary, space.4 vagy motion.duration.short, amelyek a nyers döntéseket tárolják. Az összetevők, például a gombok, bemenetek, kártyák és párbeszédpanelek ezekből a tokenekből épülnek fel, és minden állapotot tartalmaznak. Az irányelvek dokumentálják az egyes összetevők használatát, a címkék és üzenetek írását, valamint az alkalmazandó kisegítő lehetőségeket.
A tervezőrendszer két helyen él: a tervezőeszközben, mint komponenskönyvtár, és a kódban, a fejlesztők által telepített csomagban. A kettő szinkronban tartása a legnehezebb. Amikor a kódolt gomb már nem egyezik a tervezett gombbal, az emberek nem bíznak a rendszerben.
A mozgás is hozzátartozik a rendszerhez. Az időtartamok, a könnyítési görbék és a rugóbeállítások tokenek lehetnek, és az interaktív összetevőknek meghatározott viselkedésre van szükségük a lebegés, a nyomás, a betöltés és az átmenetek során. Az általunk készített ExodeUI ezt a viselkedést egyetlen nyitott fájlban tárolja állapotokkal és rugófizikával, így ugyanaz a komponens játszik le a React, Vue, SwiftUI, Flutter és más keretrendszerekben.
A jól ismert nyilvános példák közé tartozik a Google Material Design, az Apple Human Interface Guidelines, az IBM Carbon és a Shopify Polaris. Ezek elolvasása jó módja annak, hogy megtudja, hogyan épül fel egy kiforrott rendszer.