string(4) "blog"

CONTENTS

2020.8.14

デザインシステムの事例紹介:Banksalad Product Language

written by ロイ
Banksalad Product Languageの画像

デザインシステムの面白い実装例があったので紹介させていただきます。

紹介する事例は韓国で大きく成功しているBanksaladと言う「パーソナル金融管理サービス」の実装チームが構築したBanksalad Product Languageです。彼らはこれを「デザインシステムを更に拡張したもの」と紹介しております。

現在、概要とiOS版の説明が公開されており、今後別のプラットフォームでの実装やデザイナーの視点での紹介も公開される予定です。ここではBankslald Product Languageの初回公開記事を簡単に要約しております。元の記事は以下のリンクを参照してください。

banksaladサービスサイト

Banksalad Product Language紹介

上記のサイトから実際の操作画面を動画で見ることができます。内容を理解するに役立つかと思います。

解決すべき課題

  • デザイナーとエンジニア、そして異なるプラットフォーム(例:iOS、Android、Web)のエンジニア同士のコミュニケーションに問題があった。
    • 例:
      • 顧客(またはプロダクトオーナー):ここでダイアログを出してほしい。
      • デザイナー:あ、ポップアップね?
      • エンジニア:それ、アラートのこと?
  • デザインの変更にし易さと実装の変更のし易さは異なる。しかし、お互いにその理由が分からない。
    • 例:
      • デザイナー:ここ修正お願いします。
      • エンジニア:いや、それは結構大変。
      • デザイナー:Figmaではシンボル修正だけなのですごく簡単なのに、なぜ大変なの?
      • iOSエンジニア:それを変えるとナビゲーションフローが全部変わるのよ。すると他のサイドエフェクトも発生するかもしれない。
      • Androidエンジニア:うちではアプリ全体に影響が出るよ。実装の都合も知らずに簡単に言わないでほしい。
  • これらの問題を解消し、企画からデザイン、実装への適用のサイクルをより短くする方法が必要だった。

やったこと

現状の課題の把握・明確化

  • 作成済みの一部の画面を対象に、デザインファイルとiOS、Android、ウェブの実装コードを持ち寄って比較する。
  • デザインと実装の各ファイルの類似点と相違を比較することで課題が明確になった。
  • なお、FigmaとSwiftUIが構造上類似であることが分かった。

エンジニアがFigmaを使ってみる

  • デザイナーのFigmaファイルを複製してエンジニアが実際にいじってみた。
  • Zeplinなど、デザイン指示書の代わりになるツールでは最終結果だけが見えるけど、Figmaのファイルを直接いじってみることによってデザイン指示書に書かれてないデザインの意図が見えてきた。
  • またFigmaファイルと実装コードの類似性と差が具体的に見えてきた。
    • 例:
      • FigmaのコンポーネントはiOSのクラスとほぼ似ているね!
      • FigmaのAutolayoutはiOSのUIStackView、AndroidのLinearLayoutと結構似ているね!
  • これらの類似性が見えてきて、デザイナーとエンジニアのコミュニケーションが捗るようになった。

作るべきものが見えてきた

  • デザインと実装の抽象化単位を一致させる(iOSの場合)
    • デザイナーがFigmaでコンポーネントを作ると、それと1:1にマッチングする実装のクラスを作成するようにした。
    • デザインファイルで一つの数字を変えると、実装コードでも一つの数字の変更で同様の変更が適用できるようにした。
  • 過度な抽象化を避ける
    • 複数のUIコンポーネントにある共通部分を洗い出して抽象クラスを作りたい欲望は抑える。つまり、実装だけの抽象化によるデザインファイルとの乖離を避ける。これを誤るととデザインの変更に迅速に対応できない。
    • そのために、あえてDRYの原則を違反することでUIコンポーネント間の依存関係をなくした。

適用してみた

  • SwiftUIを活用し、デザインファイルの階層構造とコードの階層構造を合わせて実装した。
  • 作成したクラス群で独立したフレームワークを作成し、どのプロジェクトにもインポートして使用できるようにした。
  • 二つのサンプルアプリを作成。
    • Component_Example:UIコンポーネントの一覧を見せるアプリ
    • Integral_Example:実際のアプリのUIを実現したダミーアプリ(データは固定値を適用)
  • 新しいUIコンポーネントを作成したらComponent_Exampleに反映してレビュー、その後Integral_Exampleに反映して他のUIコンポーネントと問題なく作動するかを確認してからプロダクション版に反映する手順。

効果

  • 上記の手法で作成された新しいバージョンをリリース済み。
  • プロジェクトに属する異なる職種のメンバー間のコミュニケーションの円滑化ができた。
  • 開発生産性の向上:デザインファイルのコンポーネント名でXcodeで検索すると実装のクラスをすぐ見つけることができて、それを利用した実装ができる。
  • トラブル対応にも有効:実装したUIの確認時間が1/10に減ったので、プロダクション版で起きたトラブルの究明にも有効だった。
  • アクセサビリティーの改善にも有効だった。

結論

  • デザインガイドラインのことは言及されていないけど、これは立派なデザインシステム だと思います。多分、今後公開予定のデザイナーの視点での記事にはガイドラインの話もあるかもしれません。
  • iOSやウェブでの実装は想像がつきますが、個人的にはAndroidのことはあまり詳しくないのでそちらの実装がどうなったかは気になります。
  • Fixelでいつも言っている「デザインとエンジニアリングの境界をお互いに超えてコラボする」ことを実際に実践している企業が海外にもあると知って嬉しくなりました。
  • やはり今時の良いものは二つ以上の領域の知識をマージして改善した時にできてくると再度認識しました。
一覧に戻る
お問合わせ