設計システム:構成要素の構成原理

製品はすぐに大規模な組織内で進化し、企業は、高速に移動する必要があります一貫して構築し、新しい製品を提供し、既存のものを維持する必要があります.すべての一部として、採用されたソリューションは、一般的なパターン、色、タイポグラフィ、グリッドの原則に根ざしたデザインシステムを構築することです.
設計システムの具体化をコンポーネントに取り入れるチームの大きな課題は、どのように企業の速いペースを公開し、製品チームのコンポーネントに価値を提供し続けます.組織の開発者は、製品が進化するので、実装を越えたいと思っています.
この環境に大きな挑戦があり、デザイン側のデザインシステムチームは異なるアプローチをとることができ、特定のコンポーネントケースにデザインを停止させることができます.または両方の場合を満たします.それぞれのケースに欠点と利点があります、そして、各々のケースがあなたの組織の文脈でよりよく働くことができる方法を理解するのはあなた次第です.
一方、コンポーネントライブラリの開発者は異なるアプローチを取ることができます.

デザインシステムの場合のみを構成するコンポーネントを作成し、コンポーネントの使用を制限した場合に限定します.

製品デザインが定義されているものを越えて考えるとき、開発者が定義されたケースから逸脱するのを許して、高い柔軟性でコンポーネントをつくってください.

これらの結果は両側で悪いかもしれません、我々は彼らが彼ら自身の構成要素をつくらなければならないかもしれないか、彼らが柔軟な構成要素で仕事をたくさんしなければならないかもしれないので、開発者を挫折させることができます.そして、デザインのシステムがコンポーネント定義が固定されるので、デザイン・システムがデザイナーの創造的な心を妨げることができます.
これを修正し、扱うことは複雑です、しかし、我々は何をしなければなりませんか?当社ではLiferay ) 過去に、我々は設計システムに固定的なコンポーネントのアプローチを続けて、開発者が予想されるものをはるかに越えるのを許していません、300人以上のエンジニアといくつかの製品チームとの会社文脈では、これは悪い決定でした.

部品は設計システムに取り付けられていなかった

小さな柔軟性

デザイナーは実装を超えてコンポーネントを作り出した

結果として,我々のコンポーネントは,大きな使用量,高い構成複雑性,保守コストの増大,減価償却フェーズへの移行が非常に迅速であった.
我々はこれが悪い決定であるということを知っています、そして、我々は速く次の年にもう一つのアプローチに変わりました.我々は、コンポーネントライブラリの柔軟性と特殊なコンポーネント間のバランスを達成するアプローチを取った.
これを扱うことはより簡単に見えるかもしれません、しかし、我々はどう考えますか?我々のコンポーネントにハイブリッドアプローチに従って、我々はこれを多層APIライブラリと呼ぶ.

多層APIライブラリ

多層コンポーネントは、コンポーネントを提供する2つの方法があります.

低レベル-基本的なビルディングブロックは、カスタマイズし、高レベルのコンポーネントを作成できるように柔軟性を提供する.

特定のユースケースだけをカバーする傾向があります.

原則はかなり基本的ですが、いくつかの法律に従う必要が呼ばれる.

低レベル

低レベルコンポーネントは、ドロップダウンコンポーネントを構築する小さなブロックなどの構成に従います.

<ClayDropDown />
<ClayDropDown.Action />
<ClayDropDown.Item />
<ClayDropDown.ItemList />
<ClayDropDown.Search />

ハイレベル

高レベル成分は組成に従うかもしれませんが、多くのチームの間で共通の何かを持つより特定のコンポーネントであるかもしれません.

<ClayButtonWithIcon />
<ClayCardWithHorizontal />
<ClayCardWithNavigation />
<ClayDropDownWithItems />

高レベルのコンポーネントは低レベルで構築され、これはメンテナンスを減少させる可能性がありますが、利用可能なAPIの表面を増やす.
この利点は、より多くの採用とさまざまな味の多くのチームに達するハイブリッドアプローチを考え出すことができることです.
あなたは私たちの詳細を読むことができますcomposition approach in our documentation in our component library .
このアプローチの結果は、チームが異なるチームと異なる製品の製品の高い採用であり、チームがより速く提供するのを助けて、彼らはより幸せです.
これは、ユーザーレベルでの問題を解決するようですが、低レベルと高レベルのコンポーネントを区別、構築、および構成する方法についていくつかの議論に巻き込まれます.私は、理論や何かを概念的に調整し、時間をかけて物事を調整しようとすることから、私の考えをいくつか分離しました.

テイル理論

これをロングテール効果理論と混同しないでください.
テール理論は、2つのエンドまたはテールを持つロープのアノニムであり、ここでは、各端で低レベルと高レベルの両方のコンポーネントを配置します.彼らの間の距離は大きな痛みや大成功を引き起こす可能性がありますここですべてまたは何も!

極端は非常に痛いまたは非常に簡単にすることができます、特定のユースケースに接続された高いレベルが正しく定義に従っているチームに幸せをもたらすことができることを意味し、されていない人のために多くの痛みを作成することができます.

痛みの人にとって、痛みが大きくなるのは、低レベルがもう一方の端にあるので、低レベルから高いレベルに近いものが痛みを伴うことができます.

極端なハイレベルのケースは、彼らのケースが特定で、指定された外でどんな変化も許容しないので、ほとんど採用されないかもしれません.

彼らはより柔軟ですが、より多くの仕事を必要とするので、低いレベルは長い生命を持ちがちです.

よりスタックされたコンポーネントは、時間とともに変化する傾向があります、そして、彼らのライフサイクルはより短くなりがちです.

このグラフは仮定していますが、実際のデータはここでは使用されていませんが、コンポーネントライブラリでの作業に関する私の経験に基づいています.
いくつかの独特のもの:私たちは、短期的、長期的に低レベルの作業を非常によく、いくつかの変更を持っている可能性がありますが、それは私たちのための理想的なシナリオになりますが、途中で私たちが失うことができる1つのことは、努力と開発の経験は:これらの人々のためのポイントのキーは、ライブラリのコンポーネントを採用し、多くの努力なしに構築することです.
非常に特定のコンポーネントは多くの時間と時間の短い期間で多くを変更することができますし、いくつかの時点では、コンポーネントが膨らんだ理由を償却する必要がありますが発生する可能性がありますが、これは任意のコンポーネントで発生することができますが、我々はメンテナンスの問題と人々が使用を開始する前に物事を更新するために一定の戦いを持っているでしょう.これらのコンポーネントの寿命を延長し、メンテナンスを減らすことができます.
それで、私が部品の近くに、そして、より近いロープの中央にプッシュして、両側の間の距離が減少するならば、それは我々が側の痛みを減らすということを意味します.我々はロープの中央にそれらをプッシュする高レベルにいくつかの柔軟性を与えるたびに、経験が良くなると痛みが減少することができます.

我々は2つの側面に参加したくないが、我々は近くに取得したい、テールは極端であり、極端な価格を持って、我々はただそれを距離にしたいと我々は高レベルのコンポーネントの柔軟性を提供し、低レベルの柔軟性を減らす必要があります.
それを念頭に置いて、我々は以下のことができます.

高レベルのコンポーネントの寿命を高める.

時間をかけての変更

その結果、我々はより多くのユースケースをサポートします

人は幸せだ

最大の利益は、高レベルに低下するが、低レベルは、我々は自然の柔軟性の一部を奪うので、それはわずかに時間の経過とともにメンテナンスの量をわずかに増加させ、それ以上のメンテナンスも増加するために影響を受けていますが、これはバランスを作成する必要があるので、これは必要です、そして、2つの間の不均衡はびっくりしません.
この理論に固執するのは簡単だと思う.私たちが理解すると、コンポーネントがより柔軟性を必要とするとき、またはAPIを維持する必要があるときに、それが識別されるのは当然のことでしょう.
liferayコンポーネントライブラリはオープンソースです.

ギタブhttp://github.com/liferay/clay

サイトhttp://clayui.com

設計システムhttps://liferay.design/lexicon/

私は2 - 2年の間これに取り組んでいます、そして、私はあなたの考えと経験を聞くことがとても幸せです.
我々のGithubリポジトリは非常に興味深い考えとスピーチでいっぱいです.我々の問題とPRのものを調査してください🙂.
に従ってください+こんにちは!👋 !