Story Connectを使って思ったこと
はじめに
先日、Figmaのstorybook plugin betaが発表されました。
この通りに、discordからメンションすると、すぐにDMが来て数ラリーで権限付与してくれたので、その後セットアップして遊んだ後の感想です。まだ運用はしてません。
セットアップ
- Chromaticをセットアップ
- Figmaプラグインをinstall
- 対象のコンポーネントにChromaticにhostingされた対象コンポーネントのリンクを付与する
これだけで、このようにFigmaのコンポーネントの横で対象のコンポーネントを操作することができるようになりました。
個人的に、storybookのVRTはregsuitをいつも使っていたので、この設定から始めましたが、Discordでの返信待ちのロスタイムを除けば、ここまで全体を通して30minもかかってないと思います。
デメリットに感じたこと
前述の通り、regsuitを使用してVRTを組んでいたので運用するのであれば役割が重複することと、figmaに表示されるものの最新性を保つために移行する必要があること。
運用が回れば、今までgithub actionで済んでいたが、Chromaticに対してのmonthly課金が必要そうであること。
(良いツール起点で自然に課金に促す感じの体験は良いなと思って好きです。)
メリットに感じたこと
一つ目には、アナウンスにも書いてありましたが、実装とデザインでのコンポーネントの乖離が縮まることが大きいです。
デザインシステムとして、コンポーネントライブラリを運用していますが、Figmaのコンポーネントmasterファイルに対して、機会や余裕がなくて実装できていないコンポーネントがいくつかあります。それらが入り混じっていることによって、デザイナー/エンジニア間(またはPMもFigmaを見るのでPM)での実装コストの認識や体験の認識の齟齬が生まれています。
このPluginでLinkされているかどうか、を判断材料とすれば一部解決できるかもしれません。
また、デザインシステムのコンポーネントを実装した後に、そのコンポーネントをPR単位でデプロイしているstorybookに載せてデザイナーにレビューしてもらうようにしていますが、
デザイナー視点で言えば、普段基本的に使わないGithubを使い、storybookという機能の使い方を知って使わないといけないので認知負荷が高いです。
それによって、時にレビューがされない(時間がかかる)、見るべきケースを見逃すなどが起きています。普段使うtool内で完結するのでこの負荷と問題も一部解決できそうです。
二つ目に、実装のpropsとfigma上のVariantが結びついている点です。
最初にstorybookをリンクした時に、このようになりました。
これは、実装のpropsではvariant="primary"をPrimary Buttonとしていたのに対して、
Figma上では、type="Primary"をPrimary Buttonとしていたことに起因します。
実装とデザインでコンポーネントの使い方や組み方を統一して、ブレのないUIを継続的にデリバリーするために意思疎通する時間を取って作っていたつもりですが、やはりお互いに使うツールが違うことによって、お互いのサイドでやりやすいように設定してしまっている部分がありました。
細かいですが、この単位まで同じ組み方・使い方をすることのメリットは専門職間のコミュニケーション上大きいと個人的には思っています。
最後に
デザインツールと実装のコンポーネントの乖離を極限まで減らすことによって成果物のクオリティとデリバリー速度を上げるための取り組みとして、UXPin MergeやFramerがあります。
これらも実践経験があるのですが、デザインツールとしての使いやすさなどから、Figmaを完全に抜け出せず、双方運用することで負荷がどうしても高くなり運用フローの構築・継続が難しい面も正直あります。
それらのリッチなツールからしたら、可能にしてくれることは明らかに劣りはしますが、
そこと比べる視点での導入・金額コストは圧倒的に低いので、DesignOpsの一手としてかなり期待できるなと思いました。
Discussion