Upgrade to Pro — share decks privately, control downloads, hide ads and more …

デザインシステムと画面パターン

fkady
August 25, 2022

 デザインシステムと画面パターン

fkady

August 25, 2022
Tweet

More Decks by fkady

Other Decks in Design

Transcript

  1. 8 Vision 注: 1. ERP:Enterprise Resources Planningの略称。日本語では、企業経営において点在するあらゆる情報を一箇所に集め、一元管理を行うシステムを指して一般的に「ERP」「ERPパッケージ」と呼ばれる ユーザーネットワーク 取引の効率化・活性化を実現 統合型クラウドERP(1)

    スマートで適切なアクションを実現 オープンプラットフォーム 多様なビジネス・経営ニーズに対応 1 2 3 だれもが自由に経営できる 統合型経営プラットフォーム 電子稟議
 プロジェクト
 マネジメント
 経費精算
 債権債務
 管理
 人事労務
 契約
 固定資産
 請求管理
 会計
 販売管理

  2. 9 統合型ERPに求められること • スモールビジネスに関わる様々な領域でプロダ クトを開発。それぞれの一貫性や統合型として の価値や体験を提供する • 新規プロダクトもスタートアップに勝るスピード感 を持って開発。プロダクト単体でもユーザーに 価値が届くように

    統合型クラウドERP スマートで適切なアクションを実現 電子稟議
 プロジェクト
 マネジメント
 経費精算
 債権債務
 管理
 人事労務
 契約
 固定資産
 請求管理
 会計
 販売管理

  3. 10 デザインシステムに求められること • どのプロダクトを使っていても「一貫した体 験」を提供できるよう支えたい • 新規プロダクトの立ち上げ、既存プロダクト の改善共にスピード感を持って開発できる 土台としたい デザインシステムとして

    「一貫した体験・プロダクトの開発生産性」の下支えをしたい • スモールビジネスに関わる様々な領域でプ ロダクトを開発。それぞれの一貫性や統合 型としての価値や体験を提供する • 新規プロダクトもスタートアップに勝るスピー ド感を持って開発。プロダクト単体でもユー ザーに価値が届くように 統合型ERPに求められる デザインシステムに求められる
  4. 12 現状のデザインシステム/取り巻く状態 • フェーズ ◦ 立ち上げから3年程度経っていて、各プロダクトで利用されている • 用意しているもの ◦ ReactComponent

    ライブラリ ◦ figmaライブラリ ◦ storybook(ドキュメント・カタログ) ◦ UI/UXガイドライン(画面設計の指針) • 体制 ◦ 中心メンバーがいつつ、各チームから都度コミットしてもらっている ◦ 毎週サロンを開くなど、相談しやすい環境づくり • 開発組織 ◦ デザイナー30人以上、エンジニア250人以上
  5. 13 現状のデザインシステム/出している効果 • 1からコンポーネントを実装しなくて 良く、修正時は使っている箇所全体 に反映できる • デザインライブラリにあるものは実装 としても存在し、Designer/Engineer 間のコミュニケーションも円滑にな

    る。 コンポーネントレベルで、一定の効果を出している 開発生産性 • コンポーネントの見た目と挙動が揃 う。見た目から挙動がなんとなく想 像できユーザーが学習しやすい • アクセシビリティなど品質も伴い、誰 にでも使いやすい状態の実現を担 保している 挙動の一貫性・品質の担保 • 各コンポーネントに、文字や色など のデザインエレメントが反映されて いる。 • イラストを組み込んだコンポーネント も存在する。 ブランド体現
  6. 14 目指す姿と現状とのギャップ 現状出している効果 • コンポーネントレベルでの一貫性に とどまり、似たパターンの画面でもレ イアウトが異なることもある • コンポーネントレベルの開発生産性 への寄与にとどまり、似た組み合わ

    せの実装を繰り返している箇所もあ る 目指す姿から求められること • どのプロダクトを使っていても「一貫 した体験」を提供できるよう支えたい • 新規プロダクトの立ち上げ、既存プ ロダクトの改善共にスピード感を 持って開発できる土台としたい
  7. 17 画面パターンとして定義したいことと期待する効果 • プロダクトを通した「一貫した体験」を提供し やすくなる • デザイン生産性 ◦ 7~8割はパターン化される見込みで、デザ インのベースとして捉えられる

    ◦ パターン化されない部分によりフォーカス して考えられる ◦ 属人化せず、再生産しやすくなる • 開発生産性 ◦ デザインが揃うと、frontの実装としても揃 えやすくなる • パターン自体の定義 • パターン毎の画面レイアウト • 画面遷移などの挙動や振る舞い • 提供したい体験に基づくデザインの根 拠 • etc.. 定義したいこと 期待する効果
  8. 18 どう画面パターンを規定していくか • パターンを洗い出す ◦ 扱うオブジェクトの性質と分類 ▪ 一覧表示で、どう識別されるか(名前、日付と数字等の組み合わせ、プレビューetc..) ▪ 詳細表示で、内包するデータの表示や関連するデータの示し方

    ▪ etc.. ◦ どのプロダクトにもあるパターン(オンボーディング、インポートetc..) ◦ 画面としての振る舞い(操作、遷移、フィードバックetc..) ◦ パターンにする粒度の判断 • パターンに合わせた理想系の画面を再定義 ◦ レイアウト・ビジュアル・振る舞い等をも含めて再定義 ◦ 提供したい体験と合わせて、デザインの根拠を残す ◦ デザイナーの総意となるように協力しながら進める
  9. 19 想定されるアウトプットと運用 • アプトプット ◦ ガイドラインとして、画面パターンを追加 ▪ パターンの分類、パターンごとの理想系の画面 ◦ デザインシステムに反映

    ▪ 既存コンポーネントのビジュアル調整や置き換え ◦ パターン化される単位で ▪ figmaライブラリで提供 ▪ storybookに実装サンプルを載せる • 運用 ◦ デザイナーやエンジニアは画面パターンに基づいてUIを考える ◦ 改善の余地が出てきた場合は、画面パターン自体のアップデートを行う ◦ 普及のための活動や、相談や意見を拾う場を用意する
  10. 21 将来的にありえる展望 • より高い開発生産性への試み ◦ 画面テンプレートの自動生成やscaffoldingを試す未来もあるかも • デザイナー職以外の人もUIを考えやすくなるかも ◦ パターンを見極められると作るべきUIがおおよそ見えるはず

    • プロトタイプの検証の高速化 • etc.. *あくまで可能性として考えられるかもしれないというスタンスで書いています 未定ですが、画面パターンが定まるからこそ 手を伸ばせる領域もあるかもしれません
  11. 23 まとめ • freeeの目指す姿の実現に向けて「画面レベルでの一貫性や開発生産性」が必要と考え、その 手立てとして「画面パターンと結びついたデザインシステム」を検討しています。 ◦ ただし、統合型クラウドERPや組織規模の前提がなければ画面パターンまで規定する必然 性は高くないかもしれません。1つの参考にしていただけたら幸いです • 画面パターンへの取り組みはこれから手探りで進めていく段階です。

    ◦ パターンとして見える部分だけでなく、提供したい体験からデザインの根拠を考えたり、デ ザイナーの総意となるように協力して進める事も大事。 ◦ アウトプットの質も上がりますし、その後の浸透もしやすくなると思います。 • デザインシステムとして事業の成長に貢献できる度合いは大きいですし、将来的な展望にも可 能性を感じています