OOUIのチーム導入と実践を加速するFigmaテンプレートを公開します。
昨今のUIデザイナーであれば "OOUI" をご存知でしょう。「実際何をすればいいの?」「何だか面倒くさそう」と疑問を感じたこともあるかもしれません。OOUIの課題は、デザイナー間の習熟度の差が大きすぎて、チームでの導入, 継続が難しい点です。私も度々そういった課題に当たってきたので、解決策として専用ファイルをFigmaに作ったところ、改善することができました。そのファイルを紹介・シェアします。
Introduction
先日、OOUI設計用のFigmaテンプレートをコミュニティに公開しました。
私自身も所属するチームで活用し、それによってモデリング作業が高速化され、またデザイナー間の連携も驚くほど改善されました!
過去のモデリングもこのフォーマットに置き換えたい程度には使い勝手がよかったので、皆さんのOOUIの導入や実践にも役立てばと思い、このテンプレートを解説とともにシェアします。
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3b91a11d-09c2-4932-9b92-658b03bb38fc_3044x1974.png)
おかげさまで、本ニュースレターは購読者100人までもう少しのところまで来ています!友人や同僚の方々などにぜひシェアして応援くださいますと幸いです!
効果
このテンプレートを使うと、次のような効果を得られます。
OOUIにおけるモデリング作業が早くなる
UIモデルの保守が楽になる
細かい理屈や能書きはさておきOOUIを始められる
こんな人におすすめ
複数人のデザイナーが連携する必要のある現場
OOUIの学習や継続的な活用や保守が出来ていない
細かいことはいいからOOUIをやってみたい
特徴
モデルとビューと、
スクリーン。
このFigmaテンプレートには、モデリング用のテンプレート、ビュー設計テンプレート、スクリーン設計テンプレートの3つが含まれています。
この3種はOOUIを実践するために必要な三種の神器。それを1ファイルで完結できます。
まとめとしての
プレゼンテーションレイヤー
原理的なOOUIではビュー設計までを行います。
ただ、ビュー設計の段階ではローコンテクストすぎるため、より上流の開発工程との接続にやや難があります1(ワイヤーフレーム, 画面設計書, 画面遷移図, サイトマップの作成等)。
そこで、画面遷移図から画面イメージを抜いたようなものを作ることで、そういった中間成果物への接続点を作ることがあります。
そのアンサーとしてプレゼンテーションレイヤーというものを作れるようサポートしました。
ちなみにこの表現方法は、原理的なOOUIではなくGoodpatch社のデザインブログにあるプラクティス2を参考にしています。
保守が楽々。
モデルにビューが連動。
OOUIは便利ですが、作業としては面倒でもあります。
というのも、普通にモデルを書いていくと、1つを書き換えるたびに最大3箇所を手動で更新する必要があります3。
修正点数の2〜3倍の工数はさすがに面倒ですし、変更漏れやミスを引き起こす遠因でもあります。
そこで本テンプレートでは、モデルにビューが連動するようにしました。4
これにより、モデルを書き換えるだけで全ての設計書が自動的に書き換わるようになり、工数が50%〜66%削減されました。
OOUIに詳しくなくても使える
非デザイナーのFigmaユーザーも利用することを想定し、OOUIに詳しくなくても利用できるようにしています。
チュートリアルあり
そのために、数分で完了できる短いチュートリアルを用意しました。
このチュートリアルをこなせばどのように作業すればよいか分かります。コンポーネントを1つ1つ読み解くようなことは必要ありません。
Figmaユーザーはもちろん、パワポやNotionを使える程度のリテラシーがあれば誰でも活用できます。
カラートークンで省力化
モデルやビューには作成後、一目で識別できるようにするために色付けすることが望ましいのですが、付ける色を考えるというのは案外面倒くさいものです。
そこで、色相別に10種類の色をプリセットとしてテンプレート中に持たせています。これはファイル内で自由に呼び出すことが出来ます。
次回予告
次回は、紹介したFigmaテンプレートも絡めて、最近OOUIのドキュメントをある形・思想で活用し、頼もしい効果を得ている話を配信予定です。
以前書いた、オブジェクトを保守することで設計思想のバラツキを抑えるというプラクティスのアップデート的な内容になっています。お楽しみに!
参考記事
Substackアプリを使うと読みやすいのでおすすめです。
【より上流のとの接続に少し難が】
この”難”は、ビュー設計の時点では画面の形になっていないために起こる。
画面という単位は挙動の一瞬を切り取っただけの不安定な粒度なため、MECEでなければならない設計では役に立たない。そのため設計においては画面は不要である、原理的には。
しかし現実はそう単純ではない。上流工程では設計の正しさよりもプロダクト像の大枠を合意することが必要で、このためにはビュー設計では細かすぎて逆に役に立たない。
要するに、工程によってドキュメントは作り分け、使い分けるべきである。
【Goodpatch社のデザインブログにあるプラクティス】
当該記事はこちら。
https://goodpatch.com/blog/uidesigner-skill-ooui-structure
同ブログ記事はじわっと人気があり、OOUIを実践しようとしてこちらの記事で復習するUIデザイナーを何度か目にした。素晴らしいプラクティスに感謝。
【1つを書き換えるたびに最大3箇所を手動で更新する必要があります。】
例えばオブジェクト名を書き換えた場合、追加でモデルのオブジェクト名とビュー設計上のオブジェクト名、プレゼンテーションレイヤー上のオブジェクト名 の3つを書き換えることになる。
あるいはUIモデル上でプロパティを書き換えた場合、ビュー設計のプロパティを書き換えることになる。同じくCRUDを書き換えた場合、ビュー設計のCRUDを書き換えることになる。
【モデルにビューが連動するようにしました】
FIgmaのコンポーネント機能を活用して連動させている。