tl;dr
初見エンジニア（ほぼ）が、それっぽい（失礼な書き方になるが、初見からすると正しいかどうか？は判断は出来ないのです 上から目線）資料を見て
UXの大事そうな要素を見つけてみる（正しいとは言っていない）
※ UXD,UX 探せば大丈夫とは思います
参考とした資料
なんとなく見えたもの
- UXとは
- (in 1)ユーザー個々人による主観の体験（「誰にとっても良いUX」は存在しない）
- (in 2)"体験"そのものは、ユーザーの個人的なもの
- (in 4)ユーザーとサービス、商品の相互作用すべてで、混乱や面倒無しで顧客の的確なニーズを満たし、所有する楽しさ、使用する楽しさを生み出す「簡潔さと優雅さ」
- UXD
- (in 2)どんな'体験'をしてもらうか計画すること、"体験"が量産・再生産される仕組みを作る事
- (in 4)期待・予感＞もらう・出会う＞触れる＞ずっと使う＞記憶・思い出
なぜUXをデザインしているのか
- 成果が出ているか？が大事らしいので、KPI的な指標設定が必要となる
- モノを作る工程があって、サイクルの構築(PDCA的な)が良いらしい
- 【体験】＞【行動】＞【継続】＞【モノ】＞【体験】に戻る
各工程についての理解とステップ間の連携を明確にすると良いらしい
-
一文で表すと仰っている
- 【体験】人々のハートを揺さぶるような
- 【モノ】Design＆Productを生み出し
- 【体験】世界をより良い方向に【行動】前進させる
- 【継続】資料では事業
私の考えるプロダクトマネジメントとUXデザインの関係
- UXは時間軸でとらえる 利用前/利用中/利用後/利用時間全体
- UXDのするためには、PdM/Biz/Designer/Developer で進めると良い
- → 共通のマインドが必要
- 共通のマインドを形成するために
- 共通言語づくり
- プロトタイピング
- AARRCC
- カスタマーサクセスタッチポイントの設計
- PdMはチームにインストールする存在
- 価値発見＞価値表現＞価値伝達＞価値提供 ⇒ 価値実現
- UXデザインはマインドセット
UXはじめの一歩
- UXは企業・組織・チーム毎に背景が異なり体系化できない
- ビジネス要件を通じて体験を提供して、ユーザーが対価を支払う
- ビジネス要件の分解
- 市場調査/競合調査/UXプロセス設計/ユーザー調査・プロトタイピング/どうしようもないやつ
- チーム作りをしている。
- トップを説得ではなく、作業者レベルで「ユーザーをみる」空気づくり
- UXで会社に貢献する姿勢
- 組織における居場所の作るステップ
- 信頼・成果 ＞ 信頼・成果 ＞ 信頼・成果
- できる・やった＞ できる・やった ＞ できる・やった
- 社内勉強会＞ユーザーテスト＞ユーザーインタビュー、分析 ＞事業部を巻き込んだワークショップ ＞サービス立ち上げにUX導入
- 導入のタイミングが大事
- 要件定義、改修機関がよいらしい
- 要件定義 ビジョン提案
- 開発期間 プロトタイピング
- 改修機関 改善アプローチ
- 手法は解決用途でなくて、議論の用途に利用するとよい
- 調査ｘ分析ｘ議論＝解決案
- まとめ
- 導入できる信頼を得る/ビジネスに共感する/小さな成果から始める/学習することをやめない
はじめてのUXとUIの話
- 記憶に残るかどうかは、人によって違うのでルール化できない
- でも多く記憶に残ってほしい ＞ クリエイターの使命であり挑戦する面白さ
- もの プロダクトデザイン/人間工学/インタラクション/ユーザビリティ
- 情報 認知心理学、情報アーキテクト、情報デザイン、情報工学
- Jonathan Ive のSimplifyが良い話らしい
- 洗練への過程（やる事とポイント）
- 機能・情報の整理 誰が分かりやすいの
- UIを考える 白黒のワイヤーフレームで
- ユーザーとして操作する ルールに基づいて整合性がとれているか？
大事そうなこと
- 始まるには、優秀な人がいないと失敗する
- 優秀であるかどうか判断ができたらそもそもUXDが出来てそうなので懸念してもしょうがない点ではありそう
- 成果に対しての工程とサイクル設計が必要
- チーム・組織への浸透のために活動が必要
- 共通の目的・課題意識
- 作業者レベルでの意識づけ
- 議論をしやすくするために、手法が多く持っているとよさそう
- 上記の知識・行動面の準備や理解が無い場合はやってはいけない
- 自分の言葉で話せない人はダメってことぽい