Chakra UI導入時にデザイナーがすべきこと
こんにちは、akippaの横山です。
今回はUIコンポーネントライブラリの1つであるChakra UIを導入した話をデザイナー視点でしようと思います。
このようなUIコンポーネントライブラリは、既存で豊富なコンポーネントがすでに用意されており、デザイン作成をサポートしてくれるという点からエンジニアさん視点で語られる傾向が多いのかな？と思います。
デザイナーとしてはこういったライブラリをうまく活用しサービス全体で一貫性のあるデザインを提供していくことができるといった点に着目すべきなのかなと思います。
まずは導入編ということで、UIコンポーネントライブラリ初回導入時にデザイナーが検討すべきこと・設計すべきものなどをつらつらと書いていこうかなと思います。
背景
導入に向けての方針
デザイナーチームで導入の是非を議論した際の感想はこんな感じ。
🙆メリット
・サービス全体について同じコンポーネントやトンマナを採用することができるのがいい！
・決まったコンポーネントがあるので、コーディングコストが抑えられ機能追加のスピードが上がりそう！
🙅デメリット
・オリジナルコンポーネント作ったらコーディング担当者に嫌な顔されるんとちゃうか・・・><
・規定のコンポーネントやレイアウトを利用する工数の方が少ないだろうから、そこに遠慮して表現の自由がなくなるのでは・・？
・一定のルールに従ってデザインデータ作る必要が出そうなので、作る時のお作法がヘヴィーになりそう
真剣に向き合うからこそ、心配事はいっぱい上がってきます。
それらを出し終えたあとは、そんな不安を解決し前向きに導入できるかをみんなで検討し、下記の方針でトライしていくことに決めました。
🧭方針「困難は分割せよ、そしてスモールに検証せよ」
いきなり全てに導入するのは多大な時間がかかるしリスクもあります。規模と影響範囲の二軸からチャンレンジしやすいものを選定し、検証を重ねながら少しずつ導入してみることにしました。
・まずは単発で試行できるLPからやってみる
・その次は社内向け管理サイトに展開してみる
・最後にユーザー向けのサイトに展開する
デザイン業務は何が変わる？
Chakra UIの導入にあたり、まずはデザインデータの制作規定を見直す必要があります。Chakra UIのことを知った上で、エンジニアさんに伝わりやすいデータを作る必要があるからです。
従来の制作過程に取り入れるべき項目は主にこんな感じ。
・Chaku UIのコンポーネントを、制作データに落とし込む必要がある
・トークンやスタイルを定義し、制作データに落とし込む必要がある
次項からはこれらをFigmaでどう管理していくかを書きます。
やったこと
【Chakra UI用のデザインライブラリを用意する】
いくらスモールに導入を始めたいとはいえ、ページを作成する以上最低限のデザインライブラリを用意する必要があります。
(1)設計方針
Chakra UIはWebを横断するデザインライブラリとなることを想定していますので、Appと共通で定義すべき値については、akippa全体のデザインシステムから読み込めるようにこんな感じで設計します。
デザインライブラリの構築に際し、役に立ったのがこちらのChakra UI Figma Kit。
このKitをデザインライブラリとして使用するためにakippa流にカスタマイズして使用することにしました。
全てのコンポーネントやバリアントが網羅されている訳ではないようなので、公式を確認しもって作業を行います。
いずれakippaのwebサービスを横断する立派なデザインライブラリに育ってくれることを夢見つつ、まずは今回行った最低限のカスタマイズをご紹介しようと思います。
(2)カスタマイズ内容
カラー
デフォルト値で豊富なカラーパレットが用意されていたので、近偽色についてakippaカラーで上書きしました。
テキストスタイル
従来の実装値であるHiragino Kaku Gothic ProNを当てるかHiragino Sansを当てるかで迷いましたが、Figmaのスタイル値としてはフォントウェイトの豊富なHiragino Sansを指定しました。
[おまけ]アイコン
アイコンについてはデフォルトのものを上書きせずに、
akippaアイコンを専用のリポジトリにて管理することにしました。
今後はFigmaのアイコンセットとリポジトリ内を同期させる運用を想定しており、akippa共通のデザインシステム内で定義しました。
[おまけ]コンポーネント
コンポーネントは、今回は特に定義を加えずデフォルト値のまま利用しました。
というのも今回試金石として制作するのはLPなので、コンポーネントレベルで共通利用するようなものがなかったためです。
【制作ページへの落とし込み】
前項で定義したデザインライブラリを実際の制作ページへ落とし込みます。
(1)基本ルール
原則1：「実装時のコンポーネント名」= 「Figmaのレイヤー名」
実装の際にどのコンポーネントを使えばいいかがエンジニアさんに伝わるように、Figmaのレイヤー名にChakra UIのコンポーネント名を指定
原則2：「実装時のスタイル(カラー/フォント) 」= 「Figmaのトークン」
基本的に前項で定義したカラー/フォントを当ててデザインを作成
例外的なそのページ固有のデザインを表現したい際は、トークンを当てない
原則3：実装時の参照値は「プロパティ値」を優先する
「プロパティ値」 > 「レイアウト値」/「スタイル値」/「カラー値」 等、といった優先度で参照する
理由は後述
(2)つまずいた点
Figmaではインスタンスを切り離しても、「プロパティ値」が残ってしまう「プロパティ値」は、コンポーネントにバリアントを指定した際に付与され、Figmaで設定したバリアント値とChakra UIのバリアント値がリンクしていることでエンジニアとのコミュニケーションコストを削減することができます。
しかし、ちょっとしたデザインカスタマイズの全てをバリアント化しプロパティ値で表現することは意図するところではないため、そのような場合は、従来通り「レイアウト値」 / 「スタイル値」 / 「カラー値」 等を参照してもらうことにしました。
ただし、コンポーネントのインスタンスを切り離しただけでは「プロパティ値」は消えてくれません。
インスタンスを切り離すことで、デザイン上は独立した表現を与えることができるので気付かなかったのですが、「開発モード」で閲覧してみるとこんな感じで「プロパティ値」が残ってしまっているのです。
「プロパティ値」が残っていると、エンジニアに混乱を与えてしまうため、「開発モード」内 →「切り離しの履歴を削除」を行いプロパティ値を消す運用を行うことにしました。
導入後
そんなこんなを経てChakra UI導入したLPはこちら。
導入への懸念事項への感想
・「表現の自由度が下がるのではないか」疑惑
そもそもLPの特性上共通化の必要がないので、カスタマイズを否定する理由もなく今の段階では測れないというのが回答になりそうです。サービスに展開していき共通化が進んでからが本番なのかなという所感です。
そして自由度が下がらないようなコンポーネント設計が肝となってくると感じています。
・デザインデータの作成工数が大幅に増加するのではないか
レイヤー名指定とメモ記載でのコミュニケーションは、個人的には許容範囲かなという所感です。
コンポーネントの共通化が進むとより真価を発揮してくれる運用だと思います。
最後に
以上、Chakra UI導入時にデザイナーがすべき事でした。
今回は導入ということで、主にFigmaと実装を結びつけるという点に注力しました。次は真骨頂？でもある展開や共通化を整備したいので、機会があればそんな記事が書けたらいいなと思っています。
この記事が気に入ったらサポートをしてみませんか？