トップ/記事一覧

『オブジェクト指向 UI デザイン』を読んだ

📆2020/06/14(最終更新日:2020/07/15)🔖 デザイン読書ログ

この記事は最終更新日から1年以上が経過しています。内容が古い箇所がある可能性があるためご注意ください。

オブジェクト指向UIデザイン
オブジェクト指向UIデザイン

(週末なので沢山本を読んでいます)ソシオメディアの上野学さんが本を出されたというツイートを見て、発売前から予約購入していた「オブジェクト指向 UI デザイン」をとうとう読み切ったのでブログを書いています。ソシオメディアの記事も愛読していたので、これは買わねば……と思い、発売前から予約購入していました。

🐈

軽く本の紹介をすると、

世の中の UI を大別すると以下の2つに分けられて、

  • タスク型 UI
  • オブジェクト指向型 UI
  • 一部の例外を除いては、オブジェクト指向型の UI が良いんだよと主張している本。オブジェクト指向型 UI の方が何故良いのか?オブジェクト指向 UI を作るにはどのようなアプローチをすれば良いのか?が細かく説明されていました。内容もメチャメチャ共感できて、読みやすさも抜群だったので、UI デザイナーはもちろん、フロントエンドのエンジニアも読んでおく一冊かなと思います。

    オブジェクト(僕の理解ではドメインモデルと同義)の抽出部分に関しては、デザインのフェーズだけではなく、エンジニアリングの設計フェーズでも同じことをやるので、デザイナーだけの仕事だとは思わない方が良いかなと思いました(何も知らないデザイナーがこれを読んで、オブジェクトの抽出はデザイナーだけの仕事なんだと理解してほしくないという気持ちがちょっとある)。

    0 → 1 フェーズの設計では、エンジニアとともにドキュメントとしてドメインモデル図を作り、それをエンジニアリングの設計と UI デザインに反映される、といったコラボーレションが起きることが僕の考える理想です。(既存のプロダクトに対するコンサルティングをするとかだったらデザイナーがやるのは良いと思う)

    👀 以下、読んでてメモしておきたいなと思ったところ

    と、その感想です。

    オブジェクト指向の例外

    タスク思考の GUI が例外的に許容されるのは、ATM のようにオブジェクトが限定的で選択の必要がない場合(ATMの場合は「口座」がオブジェクトであり、その選択行為はキャッシュカードを入れる動作と一体化している)や、自己完結的な手続きを定型入力フロートして提供する場合です(P19)

    🙋‍♀️ オブジェクトが単一のときはオブジェクト指向 UI でなくても良い場合があるそう。(が、僕たちが普段作る Web アプリケーションだとめったになさそうですね。)

    モデル - ユーザーの関心対象の模式について

    オブジェクトモデリングはオブジェクト指向 UI 設計における最も重要な活動で、デザインプロセスにおいて最初に行うことになります。そしてその結果は、続く活動すべての手掛かりとなります。(P42)
    オブジェクトモデリングの作業は、開発者の間でオブジェクト指向分析として知られているものと同じです。多くの開発者はこれをあくまでソフトウェアの内部的な設計の一環として捉えており、UI のデザインとは関係ないものと考えているかもしれません。しかしオブジェクト指向 UI のコンセプトは、ユーザーの目当て(オブジェクト)を UI に反映することですから、オブジェクトモデリングは直接的な UI デザインの開始点なのです。(P43)

    🙋‍♀️ オブジェクト(自分の理解ではドメインモデル)の抽出に関しては、個人的には習得済みだったので、不要な章ということで読み飛ばしました。ブログの冒頭でも書いたけど、デザイナーの方はぜひエンジニアリングの設計プロセスも学んでほしい気持ちです。

    レイアウトパターンの適用

    オブジェクトの一覧表示、および、オブジェクトの追加、閲覧、更新、削除といった操作に伴う視覚表現には経験則として「良いパターン」があるのです。そのパターンを適切に踏襲することで、ユーザーがアプリケーションの振る舞いを短時間で学習し、自らの工夫も含めて思いどおりに使えるような UI ができあがるのです。(P87)

    🙋‍♀️ この章(3-5 レイアウトパターンの適用)が個人的に一番面白かったです。オブジェクトを抽出し、それをどうレイアウトにマッピングしていくかが書かれていました。

    🐈

    フロントエンドのエンジニアと、UI デザイナーは必読書。オススメです。

    オブジェクト指向 UI デザイン | Amazon