Align Properties in Figma and Storybook/Code

[thrbnhrtmnn]

Hey everybody 👋

I would like to discuss if we should align properties in Figma and Storybook/Code.

We already invested some time to align the properties in Storybook/Code. We made sure, that properties which do the same have the same name in all our components. We also categorised the properties in different clusters like "Appearance", "Content/Settings" or "States" to only name a few. Lastly we made sure that the categories and the properties within the categories are always listed in the same order for each component.

What we did not do is align this also with the properties that exist in Figma.

From my understanding Figma properties also function differently than component properties in code. For example the different states of a component are also properties in Figma, but in code these are completely integrated into the code and define how a component works. States are not something that you should just be able to change via a prop in the coded component.

On the other hand we have properties in Figma, which function exactly like the properties in code. For example for the Button Text component we have a property in Figma to change the size and we have a property to change the variant, exactly like in code, but the names are different. In code we name it sizeVariant, in Figma we name it Size. In code we name it variant, in Figma we name it Emphasis.

Another difference between Figma and Storybook/code is how components can be nested within each other. When I add an icon component to the Button Text component in Figma, I can change the properties of the icon component like anywhere else. In code we do not allow this. In code we define exactly which size the icon will have, based on the size of the Button Text component.

Here is a List of possible changes for the properties in Figma (ignoring the States property):

Component	old prop name	new prop name
Button Group	Size	sizeVariant
Button Group	Layout	alignment
Button Group	Lead/Center/Trailing Button	TBD, no equivalent in code
Button Icon	Emphasis	variant
Button Icon	Scale	sizeVariant
Button Icon	State	TBD, no equivalent in code
Button Text	Emphasis	variant
Button Text	Size	sizeVariant
Button Text	State	TBD, no equivalent in code
Button Text	Mode	TBD. is this the same as buttonDisplay in code? There is only the "ContentHug" option in Figma, do we need to extend this?
Button Text	LeadingIcon	Should be replaced by "icon" and "iconPosition"
Button Text	TrailingIcon	Should be replaced by "icon" and "iconPosition"
Button Text	Label	label
Checkbox	Scale	sizeVariant
Checkbox	Selection	Should be split into multiple boolean props: "checked" and "indeterminate", possibly we also should add "checkedIcon" and "indeterminateIcon"
Checkbox	HasCaption	TBD, should this be split into "hasHint" and "hasError" and behave similar to code?
Counter	Mode	variant
Counter	Size	siteVariant
Counter	CharCount	value
Counter	MaxCount	maxValue
Divider	Direction	direction
Form Caption	TBD, we should add a prop to switch between hint and error	variant
Form Caption	HintIcon / ErrorIcon	icon
Form Caption	HintMsg / ErrorMsg	message
Form Caption	TBD, we should add a prop to switch between sizeVariants	sizeVariant
Form Caption Group	Variant	TBD, in code this is not needed, as whether an error or hint is show is always defined be the parent component
Form Caption Group	TBD, we should add a prop to switch between sizeVariants	sizeVariant
Form Label	Size	sizeVariant
Form Label	Error	hasError
Form Label	Label	label
Form Label	Appendix, this one exists twice	One should be named labelAppendix, the other one could be named "hasLabelAppendix", which would need to be added in code as well
Icon	Size	sizeVariant
Icon	TBD, should we add a boolean fillParent prop	fillParent
Input Field Number	Size	sizeVariant
Input Field Number	Stepper	stepperVariant
Input Field Number	Placeholder	placeholder
Input Field Number	HasPlaceholder	TBD, not needed in code? Maybe also not needed in design?
Input Field Number	Filled	TBD, not needed in code? Maybe not needed in design?
Input Field Number	User Input	value
Input Field Number	TBD, should a decimals or leadingZeros prop be added?	decimals / leadingZeros
Input Field Number	TBD, should we add a hasUnit prop and change HasPrefix and HasSuffix to unitPosition and also change Prefix and Suffix to unit?	hasUnit / unitPosition / unit
Input Field Number	Error	hasError
Input Field Number	HasCaption	TBD, should this be split into "hasHint" and "hasError" and behave similar to code?
Input Field Text	TBD	TBD
Loader	Mode	variant
Loader	Scale	sizeVariant
Radio	Selected	checked
Radio	Scale	sizeVariant
Radio	LblNext2Ctrl	label
Radio	Hint	hasHint
Radio Group	Scale	sizeVariant
Radio Group	Direction	direction
Radio Group	HasLegend	hasLegend
Radio Group	Legend	legend
Radio Group	HasCaption	TBD, should this be split into "hasHint" and "hasError" and behave similar to code?
Select	Scale	sizeVariant
Select	Error	hasError
Select	HasLabel	hasLabel
Select	User Input	TBD, there is no User Input prop in code and nothing similar
Select	Trailing Icon	TBD, in code we only have an icon prop and if it is undefined there is no icon
Select	HasCaption	TBD, should this be split into "hasHint" and "hasError" and behave similar to code?
SliderSingleValue	TBD	TBD
SliderTwoValues	TBD	TBD
TabBar	TBD	TBD
Text Area	Scale	sizeVariant
Text Area	Filled	TBD, not needed in code? Maybe not needed in design?
Text Area	User Input	value
Text Area	Error	hasError
Text Area	isResizable	resize, in code we have 3 options (horizontal, vertical, both), but in design only 2 (true, false)
Text Area	HasLabel	hasLabel
Text Area	HasPlaceholder	TBD, not needed in code? Maybe also not needed in design?
Text Area	HasCounter	hasCounter
Text Area	HasCaption	TBD, should this be split into "hasHint" and "hasError" and behave similar to code?
Text Area	TBD, do we need something like cols and rows in code?	cols / rows
Toggle Switch	Scale	sizeVariant
Toggle Switch	HasStateLabel	hasStateLabel
Toggle Switch	HasStateLabel	hasStateLabel
Toggle Switch	Active (part of the Toggle Switch Control sub-component)	active
Toggle Switch	HasLabel	hasLabel
Toggle Switch	Label	label
Toggle Switch	Inactive (part of the Toggle Switch Control sub-component)	offLabel
Toggle Switch	Active (part of the Toggle Switch Control sub-component)	onLabel
Toggle Switch	HasCaption	hasCaption
Tooltip	Placement	placement, props mean different things here, there is issue #1087 to fix this, this should also replace option "None" to be its own property called "hasArrow"
Tooltip	Elevation	elevation, could also be changed to boolean in design to be more aligned with code
Tooltip	Text	message

Suggestions

• The above list should be discussed together with design and dev leads and unclear changes need to be defined together
• There should be a general discussion and decision about the topic of how close design and dev need to be aligned
• Properties in the "Appearance" cluster should be perfectly aligned between design and code
• Properties in the "Content / Settings" cluster should be somewhat aligned between design and code, meaning that there needs to be an way to change contents in design and in code, but these can be handled differently
• Properties that are only needed in code, but not in design should be moved into the "Technical Attributes" cluster (i. e. maxLength & minLength for Text Area)