Why dysfunction happens and how to avoid it
🗓 24th January, 2020
If digital products were like lego castles, you could think of components as the individual, unique lego blocks used to build the castles.
In most companies, it's typical for component libraries to be a shared responsibility and whilst multiple inputs ensures thorough outcomes, it inevitably brings alignment challenges.
The topic of component libraries is worthy of volumes, in this article I merely scratch the surface in exposing typical challenges and starting points for solving them. Think of this as your sigh of relief as you read and confirm that you're not alone having component wars.
Designers aren’t using the component library
You’ve got a component library in place, mature or not, however the team isn’t using it.
Why it happens
- Finding components is tedious and slowing people’s workflow.
- The team is frequently unaware of updates made to the library so they create components rather than use what was published.
- The library is incomplete, so people can’t do much with it.
- The library’s ongoing progress keeps breaking projects so people circumvent the library.
- Many components aren’t adaptable across platforms and breakpoints so people need to build their own blocks.
- People aren’t happy with what’s in the library and have ideas of their own.
What to try
Ask the team why they’re not using the library and you’ll be surprised with what you learn. Often times people will bypass a library because it’s more practical to do so if using it is a struggle. The issue with this behaviour however is that it doesn’t move the team closer to a solution, instead, it traps them in inefficient cycles, starting from scratch each time.
Are you sure components are findable?
When finding components starts slowing people’s workflow, take a close look at your library’s structure and how you name and nest components.
Talk with the team, sometimes peoples’ jargon will differ for the same component. Sometimes there are different expectations around where a component should live. It’s these different expectations that may trigger team dysfunction as people begin to feel they’re wasting time searching for lego blocks rather than assembling the castle.
Are you keeping each other updated on the library’s progress?
If the team is frequently unaware of updates, or need context before adopting changes, you may need to double down on communication.
While it’s true that software may notify people with the latest, designers rarely ever take anything onboard without a series of questions and feedback first. Having some face time with the team may be the most practical way to have needed discussions and align. At the very least, all input will be gathered at a go and people will receive all the context needed.
Are team members being heard when they make suggestions?
If people are frequently building their own blocks as opposed to using what’s available, it may be that their frustrations and suggestions aren’t being heard.
When people’s input is taken onboard they’re more likely to adopt the library — after all they’ll be using their own work. With this being said, sometimes peoples’ interests get in the way of the greater good as we’ll discuss later on.
Are the components usable?
If people cannot work with what’s in the library, could you blame them for circumventing it? Sometimes components are designed to work for one platform but don’t scale across the rest. Sometimes components fall apart when they’re resized and sometimes, it’s impossible to edit their contents without breaking them.
Try applying the same level of mindfulness around component usability as you do around the usability of customer facing goods. At the end of the day the team is the customer as far as using the library goes.
New, unnecessary components keep being created
Your team agrees the library should be a shared responsibility and encourages participation. Then again, this is why there are unnecessary variations of the same thing circulating, some of which get shipped and create product inconsistency.
This issue has a lot to do with workflow and communication, sometimes it could also be ego.
Why it happens
- There’s no vetting process to ensure that only what’s critical gets shipped.
- The team isn’t striking a balance between ideal and practical, therefore thousands of ‘ideal’ components are manufactured to solve the same problem.
- The team is focused on the lego blocks rather than the vision of the finished castle.
- The team isn’t aware of the ripple effect of creating more components and produce them like hot cakes.
- People have strong opinions on how some components should look and keep persisting.
- The team is creating new components when what’s really needed is fixing what exists.
What to try
It’s worth communicating that component libraries are in part, meant to increase a team’s efficiency and that creating unnecessary components does the exact opposite, it increases overhead and confusion. It’s also poor time management to spend too much time on the lego blocks in isolation, only to find out that they weren’t what the castle needed.
Making a library a shared responsibility will only work with some rules; as you may have guessed, the short answer to this problem is to formalise a process and refine it over time.
Have you agreed on a process for building new components?
Without a formalised process for new components to pass through, it’s hard to point fingers at people. Make it a point to discuss new components at design meetings or in design channels to prevent bloat early.
Discuss whether there is a real need or if the library already contains components that may deliver the same results — the key word here is results. If there is a need, pass the component through a checklist the team agrees on in order to ensure that the outcome is extensible enough to work as intended across contexts.
Are you weighing ideal against practical?
If the team is often caught up in dilemmas between what’s ideal and practical, start having discussions around what the tradeoffs look like for pursuing the practical route: are they design, business or customer experience trade offs?
Sometimes designers can get married to ideas they think are ideal and insist that anything else would be a compromise. However, if the ideal brings extra work for a one time use component with no bottom line benefits, then who’s that ideal for?
Are you keeping the castle in mind when building the lego blocks?
When it feels like the team is spending way too much time exploring the lego blocks, pull the focus back to how things would work in the castle.
Sometimes designers get lost in details only to find that their explorations were irrelevant after returning to the castle. Apart from removing designers from the larger context, this kind of exploration is a time robber that may offer meager returns.
Are you considering the ripple effect of adding to the library?
People may think that adding another component to the library is no big deal. In truth each addition poses challenges such as a growing front-end rule set, increased chances of product inconsistencies, more library maintenance and communication overhead. Be mindful before publishing anything as you’ll either relief people, or potentially pull a seagull manoeuvre on them.
Get into the habit of roping developers in early as they too will be effected by new additions. Developers understand the front end best and are aware of the ins and outs, they’re the ones implementing it.
Designers regularly claim that the components don’t cut it for ‘them’
This issue may be twofold. In the case of a library which isn't mature, one may definitely find herself in situations were the available components aren't ideal as they haven't been pressure tested.
However in some instances, designers tend to create new components to address nuances or because they favour another approach. In other words it could be ego. Ego aside for a minute, there are some valid reasons a library may not be helping designers solve some of their problems.
Why it happens
- The library mimics a standard system (perhaps downloaded) but doesn’t cater for the product’s specific needs.
- The components in the library aren’t the outcome of real use cases the team has addressed.
- The components in the library are overly nuanced making them hard to reuse.
- The components were built around a single or few parts of the product and aren’t cognizant of the entire customer journey.
- The product has outgrown the library which was built a while back.
What to try
Before building a case around why the library isn’t cutting it for ‘you’, it’s worth remembering that you’re likely working on a portion of the product and that bloating the entire library for this portion may be unnecessary.
Assuming you’re a team player and still can’t work with what’s on the menu, you may have to make some calls. Whatever the case, it’s worth preventing the team from running into similar issues moving forward.
Are the components in the library the result of customer facing projects?
If components frequently feel like they aren’t the outcome of real cases, you may need to look into when they’re being designed.
Sometimes components are designed in isolation of a real task and added to the library to conveniently be found in the future as their need arises. However, that’s like saving up money all your life to become a monk — you cannot always foresee the future.
It’s more practical to do the work when it’s needed, this way the context will be clear and the outcome will likely be more extensible.
Are you designing components you’d likely reuse?
It may be the case that your product merits some speciality components. This being said, when everything becomes speciality and barely anything’s reusable, rest assured bad calls are being made.
When this is the challenge, try find out why the team isn’t keeping reusability in mind when building. Challenge speciality components that have simpler solutions which also make them reusable.
Remember to avoid causing the same issue for your team by designing components that are bound to be useful and pay off over and over.
Does the library reflect the product’s needs of today?
It’s all good to keep a library lean, push for reuse and keep productivity at an all time high. Sometimes, products move on and leave us behind, if we don’t keep up with them we may find ourselves using old tools for new problems.
Keep abreast of the product’s needs and reflect them in the library to avoid forcing team dysfunction in was already discussed. There’s no special rule of thumb here except to avoid using new product needs as an excuse to create new blocks unnecessarily.
Closing thoughts
I do realise I’ve opened pandora’s box. You’re likely thinking of cases you’ve faced that I haven’t had the ink to cover here. This piece can go on and on, however less value would be extracted from it as differing problems may have similar solutions in truth.
In concluding, there are a few points I wish to drive. Component libraries should increase design to market efficiency, team alignment and product consistency. Often times, these worthy goal posts are missed due to misinformation, unawareness, frustration or perhaps ego — the dysfunction stems from people challenges.
The next time you’re about to explode as you witness someone creating a button you’ve already created, keep cool and consider whether your team is addressing the people challenges around component libraries.
Here’s a handy list for you:
- Add a little process to increase transparency and comprehensiveness
- Find time to communicate the library’s progress frequently
- Base your component library on real projects
- Be sensitive to peoples’ needs
- Practical wins over extensive
- Keep the library usable for the team
- Build highly reusable components
- Never lose sight of the finished castle
- Keep up with your product’s needs
- Consider the ripple effect of adding stuff to the library
Good luck.
