• Like
Designing UX Development
Upcoming SlideShare
Loading in...5
×

Designing UX Development

  • 2,806 views
Uploaded on

UX Developer の人材運用の現実と求められる理想の運用方法 …

UX Developer の人材運用の現実と求められる理想の運用方法
ならびに、それを実現する為の立ち振舞い その1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,806
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
16
Comments
0
Likes
25

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. DesigningUX Developmentよりよい UI / UX を提供する組織と手法のデザインあるいは組織内戦略KLab 株式会社 開発制作本部 第五開発制作部VoQn http://voqn.github.com
  • 2. What’s this ?UI / UX ほげふが なる肩書きが増えている昨今そうした人材を必要とされる気運が高まっているけれど実際どうなのよ? どう使うのが本当にいいのよ? という話
  • 3. Agenda• Ideal & Real - 理想と現実• Where is “Experience” ? - それはそうと• UX = System >>= Culture - そもそも• Developer’s Sadness - これがつらい• Positioning - こうあるべき• Aiming for Victory - こうしたい• How should it begin - どうすればよいか• Homework - しゅくだい
  • 4. Ideal & Real• 「UI / UX の質を高めれば…」 • 売上が上がるわけではない • 別の因子の方が大きく働く • 「ターゲットにマッチしたマーケティング」 • 「ライバルの不在 / ライバルに対する優位」 • 「UI に対する慣れ」で時間的に解決されてしまう事も • 工数が短縮されるわけではない • 原理的に関係ない • 的確なコンセプトワークで手戻りが減る→短縮はありうる • 下手な運用次第では逆に時間がかかりうる
  • 5. Ideal & Real• 「UI / UX の専任がいれば…」 • タスクを一任できるわけではない • タスクは複数の領域に跨ぎ、常に別の専門の協力が要る • 一任できるタスクは「コンセプトワーク」くらい • 分業が進むわけではない • むしろ全てにおいて「兼任」になってしまう • 常に「どっちつかず」を懸念される存在 • 「見通しの良い計画…」にはならない • むしろ「レビューによる再考」上等スケジューリング • 最後までリテイクを受け入れる覚悟が要る
  • 6. Where is “Experience” ? Input F I U CFunction Interface Output User Commune Product / Service Interaction Society
  • 7. Where is “Experience” ? Input F I U CFunction Interface Output User Commune Product / Service Interaction Society User Interface User Experience
  • 8. UX = System >>= Culture• ハードウェア、ソフトウェア問わず • プロダクト / サービスを提供し • ユーザー文化圏の中で利用され • ユーザーが 体験・体感 するモノ• だから UX Developer は全部やる• ただ、「UX、UX」って呼んでても「体験、体験」って呼んでても、 曖昧すぎるし、ゲシュタルト崩壊するし、ぶっちゃけ「UXの専門家 です(ドヤ顔)」みたいな人、きらいだし信用できない
  • 9. UX = System >>= Culture• UX は設計しても再現性が「無い」 • 設計、設定したところでユーザーに 必ずに体験させられるものではない (そりゃそうだ) • 感じ方や使い方はユーザーの自由ゆえに 設計者は結局「あんなこといいな、できたらいいな」 のレベルを超えられない
  • 10. Developer’sSadness• UXの因子 「全部やれってか?」 • エンジニアリング - Program/System • デザイニング - Concept/GUI/Layout • スタイリング - Style/Image/Decoration • マーケティング - Research/Promotion
  • 11. Developer’sSadness• 「わかったよ! 全部やればいいんでしょ!?」 • ディテールに深く手を入れるヒマなし • 手付かずを埋めるだけで時間を食われる • 忙殺されてそもそものUXを見直すヒマなし • 気がついたら出来が悪いモノに • これ、よく経験したし、黙ってやってると確実にこうなる
  • 12. Developer’sSadness• 「ディレクションに徹するから 細かいのは各自お願い」 • メンバー「口だけのウルセー目の上のタンコブだな…」 • 上司「皆は頑張ってたけど結局キミ何やってたの?」 • ここらへんの憂鬱はよくあるディレクターや マネージャーの悲哀と同じ • 実は UX Developer の一番正しい人材運用の仕方
  • 13. Positioning• UX 設計・開発はシングルコンバット で出来る事じゃない• 機能に関わる全てを以って初めて 「狙い通りに体験してくれるかも…」 というモノ• つまり全部の面倒を見れる技能と知恵を 必要とするし、発揮できる状況が求められる
  • 14. Positioning• 「戦線に立つディレクター」 • 進行・調整のディレクションではない • プロダクトの 出来 を専ら監査するディレクター • いざとなったらそれぞれの前線に入れる スキルと知識が必要 • しかしいつまでも前線にいたらいけない • スタイリストは別要員にすべき
  • 15. Aiming for Victory• 「戦線に立つディレクター」として 運用してもらうために • 何も言わず黙ってると 「エンジニアのタスクも投げられる便利なデザイナーさん」 として使い潰される • 「ディレクター? 企画が兼任でいいだろ」になりがち • 「人手が足りないから開発もデザインも出来る人をとりあえず   UXデザイナー ということで全部やらせました」 「エンジニアリングの都合もわかってくれるデザイナーに 全部つじつま合わせてもらいました」 が大抵の真相だったりする
  • 16. Aiming for Victory• まずは組織的に認められるように • 利益を出して工期も短縮しちゃう • ↑さっき売上に貢献しないとか 言ったじゃん! • ↑工期の短縮に貢献しないとも 言ったじゃん! • まぁ聞いてくださいよ
  • 17. Aiming for Victory• UX Developer をチームに入れて • Design Principles (デザイン原理) を定めさせる • 徹底したコンセプトワークをさせる • 一貫したコンセプトの元での デザインワークやエンジニアリング• マーケティングの精度向上や 手早いスタイリング、リテイクも 狙えないわけではないよね?• 事業主にはここで納得していただく
  • 18. Aiming for Victory• UX Developer がチームにいることで • メンバーが「いいゾ∼これ」って思ってくれるように Developer が働く • 上長も「面倒みる部分(質の高さとか)が減って嬉しい!」 と思ってもらえるように働く • ディレクターが「進行の把握と計画調整だけになって 助かるわ∼」と楽になるように働く • 生々しいハナシですね!!!
  • 19. How should it begin?• 普通にやってると 「開発もデザインもできちゃう便利屋」 にされてしまうことは前述した• これまで UX Developer が居なかった場所では 仕事の分担 を分けてもらう必要がある• 受け入れ態勢が出来てなかったり、 それ を期待されてない事多々あり「いや、黙ってコードも書いてデザインもやれよ」って言われないように
  • 20. How should it begin?• (その1) ワーキングフローそのものを UX Developer が改善させる • 自分の職場を UX 設計・開発の対象として演習 • これ自体チームメンバーにとって、 UX 設計・開発をよく理解してもらう好機になる • UX Developer にとっては良い練習にもなる • チームの性格で馴染むワークフローが違うので 合ったやり方を見極めるのが重要
  • 21. How should it begin?• (その2) 企画が持ってる プロダクトの「一番大事なこと」 を最大限に引き出す • (たぶんしたことが無かったであろう) Design Principles の設計 • これまでに無い程の骨太の コンセプトワークをやってみせる • デザイナーが楽を感じれたらしめたもの
  • 22. Homework• (1) 今の自分とチームの取り組み方を UX開発対象として分析する • ユーザーは自分を含めたチームメイト • 仕事のゴールは何だったかの確認 • 今抱えている問題・課題は何か 自分らの問題を考察も解決もできずに 見知らぬユーザーのUXなんか考えられるわけないだろ と自分に言い聞かせよう
  • 23. Homework• (2) 外部要因に依らない、宿題 (1) の 問題を改善するアイデアを出す • 他所様の所為にしてれば楽だけど 一向に良くなったりせんよね • 実際にプロダクト出した時に 「 他の所為 でUXが実現しませんでした」 とか情けない言い訳できないよね 実際の UX 開発も外部要因は考察と分析の対象であって、 設計自体は内部要因をどうするかしか出来ません と自分に言い聞かせよう
  • 24. Homework• (3) 今抱えてる案件の グランドコンセプトを もう一度言語化する • グランドコンセプトって案外やってるところ少ない 創業100年かつデザイナー専用スタジオ持ってる 超大手メーカーくらいしかやってないのでは • 宿題(2)がこれだけで解決されることあり 実際の UX 開発もグランドコンセプトから と自分に言い聞かせよう
  • 25. Homework - Hint• ヒアリングはすべての基本• 因果関係の根を探れ• 「様々な工夫」より「一つの突破口」• シンプルであるほど強いと知ること案外「お菓子食べながら雑談する時間をつくる」みたいな施策で拍子抜けするくらい上手く行ってしまうことだってあるよ
  • 26. NextWhat learn forUX Developmentよりよい UX を提供するために何を知るべきかお楽しみに