【OOUI愛好家必見！】なぜ運用ルールを緩和しただけで、オブジェクト指向がUIデザイナーに浸透し始めたのか？
オブジェクト指向UI（OOUI）の固定観念に挑んだ経験は、私にとって小さな革命でした。従来の厳格なOOUI運用にあった制約感と戦い、デザイナーの創造性を抑えることなく適切なUIデザインに到達する道を探りました。運用ルール緩和により、OOUIは面倒な工程から便利で使いたいツールへと変貌。私とチームをOOUIの原理主義から解放しました。この事例は、OOUI導入と継続のハードルを超える1つの方法です。
Introduction
以前配信したニュースレターで、OOUIオブジェクト設計を基礎としてデザイナー間の連携を行うことを紹介しました。
しかし最近あるチームでデザイナー間, 開発者間の議論によって、OOUIで作ったモデルのより良い使い方を見つけました。
ナレッジのアップデートとその具体的な内容, 効果, 意図をシェアします。
課題
OOUIの過程で作るUIモデルやビュー設計は、優秀ではありますが原理主義的に運用するとある課題がありました。
問題1：原理主義
原理主義的とは、必ずモデリングを行ってからUIを作る運用にする といった像です。
OOUIに習熟していないデザイナーにとってはただただ面倒である
アイデアや表現からUIデザインを始めたいデザイナーにとって過剰に窮屈
総じて、排他的で、初めて触れるデザイナーにとっては受け入れがたい ものになってしまいます。「そんな面倒くさいことしなくても、俺はUIを作れるぞ」と。
慣れない内から知らないプラクティスを問答無用で使わされることは反発につながります。これは大変望ましくないことです。
チームの秩序を乱し、デザイナー個人にとってもプラクティスを得るせっかくの機会を感情的に遠ざけかねません。OOUIに偏見を持つ人が増えるのでOOUIというプラクティスにとってもマイナスです。
問題2：テーブル設計と重複して見える
また、エンジニアの視点では次のような課題もありました。
オブジェクト設計に依拠してテーブル設計をする必要があるかのように見える
似ているからとオブジェクトに依拠してテーブル設計を行うと、中期的には破綻してしまう可能性がある
解決策
これらの課題を解決するために、あるチームでの最近の議論によって、より良い運用を見つけました。
まず、OOUIに対する面倒さや窮屈さを解消するために、オブジェクトを必ず先に作らなくてもよい という運用にしました。
一方で、”正しい”UIを導きやすいというOOUIの利点は有用なので、作った画面は必ずモデルと見比べ、答え合わせ的にチェックするようにしました1。
そして最後に、エンジニアからテーブル設計に使えるかという質問があった時、Noと明確に回答するようにしました。また、そもそもデザイナー間のみの連携資料として運用するようにしました。
効果
面倒な作業 → 便利な道具 に
こうすることによって「面倒くさそう」だったOOUIは、作ったデザインの答え合わせを出来る「便利な道具」へと飛躍しました。この利便性によってOOUIの活用度が自然と上がっていくのを感じています。
OOUIの悪いところが抜け、良いところが目立つようになったわけです。
もう少しマクロな視点では、答え合わせ──つまりデザインレビューがデザイナーの主観や経験則によらず評価軸が明確に2なり、その有効性が戦略的に増しています。これはチームやプロダクトにとってもメリットです。
デザインレビューの実質的な代替という点は、オブジェクト設計をチーム共通の設計思想にするという以前の投稿と共通点がありますね。
ほかドキュメントやDDDとの共存
以前の投稿ではオブジェクト設計を使って早めにエンジニアが着手してもらうことを説いていましたが、これは実際には混乱の遠因となるものでした3。
というのも、オブジェクト設計は大いに役立つ一方、OOUIに未習熟なメンバーとの共有資料, 進行上重要なドキュメントとして使うには難読で、全員が依拠できるものではなかったからです。
そこでOOUIに依存せず、様々な人が分かるドキュメント(要件定義書, 画面遷移図, ワイヤーフレーム, ER図など)を別途用意し、非デザイン各部門はそちらに依拠するのが、やはり望ましいようです。
そもそもエンジニア側ではOOUIが無くても、明示的にであれ暗黙的にであれ、OOUIと似た性質のモデリングは行われます。餅は餅屋。信頼して任せましょう。
重要なのは、互いのモデリングの根拠になるドメイン情報や顧客像が同じであることです。
おわりに
チームでOOUIを使う際の課題がいくつかありますが、それを解決するのが次の3つでした。
OOUIのオブジェクト設計を必ず先に行わなくていいというルール
答え合わせとして便利に使うというルール
デザイナー間のみの共同資料にするというルール
この運用はMECEに現実に即していて、柔軟かつ初学者でも受け入れやすいものでした。
このナレッジによって、しばらくOOUIの導入に足踏みしていたプロジェクトへの導入と、安定的な運用化に成功しています。
今のところ上手くいっていますが、今後さらにより良いプラクティスを見つけたら、またシェアします。
それでは。
Substackアプリを使うと読みやすいのでおすすめです。
【答え合わせ的にチェックするようにしました】
作ったUIデザインやプロトタイプがモデルに照らし合わせて正当な遷移になっているか、プロパティの抜け漏れは無いか、CRUDの抜け漏れはないか…等をモデルと見比べてチェックする。
【デザインレビューがデザイナーの主観や経験則によらず評価軸が明確に】
画面が出来上がった後のデザインレビューでは、レビュワーがデザイナーであっても短時間で脳内リバースエンジニアリングをせねばならない。
これでは真に有効なフィードバックや議論はしづらい。もしくはデザインレビューの時間を伸ばす必要がある。非デザイナーであればいわんや望み薄である
【混乱の遠因となるものでした】
実体験として、早期に合意したオブジェクトとDB設計を、後になって実現不可能であるとして棄却せざるを得ないケースがあった。
この時開発中盤に差し掛かっていたこともあり、徒労感から、デザイナー, エンジニアともにバーンアウトの危機にも繋がった。
これは後から考えると、DBという論理の世界の設計を、UIという具象(あるいは物理)向けに行った設計を参照して作ってしまったことが原因だった。
これをしっかり防ごうとするならば、DBはOOUIのUIモデルと通底する別のドメインモデリングを根拠に設計を行い、その上でBFFなどのアーキテクチャを用いてDBの複雑性をバックエンドとフロントエンドの中間で吸収しなければならなかった。