UIデザイナーを取り巻く様々な設計 / Intrinsic meaning of UI Design

by Tsuyoshi Higuchi

Slide 1

Slide 1 text

Human Intrinsic meaning of UI Design 6*σβΠφʔΛऔΓר༷͘ʑͳઃܭ Computer

Slide 2

Slide 2 text

みなさん、設計って何をどこまでやっていますか？ Question

Slide 3

Slide 3 text

デザインは”設計”という意味だけど、 UIデザイナが関わる設計はそこだけなのでしょうか？ UXやビジュアル・インタラクションの設計だけ？

Slide 4

Slide 4 text

UIデザインにおけるヒトやコンピュータの情報処理・設計について UIデザイナー視点でまとめてみました。 ͱ͍͏Θ͚Ͱɺࠓճ͸ʜ

Slide 5

Slide 5 text

Profile • UI Designer • 趣味でサービスつくったり、ハッカソンに参加したり • 最近熱いのはDDDと情報処理心理学毎週日曜朝に色々な企業・学生のエンジニアと渋谷で趣味開発やってます。デザイナーが少ないので興味ある方はぜひ！ Tsuyoshi Higuchi devMorning @tyshgc

Slide 6

Slide 6 text

Agenda 情報処理のデザイン 1. モデルのデザイン 2. 開発コミュニケーションのデザイン 3. まとめ 4.

Slide 7

Slide 7 text

情報処理のデザイン 1.

Slide 8

Slide 8 text

よくみるUXフロー ೝ஌ ڵຯ ߦಈ ൺֱ ҙࢥ ܾఆ ར༻ この流れの中にUIが介在する UI UI UI UI UI

Slide 9

Slide 9 text

さらに細かくユーザフローを見る

Slide 10

Slide 10 text

記事リーダアプリで記事を選ぶまでのユーザフロー ىಈͨ͠ΒϦετ͕ ͋Δͱࢥ͍ͬͯΔ Mainﬂow Subﬂow アプリを起動する画像などで内容を軽く認知タイトルなどで内容を軽く認知リスト面を見る記事をタップする記事セルに指でふれる画面が記事詳細へ切り替わるのを期待 Ϧετηϧ͸λοϓ Ͱ͖Δͱ͍͏ࢥ͍ࠐΈ λοϓ͢Δͱը໘͕ ੾ΓସΘͱࢥ͍ͬͯΔ

Slide 11

Slide 11 text

ユーザフローは単一軸ではなく、各タスクにあるサブフローを経て次のタスクへ進む

Slide 12

Slide 12 text

ユーザフローを踏まえて、UIデザインってそもそもなに?

Slide 13

Slide 13 text

Human Computer UIデザイン = ヒトとコンピュータを繋ぐ層のデザイン User Interface Design

Slide 14

Slide 14 text

UIをデザインするということは、ヒトとコンピュータどちらの仕組みも知る必要があるのでは? ユーザの流暢性《認知や処理のしやすさ》を向上させること

Slide 15

Slide 15 text

非エンジニアの考えるコンピュータの情報処理の仕組みは?

Slide 16

Slide 16 text

ちょっと、コンピュータの処理をブラックボックスにしすぎ… エンジニアがいい感じにした処理群 UIに入力 UIに反映

Slide 17

Slide 17 text

もうちょっと詳しく見てみる… 例えばWebフロントエンドのアーキテクチャ

Slide 18

Slide 18 text

User Interaction Action Dispatcher Store View User Interaction ユーザの入力リクエストを受けデータを渡す ActionとStoreの紐付けデータの永続化を担う Storeを状態から描画処理 Fluxのアーキテクチャだとこんな感じ FluxはFacebookが提案した一方向型のアーキテクチャ WebAPI

Slide 19

Slide 19 text

ʜݟ͑Δͧʂࢲʹ΋ྲྀΕ͕ݟ͑Δο

Slide 20

Slide 20 text

WebAPI取得時に待機アニメーションで遅延を感じさせない工夫できるかも? とか Storeに持つデータはどんなものがあるのか見えた。足りないフラグを追加してもらわねば… とかコンポーネントを意識してデザインし、実装コストを抑えれれば別の大切な部分にエンジニアリングを注力できるかも？とか

Slide 21

Slide 21 text

ヒトってどうやって動いているのだろう？

Slide 22

Slide 22 text

脳、有能！でも、そんな単純なはずは… 脳感覚身体的動作

Slide 23

Slide 23 text

感覚器官短期記憶パターン認識スキーマ身体行動感覚器官視覚・聴覚・触覚などからの入力 7秒程度の記憶長期記憶と比較、記憶と行動の紐付け紐付けから行動を呼び出す体を反応させる人間情報処理のおおよそなフローもう少し実際は複雑ではあるが、ヒトの情報処理もデータ駆動

Slide 24

Slide 24 text

人間が認識するまでの最適化が考えられるから、例えば、ディテールはアフォーダンスを踏まえて設計できるよね？とかカラーリングはパターン認識。そこから得られる意味情報（雰囲気）を無意識下で視覚野になげれば、ブランドのサポートになるかも？とか繰り返し学習を行う・体験をすることで長期記憶に残ってほしいラベリングの意味付けとかできるかもしれないね？とか

Slide 25

Slide 25 text

Human Computer User Interface Design UIデザイン = システムとヒトを繋ぐ層のデザイン ͲͪΒʹ΋ࡉ͔͍৘ใॲཧͷϑϩʔ͕͋Δ͜ͱ͕Θ͔ͬͨʂ ヒューマンコンピュータインタラクション

Slide 26

Slide 26 text

提供期待 ίϯϐϡʔλʔ ώτ 価値を提供するために両サイドの仕組みを知り ৘ใॲཧ ৘ใॲཧ 最適化されたUser Interfaceを設計する流暢性向上へ

Slide 27

Slide 27 text

Designer Engineer UIデザイン = 二者の職域にまたがる設計 User Interface Design

Slide 28

Slide 28 text

いろいろな人が職域を超えて協業するには… モノやコトの本質を抽出して共有することが近道なのでは?

Slide 29

Slide 29 text

モデルのデザイン 2.

Slide 30

Slide 30 text

サービスは、”利用者のメンタルモデル”を基にした ”ドメインモデル”の抽象化

Slide 31

Slide 31 text

メンタルモデル物事の動作がどうやって起こるのかに対する `心や意識の概念モデル` ドメインモデルサービスにあるべき `ビジネスの実体と業務の振る舞いの概念モデル`

Slide 32

Slide 32 text

サービスの本質に基づいて機能や画面が設計されるべきでは？画面（GUI）駆動開発はボトムアップなので、プロダクトの規模によってはアンチパターンになるかもしれない... サービスデザイン = 何がサービスのコアなのかの抽出が大切

Slide 33

Slide 33 text

ユーザーの満足度を上げて使い続けてもらうということは… サービスに関わるデザイナー、エンジニア、ビジネスパーソンが協業して、どこに本質的課題があるか探していく長い旅

Slide 34

Slide 34 text

利用者のメンタルモデルから得られたドメインモデルの抽象化でより本質的な課題の解決を論理的に行う

Slide 35

Slide 35 text

どうやってモデルを抽出するのか? コミュニケーションから抽出できるらしい

Slide 36

Slide 36 text

開発コミュニケーションのデザイン 3.

Slide 37

Slide 37 text

エンジニアのみなさんの多くは… ドメインモデルをコードの構造に落とし込み、共有するアーキテクチャをすでに実践しています

Slide 38

Slide 38 text

ドメイン駆動設計を大雑把にいうとドメインモデルを設計の基盤とし、実際のコードへ落とし込みドメインエキスパートやプロジェクトメンバと認識を共有する DDD = Domain Driven Design ドメイン駆動設計

Slide 39

Slide 39 text

ドメインモデルとして抽象化されたサービスの関心事をコードに書いて、コードを読んで皆が理解する Ϣʔβ ໊લ ੑผ ॅॴΛอଘ type User struct { FirstName string LastName string Age int Hobbys []string } golang

Slide 40

Slide 40 text

また、ドメインモデルの抽出を行う際に、プロジェクトメンバやドメインエキスパートなどと共通で使用する言葉の定義をする

Slide 41

Slide 41 text

例：メッセンジャーサービスの場合メッセンジャー is 自転車に乗って配送業務を行う人顧客 is 配送元や配送先の企業配送 is 配送元の荷物を配送先へ届ける行為共通に認識できる言語をきめる = ユビキタス言語 ఆٛ

Slide 42

Slide 42 text

共通言語をデザインできればモデルの抽出化は行いやすくなり本質的なモデルの抽出が行えれば UIデザインも本質的になる

Slide 43

Slide 43 text

ドメインモデルとユビキタスドメイン駆動設計の参考リンク・書籍ユビキタス言語とドメインモデル、そしてモデル探索のうずまき http://j5ik2o.me/blog/2013/05/07/domain-model/ SNSチームでのドメイン駆動設計の実践 http://labs.gree.jp/blog/2013/12/9330/ エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) エリック・エヴァンス (著), 今関剛 (監修), 和智右桂 (翻訳), 牧野祐子 (翻訳)

Slide 44

Slide 44 text

まとめ 4.

Slide 45

Slide 45 text

設計 = デザインは同義ある目的を達成するための計画をたてて、無駄を削ぎ本質を明確にする作業を繰り返すこと

Slide 46

Slide 46 text

目的 = サービスをユーザに提供し利益を生むこと… そのためには、ドメインへの理解とユーザへの理解それらをコミュニケーションでデザインしていく

Slide 47

Slide 47 text

人間中心のUIデザインを行うためにモノやコト・ヒトの本質の理解をすすめるため設計に携わっていくことが近道になる UIデザイナーという職域にだけ閉じこもるのは… サービスにもヒトにも保守的な関わり方

Slide 48

Slide 48 text

コードをかけなくても理解ができればドメイン駆動設計のような本質視点の開発をエンジニアやドメインエキスパートと一緒におこなっていき、よりよいサービス提供ができるかもしれません。

Slide 49

Slide 49 text

少なくとも、エンジニアとデザイナのコミュニケーションの促進やより現実に沿ったプロトタイピングなどができます。

Slide 50

Slide 50 text

UIデザイナーもコードや設計と友達になろう！