What is a component in a design system?
When we talk about design systems, a lot of time is spent talking about what a thing is, creating a shared understanding to what things are is just as important as what the names themselves.
These things are thought about as getting progressively bigger in size.
With that in mind we can then generally break it down into the following:
small things: header, labels, input, button
collection: form
page: about you
pattern: collect person details
Component? Atom? Element? UI asset?
Regardless of what you articulate it, generally speaking, these are the smallest part of a design system.
Brad Frost talks about an atom as:
“Atoms are the basic building blocks of matter. Applied to web interfaces, atoms are our HTML tags, such as a form label, an input or a button.”
If we replace Atoms, with any word, then we still have the intent that we are trying to achieve.
Naming this is hard. Giving people a shared understanding of what a thing is, can help a lot also what needs to be clear is the space between what you call them. How is a component different to a visual style or a pattern? or other things you have decided you have.
Breakdown of a component
Name aside there are quite a few principles we could apply to a component. Applying principles, and defining standards to a component will help others contribute to it.
These principles should develop over time as there is more understanding how to deliver these onto many projects, at a first pass I wrote this:
Principles
- Responsive
- Cross-browser support
- accessible
- progressive
Outcomes
- HTML
- CSS
- JavaScript
- Documentation
- Testing
- Templating support
If we deliver the above then we should have a component that can be reused across projects but it doesn’t need to be all of the above.
We might take a slice and decide to not to do some parts of the above — for example templating support can be really complicated across multiple technology stacks.
HTML
Examples of the markup of the component, with different states. This HTML should be semantic and accessible.
When we talk about accessible, this should include making sure it is keyboard accessible and is using the correct tags.
CSS
There are a few choices that will be driven by how components are used, things to consider
- how will you provide it? Compiled CSS? Sass partial? Both?
- will you use OOCSS, SMACSS, and BEM?
- if you are using sass, what standard will you lint to?
- will this be used with current variables, what is that relationship?
- will it be able to run it independently
JavaScript
Again, like CSS there are a few things to decide on.
- how do we provide this so it can be consumed as a module?
- will it use other libraries? (dependencies)
- how does it work when the JavaScript fails?
Documentation
The examples of HTML goes some way to providing documentation for how to use a component, but also having docs around how to install or consume it is useful. Research notes can also be very helpful, ‘this worked well in x situation’
Automated testing
Making sure a component is well tested is important as it will be being used across a range of browsers and devices, a couple of different types of testing could be added.
- unit testing against the JavaScript
- visual regression to make sure the design doesn’t change
- accessibility tests (keyboard, colour checks)
- snapshots of the markup
Templating support
Building template support for a component can be time-consuming and can become a maintenance headache.
- what languages do you support?
- is the implementation the same?
- what is the effort to add a new one?
