Looking at our components through different lenses

Right at the beginning of creating a new component, we can bring together people from other disciplines to look at the work in the round. If there’s a requirement for a component, do we just design it and hand it over or between a cross-functional team, can we turn it around and consider it from various angles to make sure we’re not missing anything. If you could think of it as a design system twist to the 3 Amigos style meeting, you might come across in some flavours of agile. This typically gets together a Product person or Business Analyst with someone from Development and Testing as a kick-off. Here are some suggestions of ‘lenses’ you could look at your component through:

Visual Design

We can consider the application of a brand in even the most minor components. A button could be a nondescript, functional entity, or it could be something that is recognisably ‘our’ button. What are the brand personality traits? Do we feel they’re present in a way that’s appropriate for the purpose of this component and complements the UX?

Content

Whether you have Content Designers on your team or not, it’s worth considering the microcopy requirements. Is there guidance you can provide people using it to help them know what good looks like? This component may be a call to action or a title/heading section component with a specific purpose; establishing some constraints and tone of voice would help your colleagues make the most out of it.

Accessibility

Very much related to the content, how can we bake accessibility and design inclusively, ensuring the broadest possible audience for what we’re producing? Is there visual, UX or code-based guidance we could put in place? Is there guidance we can document to ensure accessibility is never an afterthought? In a previous article, I talked in greater depth about how you can make your design system more accessible.

SEO

It can be hard to predict all of the use cases of a component you create, but one audience we can easily neglect is search engines. Very often, SEO basics should be covered if you have good, well-described content and considered accessibility. A well-structured HTML document helps as primarily search engines attempt to infer what you’re talking about and its context.

For some components, there may be schema.org code we can add to describe better either whole articles, chunks or data or assets. There’s a lot you could annotate! Google has handy ‘structured data’ tools to help you see if it’s working as expected.

As with accessibility, there’s likely some best practice guidance that makes sense to document, so any gains or learnings aren’t lost as the design system evolves.

Performance

These days, performance isn’t just essential for our users to have a great experience of our websites, but it’s also become a factor in how Google ranks our sites through ‘page experience metrics’.

When looking at the components we’re creating; there are a few suggestions around performance that we could consider:

• Media assets
• Are we using large images? Do we need to?
• Can they be served in a modern format such as WebP or AVIF?
• Are they adequately compressed?
• Using either the <picture> element or the srcset attribute on the <img> tag, are we serving the right sized asset for the current viewport size?
• Are we serving them from a CDN?
• If we’re serving video, are we using a 3rd party solution? Can we trigger this from a user interaction rather than loading immediately?
• Can we lazy load (related to the section below about states)?
• Javascript/behaviour
• Is this behaviour necessary?
• If we’re using 3rd party code, is that the most performant method or worth writing our own?
• Are we serving only the code that’s needed to run?
• Are we bundling the code effectively so there are fewer assets for the browser to download?
• How much should this component be responsible for – is it a layout or app concern?
• Can we reliably measure the performance of this specific component? Is some kind of benchmarking possible?
• Do we have checks like Lighthouse running on our builds?

Tracking

Easy to miss but potentially important as part of the whole website or app is whether there is anything about this component that should be specifically tracked. If you have some kind of interaction, this is something that Google Analytics and similar tools will be able to store for you. It might be that any custom labels for that event tracking might need to be recorded as part of a whole layout rather than an instance of a component that has been interacted with. You might want to know if a specific accordion (i.e. an FAQ about design systems) has been expanded rather than a random accordion somewhere on the website.

States

As we’re thinking about interactions, there may be a number of states we could think about for a component. Not all will apply in every instance, and you might come across more when thinking about the specific component you’re working on but as a starting point

Loading: When this specific component loads, is there anything it should do? Should it have a spinner or skeleton state (which may be handy if pulling data from somewhere)? Should it have a transition?

Unloading: Unlikely, but in the reverse of loading, is there something it should do when the component is unloaded, so removed from the layout?

Quantity: Is it possible we could have no data? If we have more than the optimal number of items, how are we best dealing with that?

Interaction states: Which common states might apply to your component? Have you covered all bases? These might include

• Disabled/inactive
• Focus (may have different effects based on keyboard or mouse focus if appropriate)
• Hover
• Active/triggered

View states:

• Should the component do something when it’s not in the viewport compared to what it’s visible to the user? Using intersection observer, we can easily do this these days. This might relate to the point around performance mentioned earlier but also as a trigger for animation.
• Viewport events such as resize, orientation change or even referring to media queries in JavaScript might have a bearing on what you create, depending on the nature of the component you’re making. In the near future, container queries might change how you think about the evolution of a component?

There may also be instances where the behaviour of one component should affect another if it’s present, which is where things can get complicated!

Motion and animations

Often seen as a ‘nice to have’, you may have a component for which this is an integral part of its purpose. Aside from describing and implementing it, we also need to consider a state where the user has expressed a preference not to experience it, which we can know through the prefers-reduced-motion API.

The movement you want may have some kind of trigger to start it, which links into the earlier sections around ‘state’. Doing nothing, this would be on load and unload, but you may want it only to trigger when the component is in-view or after some kind of user interaction. The states and motion may be linked, but it’s essential to consider this as a lens of its own. What is the movement communicating? What does it add to our interface? What’s the most performant way to implement it (which relates to the points around performance and accessibility)?

Research and Testing

I’ve largely covered this in a previous article about how we embed confidence in our design system but even from our visual design, we can consider what the user might do, what error states might occur and start to almost map out a bit of a test plan – some scenarios the user might experience that we need to check work at all stages of our workflow.

What is interesting is gathering any user research you can get around how users experience a given component in various contexts or layouts. It’s something that’s often overlooked but great to see when research insights are included in documentation too. A great example I saw of this was the call-outs for research on Bulb’s Solar design system. Perhaps some research led to the component being designed in the first place that could be captured and added to docs before the component is live in the system?

It’s all about perspective

In any given specialism or discipline, we’d have a natural bias regarding how we might look upon a component. This notion of lenses is a way to challenge ourselves to look at an object we’re creating from many points of view. We can recognise where other people can help with some if they’re beyond our area of expertise. This idea can also help to identify gaps in experience or knowledge within a team and prevents anything from being left as an afterthought or not being implemented because of time constraints. As with anything, a process like this can speed up over time, become part of your workflow, and may help you create better components!

You could take this as a formal checklist as part of your review or use it as a prompt to encourage different points of view. It could help from kick-offs, design crit to a pre-release definition of done or team review. You might find it a useful tool as part of your workflow in some way. If you think of any other lenses you might add – let us know!

—

Is there anything we’ve missed that you think should be an additional lens to look at our components through? Let us know if you try something like this as part of your workflow over Twitter or in our Slack community zheroes