「モデルベースUIデザイン 構造化UIと情報設計の方法論」を読みました。
どうも。Reoです。
モデルベースUIデザイン 構造化UIと情報設計の方法論の本を読み終わったので、紹介と感想を書いていこうと思います。
本を読んだきっかけ
本屋さんでたまたま手に取った本が、usagimaru氏の本であることに気づいて購入しました。
この本の著者である丸怜里氏ことusagimaru氏のことは以前からXやQiitaなどを通して存じ上げており、間違いなく有益な情報が書いてあるに違いない…！という確信がありました。
発売日は2025年7月7日だったようで、少し出遅れてしまったな〜と思ったほどです。
本書の構成
全7章の構成です。
序章
第1章 情報設計とUIデザイン
第2章 ユースケース定義
第3章 タスク整理
第4章 概念設計
第5章 ナビゲーション構造設計
第6章 プラットフォームへの適合とインタラクション設計
第7章 構造設計とインタラクション設計の深化
ページ数は索引含め287ページ。
本書では、見栄えの良いグラフィックデザインやビジュアルデザイン、効果的なUIのレイアウト方法、見やすいカラー設計、タイポグラフィなど、主に見た目を整えるためのテクニックやプロセスにはほとんど言及しません。(p11 より抜粋)
実際に本書にはこのようなルック&フィールに関わるような話はほとんどなく、情報をどう整理して設計していくかの話が主でした。
本書は「モデルベースUIデザイン」構造化UIデザインの発想と方法論｜usagimaruの内容を基にして更なる加筆修正したものになるので、気になる方は此方の冒頭を読んでみてから購入するのも良いかもしれません。
一読してみて
情報設計に基づいたUIデザイン。自分がやりたいのはこういうことだなぁと思う一冊でした。
usagimaruさんはエンジニア出身のデザイナーであることもあり、エンジニアの設計方法やDBのような設計方法を取り入れているように感じました。なので、UIデザイナー向けではあるけれど、エンジニア視点の方が理解しやすい内容かもしれません。
自分はどちらかというとエンジニアではあるけどUIデザインに口出しをするような人なので、自分が目指す道の先にいるような方だなぁと思いました。
本書を読みながら、自分がこれまで作ってきたアプリを鑑みて直したくなりました。ルック&フィールに関わる内容がないにも関わらず直したい箇所が出てきました。
デザインには答えがなくて難しいと思ってしまいますが、その答えのないデザインに構造化で答えをくれるような本です。
多重度と優先度
個人的に早速取り入れたいと思った設計方法が、「多重度」と「優先度」です。
多重度は概念オブジェクト同士がお互いに幾つに見えているかを示す情報です。これは関係データベースの relationship のような考え方であると思いながら読んでいました。
デザイナーはコンテンツが空の画面を作り忘れることがありがちです。（偏見かも知れませんが私自信もそのような場面に出会ったことがありました。）多重度という考え方があれば、このような失敗はなくなり、画面を漏れなく用意することができるようになるんじゃないでしょうか。
優先度については、シンプルにどれがいちばん優先かを決めておくということですが、これを決めるか決めないかで意思がブレることがなくなり、より迷うことなくUI設計ができるようになる気がします。シンプルだけど非常に大切。
「画面」起点で考えない
自分はこれまでかなり「画面」起点で考えてきていたので、この話も印象的でした。
ナビゲーションも「画面遷移図」ではなく、多重度やユースケースを基にして、1つの概念オブジェクトに辿り着くまでのルートを示すものでした。
このナビゲーションを基に、画面遷移図を作るのはもっと後の工程となります。
「機能」の代わりに「ユースケース」で考える
これも非常にわかりやすく、印象的でした。
ですがユースケースを考える工程にデザイナーが関われない場合も多いんじゃないかと思います。
幸い自分は個人開発なので問題ではないのですが、デザイナーが要件定義に参加できないと、それだけでも手戻りが発生するような状況になり、その点は会社やプロジェクトの構造自体が変わるべきなのだろうなぁと感じました。
読者対象に「ソフトウェア関連のエンジニア、ディレクター、PdM、PM」が含まれているのはこのような工程にUIデザイナーが必要であるということを知ってもらうためという意味もあるかも知れません。
タブジャンプを抑制する
過去を振り返ると、とても胃が痛くなる内容です。最近ではそこまでやらなくなった気もしますが、昔はタブジャンプをよくやってしまっていました。
タブジャンプとは、ユーザーがあるタブ内での操作最中に、意図せずに別のタブに勝手に切り替わる振る舞いを言います。(p181 より)
情報コンテンツを特定のタブに所属させる「縦割り構造」をした結果、タブジャンプが必要になってしまうという話です。どのタブにも重複して同じ情報コンテンツが現れても良いのです。（例として写真アプリでライブラリタブからもコレクションタブからも同じ写真にアクセスできる）
経験を積んだりApple製のアプリを真似することで「なんとなく」1つのコンテンツは複数のタブに現れても良いことを学びましたが、言語化されると非常に納得感があり、理解が深まります。
デザインソフトを使い始める前の工程
本書ではデザインソフトの使い方などは一切出てきません。Figma や Sketch などを使い始める前段階の話になります。
おそらく多くの人は本書に書かれているほとんどの工程を行っていないんじゃないでしょうか。
私自身、自分のノートを見返すと、概念オブジェクトっぽいものが洗い出され、実装したい機能が書き出され、そこからすぐ画面が描かれてしまっています。コンセプトも簡潔に一言「こういうアプリ」と決めているだけです。DB周りを考えるために、概念オブジェクトの構造設計などを行いますが、これはUIのためではなく実装のためでした。
これがクライアントから与えられた情報を基にデザインする立場であれば、それこそ与えられた情報をあまり整理することなく、すぐに頭に浮かんだ画面遷移図やビューの絵を描き始めそうです。
ある程度の情報設計はやってはいるつもりの場合も、それを論理で説明できるほど自分の手法を理解しているわけでもなく、「なんとなく」作っているものになってしまいがちなのではないでしょうか。
そもそも「デザイン」という意味は幅広いです。「UIデザイン」というデザインをUIにフォーカスした名前にしても難しいです。「デザイン」という言葉については本書の著者であるusagimaruさんも記事を書かれています。
偏見まみれのUIデザイナーのタイプ分類の記事に紹介されているなかで、私の偏見ではデザイナーとして働いている人達は「ヴィジュアル表現志向タイプ」や「インタラクティブ表現志向タイプ」の方が圧倒的に多いのではないかと思います。
本書はこのタイプ分類の中では「情報アーキテクチャ志向」への手がかりを得られる本だと思います。
自分は特にグラフィック表現やインタラクティブ表現などのルック&フィールに関わる表現がとても苦手なので自分のことはUIデザイナーではないという自称です。また多くの人がUIデザイナーに求める人物像がルック&フィールを表現できる人という認識をしています。（これは自分の偏見なので実際はどうかはわかりませんが。）本書の内容「だけ」ができてもUIデザイナーを名乗るのは少し心許ないなとは思います。
構造化のおかげでデザインに芯が通る
よく「このデザインはなんでこうしたの？」と訊かれることがあると思います。また「こうした方が良くない？」というのもよく言われることでしょう。
情報設計や構造設計を行っている場合には、この疑問に論理的に答えられるようになるのではないかと思います。「こうした方が良くない？」についても、そうしない方が良い理由に説得力がでるのではないでしょうか。
本書をうまく活用できると、デザインに芯が通ると同時に、自分自身がデザインしたものへの自信となってくれるのではないかと思います。
デスクトップの話も多め
usagimaruさんはmacOSとiOSのネイティブアプリケーション開発が専門の方です。
本書は基本的にはOS関係なく使える話であり、第6章にてそれぞれのプラットフォームに適合した設計にする話が出てきます。そこでは、macOS、iOS だけでなく Windows の話もあります。Androidの話も少し出てきます。その中でもデスクトップの話が多く感じました。Webの話は少なめです。
UIデザイナーの多くはWebやモバイル畑の人が多そうではあるので、この辺が冗長に感じてしまう人もいるかも知れません。ですが他の畑のことを知っておくこともどこかで役にたつはずです。
個人的には長年PCを扱ってきているのにメニューバーで使えるコマンドの ... の意味を初めて知り、目から鱗でした。
おわりに
本書はUIデザイン目線だけでなく、プログラムの設計もしやすくなりそうだなと考えています。
最近、プロジェクトのディレクトリ構成を考えているときに、Webフロントエンド界隈に存在する「コロケーション」という考え方があることを知りました。
コロケーションは 「関連するリソース同士を近くに置いておく」という考え方になります。
これまでの私は設計を学び、その設計に当てはめたディレクトリ構成をしがちでした。WebではAtomic Designを学んだ後は atoms というフォルダを作ったし、iOSでVIPERを学んだあとは Interactor というフォルダを作りそこに全ての Interactor を入れるようなことをしていました。なんとなくうまくいっていないなとは思っていましたが、それを説明する文献などは少なく、なかなかそこから抜け出すことができませんでした。コロケーションの話を読んだ後、ようやく実装の設計とディレクトリ構成は別物だということに気づき、理解しました。
このコロケーションを実際どのように分けるのかという話に「概念オブジェクト」や「ユースケース」や「ナビゲーション設計」の話が使えるのではないでしょうか。ナビゲーション設計は画面遷移図を基にして切り分けるのではなく、本書で紹介されているナビゲーション設計方法です。SwiftUIのComponentsも「画面」ではなく「ビュー」で構築すると良さそうです。
これが本当にうまく当てはまるかはわかりませんが、本書もデータベースにおけるCRUDの考え方を利用するなどして上手くエンジニアでの経験を取り入れているので、試してみる価値はありそうです。
本書だけでなく、本書に紹介されている本やusagimaruさんの他の記事（noteなど）を読んで今後も勉強を続けたいです。
貴重な考えを執筆して本という形で出版してくださり、ありがとうございました。
是非読んでみてください。
![card]
モデルベースUIデザイン 構造化UIと情報設計の方法論
色々直したいところがいっぱいです。なんかちょっとわかってそうなこと書きながらブログはこんなのなので、恥ずかしい。やりたいことがいっぱいでてきました。
ではでは〜。
