どういうときはUIライブラリに頼り、どういうときは頼らない方が良いのか

この記事の概要

世の中には色々なUIライブラリがあります。
有名なものだとMUIやChakra UIなど。

便利な場面もありますが、ライブラリだからこその大変な場面もあります。

どういうときはUIライブラリに頼り、どういうときは頼らない方が良いのか、という観点を記事にしました。

裏付けされたデータや理論があるわけではなく、自分の経験をもとにした内容です。1つの観点として参考にするくらいの気持ちで読んでください。

ここでいうUIライブラリは「見た目があるライブラリ」です。つまりヘッドレスUI系は除いています。あれらを含めると条件がまた複雑になってくるので、この記事では話を簡単にするため、見た目がセットのライブラリだけに言及しています。

頼った方が良い場面

デザイナーが少なくてエンジニアが多いチーム

よくある制作フローはデザイナーが見た目を作る→エンジニアが実装するです。
このとき、エンジニアがたくさんいると自然と開発ラインが増えます。
開発ラインが増えていくと、いずれデザイナーが見た目を作るのが追いつかなくなって、ボトルネックになります。

このとき、デザイナーが1からデザインデータを作っているとデザイナー人数 * 3くらいの開発ライン数で限界を迎えることが多いように思います¹。

しかしUIライブラリを使えば細かな部分の制作時間を短縮できるので、開発ラインの上限が高まります。

社内用の業務効率化ツールなどを作る場面

言い方は悪いかもしれませんが、社内用のツールの場合限界効用の逓減が早いです。

ざっくりと「〇〇を△△できる」時点で大抵の要求はクリアされていて、細かな使い勝手を上げてもリターンが増加しづらいです。

そういった場合デザインデータとしては、既に存在するコンポーネントをざざっと並べて終わりでも良いと言えるでしょう。
となると、UIライブラリは頼もしい存在です。

もちろん使い勝手が良いに越したことはありません。
しかし、どこの組織でも人員・時間ともに有限で、シビアに達成すべき目標があるはずですから、こういう判断になりがちかと思います。

UIデザインの下書き代わりの用途

ライブラリの作者からしたら悲しい使い方かもしれませんが……。

いわゆるワイヤーフレームの状態から、一気に完成形のデザインデータを仕上げるのはなかなか大変です。
中間地点として、一旦UIライブラリのデータ（例えばFigmaコミュニティにあるデータ）を使って下書きを作る、というのはそれなりに便利です。

ライブラリを土台として見ると、自作しないといけない箇所が明確になったり、意外とライブラリだけで済むことが分かったり、自分達の立ち位置が分かりやすくなると思います。

頼らない方が良い場面

「ブランドに投資する」などが口にされる組織

ここでは、何をもってブランディングとするのか？というアカデミックな話はしません。
しかし確実に言えるのは、ブランド作りは生半可な気持ちでは実現できないということです。

UIライブラリを使うと良いブランドができないわけでもありません。
しかし目の前にあるプロダクトに対して、微に入り細を穿つまで考えていると、大抵自然と既存のライブラリでは実現できないことが出てきます。

その際に頑張ってライブラリをカスタムするよりは、最初から自分達で作った方が良いかと思います。

他の話もそうですが、この話は特に「そういう傾向が（私の観測範囲では）よく見られる」というだけです。「〇〇をしている or していないから、良いブランド or 悪いブランドである」のような単純過ぎる話にするつもりはありません。

一般的なUIから逸脱することが分かっている場面

UI作成において、一般的なものから逸脱すること自体が良くないのですが、ときには必要な場面もあります。

昔から続く商慣習に対応するためのUIや、社内独自のKPI向上のためのトリッキーなUIなど、色々な背景が考えられます。
理想像やべき論だけで言えばそんなしがらみは突っぱねて、一般的なUIにした方が良いのでしょうが……。

予め作るものが一般から逸脱していると分かっている場合、UIライブラリには頼らずに自作した方が良いと思います。

公式ドキュメントを読むのが苦手なデザイナーが多いチーム

大抵のライブラリは、カスタマイズするための仕組みが提供されています。
しかしすべてをカスタムできるわけもなく、仕組みが用意されている箇所はカスタムしやすく、カスタムを想定されていない箇所はできない or ハックめいたことをするしかないです。
当たり前の話ですね。

このとき、デザイナーが公式ドキュメントを読むのが苦手だとかなり大変になります。
公式からFigmaライブラリなどとして提供されているデザインデータがあったとして、あくまで見た目のデータなのでどうとでも触れてしまいます。
そして実装のターンになって「このカスタマイズを実現するのは無理かもしれない」と発覚し、修正へ……。

かなり時間がかかりますし、多くの関係者がモヤっとするパターンです。

能力の問題というよりは、ライブラリのドキュメントを見ながらそれに沿ってUIを構築するというフローに慣れているかの問題かと思います。

最後に

頼った方が良い場面、そうでもない場面、3つずつ挙げました。
一元的に使うべき使わないべきがあるわけではなく、組織や文化次第かと思います（何においてもそうと言えばそうなのですが）。

この記事で書いたような判断軸がお役に立てば幸いです。

1. もちろん線形に増えるわけではないですが、単純化するならこんな感じ、というイメージです。 ↩