⛩️

OOUIのチーム導入と実践を加速するために作った、オブジェクト設計用Figmaテンプレートを解説。

2023/12/18に公開

Introduction

先日、OOUI設計用のFigmaテンプレートをコミュニティに公開しました。

私自身も所属するチームで活用し、それによってモデリング作業が高速化され、またデザイナー間の連携も驚くほど改善されました!

過去のモデリングもこのフォーマットに置き換えたい程度には使い勝手がよかったので、皆さんのOOUIの導入や実践にも役立てばと思い、このテンプレートを解説とともにシェアします。

FIgmaコミュニティの検索結果(12/11現在)。ぜひ検索してみてください。

効果

このテンプレートを使うと、次のような効果を得られます。

  • OOUIにおけるモデリング作業が早くなる
  • UIモデルの保守が楽になる
  • 細かい理屈や能書きはさておきOOUIを始められる

こんな人におすすめ

  • 複数人のデザイナーが連携する必要のある現場
  • OOUIの学習や継続的な活用や保守が出来ていない
  • 細かいことはいいからOOUIをやってみたい

特徴

モデルとビューと、スクリーン。

このFigmaテンプレートには、モデリング用のテンプレート、ビュー設計テンプレート、スクリーン設計テンプレートの3つが含まれています。

この3種はOOUIを実践するために必要な三種の神器。それを1ファイルで完結できます

テンプレートの全体像。Section1でモデリング, Section2と3でビュー設計を行う(便宜的に3は”スクリーン設計”と呼称している)

>>Figmaテンプレートを開く

まとめとしてのプレゼンテーションレイヤー

原理的なOOUIではビュー設計までを行います。

ただ、ビュー設計の段階ではローコンテクストすぎるため、より上流の開発工程との接続にやや難があります[1](ワイヤーフレーム, 画面設計書, 画面遷移図, サイトマップの作成等)。

そこで、画面遷移図から画面イメージを抜いたようなものを作ることで、そういった中間成果物への接続点を作ることがあります。

そのアンサーとしてプレゼンテーションレイヤーというものを作れるようサポートしました。

プレゼンテーションレイヤーの作例(TwitterやインスタのようなUGCメディアをイメージ)

>>Figmaテンプレートを開く

ちなみにこの表現方法は、原理的なOOUIではなくGoodpatch社のデザインブログにあるプラクティス[2]を参考にしています。

保守が楽々。モデルにビューが連動。

OOUIは便利ですが、作業としては面倒でもあります。

というのも、普通にモデルを書いていくと、1つを書き換えるたびに最大3箇所を手動で更新する必要があります[3]

修正点数の2〜3倍の工数はさすがに面倒ですし、変更漏れやミスを引き起こす遠因でもあります。

そこで本テンプレートでは、モデルにビューが連動するようにしました。[4]

これにより、モデルを書き換えるだけで全ての設計書が自動的に書き換わるようになり、工数が50%〜66%削減されました。

モデルとビュー設計の連動の様子。モデル(左)を編集するとビュー設計(右)が連動して変化するのが分かる

>>Figmaテンプレートを開く

OOUIに詳しくなくても使える

非デザイナーのFigmaユーザーも利用することを想定し、OOUIに詳しくなくても利用できるようにしています。

チュートリアルあり

そのために、数分で完了できる短いチュートリアルを用意しました。

このチュートリアルをこなせばどのように作業すればよいか分かります。コンポーネントを1つ1つ読み解くようなことは必要ありません。

Figmaユーザーはもちろん、パワポやNotionを使える程度のリテラシーがあれば誰でも活用できます。

チュートリアルページの全景。

>>Figmaテンプレートを開く

カラートークンで省力化

モデルやビューには作成後、一目で識別できるようにするために色付けすることが望ましいのですが、付ける色を考えるというのは案外面倒くさいものです。

そこで、色相別に10種類の色をプリセットとしてテンプレート中に持たせています。これはファイル内で自由に呼び出すことが出来ます。

プリセットされている色の一部。Variableとして持たせている。

>>Figmaテンプレートを開く


脚注
  1. 【より上流のとの接続に少し難が】
    この”難”は、ビュー設計の時点では画面の形になっていないために起こる。画面という単位は挙動の一瞬を切り取っただけの不安定な粒度なため、MECEでなければならない設計では役に立たない。そのため設計においては画面は不要である、原理的には。
    しかし現実はそう単純ではない。上流工程では設計の正しさよりもプロダクト像の大枠を合意することが必要で、このためにはビュー設計では細かすぎて逆に役に立たない。要するに、工程によってドキュメントは作り分け、使い分けるべきである。 ↩︎

  2. 【Goodpatch社のデザインブログにあるプラクティス】
    当該記事はこちら。
    https://goodpatch.com/blog/uidesigner-skill-ooui-structure
    同ブログ記事はじわっと人気があり、OOUIを実践しようとしてこちらの記事で復習するUIデザイナーを何度か目にした。素晴らしいプラクティスに感謝。 ↩︎

  3. 【1つを書き換えるたびに最大3箇所を手動で更新する必要があります。】
    例えばオブジェクト名を書き換えた場合、追加でモデルのオブジェクト名とビュー設計上のオブジェクト名、プレゼンテーションレイヤー上のオブジェクト名 の3つを書き換えることになる。
    あるいはUIモデル上でプロパティを書き換えた場合、ビュー設計のプロパティを書き換えることになる。同じくCRUDを書き換えた場合、ビュー設計のCRUDを書き換えることになる。 ↩︎

  4. 【モデルにビューが連動するようにしました】
    FIgmaのコンポーネント機能を活用して連動させている。 ↩︎

Discussion