组件库的组件尺寸_组件库方面的人员挑战

组件库的组件尺寸

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)

1. Finding components is tedious and slowing people’s workflow.
   查找组件很繁琐，并且减慢了人们的工作流程。
2. The team is frequently unaware of updates made to the library so they create components rather than use what was published.
   团队经常不知道对库所做的更新，因此他们创建组件而不是使用发布的组件。
3. The library is incomplete, so people can’t do much with it.
   该库是不完整的，因此人们无法做很多事情。
4. The library’s ongoing progress keeps breaking projects so people circumvent the library.
   图书馆的持续进展不断导致项目中断，因此人们绕开了图书馆。
5. Many components aren’t adaptable across platforms and breakpoints so people need to build their own blocks.
   许多组件无法跨平台和断点适应，因此人们需要构建自己的模块。
6. 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)

1. There’s no vetting process to ensure that only what’s critical gets shipped.
   没有审核流程可以确保仅将重要的内容发送出去。
2. The team isn’t striking a balance between ideal and practical, therefore thousands of ‘ideal’ components are manufactured to solve the same problem.
   团队并未在理想与实用之间取得平衡，因此制造了数千个“理想”组件来解决同一问题。

3. The team is focused on the lego blocks rather than the vision of the finished castle.

   该团队专注于乐高积木，而不是成品城堡的视野。

4. The team isn’t aware of the ripple effect of creating more components and produce them like hot cakes.
   团队并不了解创建更多组件并将它们像热蛋糕一样产生的连锁React。
5. People have strong opinions on how some components should look and keep persisting.
   人们对某些组件的外观和保持持久性有强烈的意见。
6. 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.

讨论是否确实有需要，或者库是否已经包含可以提供相同结果的组件-此处的关键词是results 。 如果有需要，请通过团队同意的清单来传递组件，以确保结果具有足够的可扩展性，可以跨上下文使用。

您权衡实用与理想吗？ (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.

有时候，设计师迷失了细节，只是发现回到城堡后，他们的探索是无关紧要的。 除了将设计者从更大的范围中删除之外，这种探索是一种时间浪费，可能会带来微薄的回报。

您是否正在考虑添加到库中的连锁React？ (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)

1. The library mimics a standard system (perhaps downloaded) but doesn’t cater for the product’s specific needs.
   该库模仿一个标准系统(也许已下载)，但不能满足产品的特定需求。
2. The components in the library aren’t the outcome of real use cases the team has addressed.
   库中的组件不是团队已解决的实际用例的结果。
3. The components in the library are overly nuanced making them hard to reuse.
   库中的组件过于细微，难以重用。
4. The components were built around a single or few parts of the product and aren’t cognizant of the entire customer journey.
   这些组件是围绕产品的单个或几个部分构建的，并不了解整个客户旅程。
5. 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:

下次当您看到有人创建已经创建的按钮时爆炸时，请保持冷静，并考虑您的团队是否正在解决围绕组件库的人员挑战。 这是给您的方便清单：

1. Add a little process to increase transparency and comprehensiveness
   添加一些过程以提高透明度和全面性
2. Find time to communicate the library’s progress frequently
   抽出时间经常交流图书馆的进展
3. Base your component library on real projects
   将组件库基于实际项目
4. Be sensitive to peoples’ needs
   对人民的需求保持敏感
5. Practical wins over extensive
   实际胜过广泛
6. Keep the library usable for the team
   保持图书馆对团队的可用性
7. Build highly reusable components
   构建高度可重用的组件

8. Never lose sight of the finished castle

   永远不要忘记完成的城堡

9. Keep up with your product’s needs
   跟上您产品的需求
10. Consider the ripple effect of adding stuff to the library
    考虑向库中添加内容的连锁React

Good luck.

祝好运。

翻译自: https://uxdesign.cc/people-challenges-around-component-libraries-960e3302efb0

组件库的组件尺寸