Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PMがUXするために必要なのは多分IA / IA for PM
Search
Kotaro Kokubo
October 24, 2018
Design
10
11k
PMがUXするために必要なのは多分IA / IA for PM
PMCONF 2017 の UX トラックでの講演資料です
Kotaro Kokubo
October 24, 2018
Tweet
Share
Other Decks in Design
See All in Design
Карта процесса-опыта. Презентация метода
ashapiro
0
330
Design System for training program
mct
0
130
エムスリー株式会社 デザイングループ紹介資料 / m3design-team-profile
m3designer
0
4.8k
開発チームの中心で心理的安全性をつくる、UXデザイナーの問いかけ方
takuto_yonemichi
2
580
効果的な管理画面を デザインをするために 避けるべき5つの罠
takanorip
14
6.1k
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
1
150
ABEMAの進化 – 複雑化したコンテンツ構造とUI改善への道 – / abema-ui-improve
cyberagentdevelopers
PRO
2
410
ユーザーに向き合うデザインが介護・福祉の現場を変える / User-facing design changes the field of care and welfare
sms_tech
0
140
20241019-CUD友の会「困った!を解決するデザイン改訂版」交流会
majimasachi
0
260
root COMPANY DECK / We are hiring!
root_recruit
1
15k
デザイナー視点の体験設計とデザインレビューを事業部全員で体験するワークショップをしたお話
masayofff
3
210
Managing Design Systems (Smashing NY 2024)
nathanacurtis
2
300
Featured
See All Featured
Bash Introduction
62gerente
608
210k
Practical Orchestrator
shlominoach
186
10k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
130
The Pragmatic Product Professional
lauravandoore
31
6.3k
10 Git Anti Patterns You Should be Aware of
lemiorhan
655
59k
Embracing the Ebb and Flow
colly
84
4.5k
Designing for humans not robots
tammielis
250
25k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
Transcript
株式会社 CAMPFIRE ⼩久保浩⼤郎 PMがUXするために必要なのは多分IA
None
IA とは(雑) • IA = Information Architecture です • IA
は職種ではなくスキルセットです • プロダクト開発に関わるすべてのジョブロールの⼈が持っ ていていいスキル • 抽象的に情報を扱うスキル、程度に考えてください • 今⽇の話は、⼤体 IA っぽい領域の話だと思ってください
• UX is 何? • ユーザビリティと UX • マーケティングと UX
• UI と UX • 名前重要
UX is 何?
Experience User Service/Product
Experience User Service/Product Context/Environment 広告、レビュー記事、⼝コミ 利⽤デバイス、利⽤環境・シーン
UXは環境やコンテキストに依存する • ユーザーと対象(サービス、プロダクト)という ⼆者の間の話のように聞こえるがそうではない • それらを取り巻く環境やコンテキストにその認知は ⼤きく依存する • UX を考える時はユーザーの利⽤環境、マーケット認知、
社会的認知など様々なレベルのコンテキストを考える 必要がある • 別に新しい話ではなく、できるデザイナーは 昔からそこを分かっていて考えてやっていた
User Experience とは 発明されたのではなく 発⾒された概念である 詳しくは「UX⽩書」やその解説をおググりください
ユーザビリティとUX
「道を歩く」のユーザビリティ Case 1
None
None
Success! Great Usability!
ユーザビリティ = 予測可能性
But…
Is there any experience? Past Present Future
「道を歩く」の Experience Case 2
None
None
None
! Experience!
これらの違い
Prediction Expectation Result Case 1
Prediction Expectation Result ! Case 2
Prediction Expectation Result ! Gap! Case 2
Prediction Expectation Result Gap Micro Experience Unit
Experience User Service/Product Context/Environment
マーケティングとUX
対象ユーザーのペルソナを どう考えるか
プロダクトライフサイクルや マーケットへの普及のステージ によって対象ユーザー像は変わる
Product Lifecycle Introduction Growth Maturity Decline
Diffusion of Innovation Innovator Early Adopter Early Majority Late Majority
Laggard
対象ユーザーペルソナが変わると プロダクトデザインの何が変わる?
学習曲線のデザインが変わる Type B Type A
何に対する学習度か? • サービスの提供価値や動作概念に対する理解度 • 利⽤習熟度A(よく使う機能を意識せず素早く使える) • 利⽤習熟度B(⾼度な機能を⾒つけて使いこなす)
Innovator Early Adopter Early Majority Late Majority Laggard Type A
Type B
• 新しいものへの興味が強い • 難しいことも理解しようとする • 絶対数は少ないがオピニオンリー ダーとして影響⼒がある • カーネマンのシステム2的 Type
A Type B • ⼈が使っているもの、流⾏ってい る物を使いたがる • 理解するのが難しいと使わない • 絶対数は多い • カーネマンのシステム1的 • ⾒た⽬が美しく魅⼒的 • 操作に必要なサインの提⽰ • ⼀度に処理すべき情報量が少ない • 動作モデルが理解可能 • 慣れた予測で素早く操作可能 • ⼀覧性が⾼く情報量が多い ϖϧιφ ·ΕΔUI
UIとUX
PMが考えなきゃいけないモデルたち Business Model System Model Product Mental Model
System Model Mental Model システムがどのように 動作するか(事実) システムがどのように 動作するように⾒えるか(認知) これらをいかに⼀致させるか またはさせないか
システムモデルとメンタルモデル • これらは単純に⼀致させればよいというものではない • 効率的で合理的なシステムの動作モデルと、ユーザーがわ かりやすく使いやすいと考えるモデルは違うことは多い • どちらかが先に決定するわけではなく、相互に影響しなが らできあがることも多い •
おそらく昔はシステムモデル先⾏だったが、ユーザビリ ティや⼈間中⼼設計といった概念の普及により改善された • UXという概念の普及もこの流れの⼀環と⾔える
System Model Mental Model システムがどのように 動作するか(事実) システムがどのように 動作するように⾒えるか(認知) これらをいかに⼀致させるか またはさせないか
Mental Model Designer’s Model User’s Model
Mental Model Designer’s Model User’s Model User Interface こう思わせたい(意図) こう思った(認知)
デザイナーズモデルとユーザーズモデル • これらは常に可能な限り⼀致させたい • それをどううまくやるのか、というのが UI デザイン • UI を通してユーザーがデザイナーズモデルを理解する
• その理解の結果がプロダクトに対するメンタルモデル
System Model Designer’s Model User’s Model Product
System Model Designer’s Model User’s Model Product
ターゲットペルソナは複数いる • プロダクトライフサイクルやマーケットへの普及のステー ジによって対象ユーザー像は変わる • 対象ユーザー像が違えば提供すべきメンタルモデルも違う • 提供すべきメンタルモデルが違えば UI が違う
つらい
名前重要
「モデル」とか「理解」とか ⾔ってるけど ⼈はそもそも物事を どのように理解するのか
理解 = 分かる = 分かつ
理解 = 分かる = 分かつ • ⼈は物事に名前がついて初めてそれを他のものと区別する ことができる • あるふたつのものが本来的に存在するのではなく、別々の
名前をつけることによって⼆つの存在に分離する • 分かつことによって、その抽象的性質を帰納的に推論でき るようになる • この抽象モデルを⼿に⼊れることが「理解」
名前重要 (Ruby の⽣みの親 まつもとゆきひろ⽒) by Matz
System Model Designer’s Model User’s Model • オブジェクトモデル • スキーマ、DB
カラム • クラス、メソッド • 変数 • UI エレメント、 コンポーネント • UI ラベル、⽂⾔ • ⾊、スタイル • UI ラベル • ⽂⾔のトンマナ • オブジェクトの名称 • ⾏為の名称 User Interface これらをいかに⼀致させるか またはさせないか
基本的なところは統⼀した⽅が良い • システムの根幹的な概念や動作モデルに関する名称 • 主要なオブジェクト達(名詞) • それらが取りうる振る舞い(動詞) • 利⽤シーンにおけるユーザーの区別(名詞) •
ユーザーが取りうるアクション(動詞)
統⼀する利点 • 開発チーム内のコミュニケーションの効率化 • バックエンド、フロントエンド、デザイン、コピーにおけ る名称の⼀貫性 • システムモデルとメンタルモデルの差異が 意図的か否かが分かる •
開発ドキュメントが書きやすく、読みやすく • マニュアル、FAQ、マーケティングにも⼀貫性 • 新しい概念に対する命名の必要性判断の⼟台
名前重要 (Ruby の⽣みの親 まつもとゆきひろ⽒) by Matz
おすすめの本
PMがUXするために 必要なのは多分IA