designing ux development

26
KLab 株式会社 開発制作本部 第五開発制作部 VoQn http://voqn.github.com Designing UX Development よりよい UI / UX を提供する 組織と手法のデザイン あるいは組織内戦略

Upload: mizushima-kazuhiro

Post on 24-May-2015

2.924 views

Category:

Documents


0 download

DESCRIPTION

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

TRANSCRIPT

Page 1: Designing UX Development

KLab 株式会社 開発制作本部 第五開発制作部VoQn http://voqn.github.com

DesigningUX Developmentよりよい UI / UX を提供する組織と手法のデザインあるいは組織内戦略

Page 2: Designing UX Development

What’s this ?”UI / UX ほげふが” なる肩書きが増えている昨今

そうした人材を必要とされる気運が高まっているけれど

実際どうなのよ? どう使うのが本当にいいのよ? という話

Page 3: Designing UX Development

Agenda• Ideal & Real - 理想と現実

• Where is “Experience” ? - それはそうと

• UX = System >>= Culture - そもそも

• Developer’s Sadness - これがつらい

• Positioning - こうあるべき

• Aiming for Victory - こうしたい

• How should it begin - どうすればよいか

• Homework - しゅくだい

Page 4: Designing UX Development

Ideal & Real•「UI / UX の質を高めれば…」• 売上が上がるわけではない• 別の因子の方が大きく働く

• 「ターゲットにマッチしたマーケティング」

• 「ライバルの不在 / ライバルに対する優位」

• 「UI に対する慣れ」で時間的に解決されてしまう事も

• 工数が短縮されるわけではない• 原理的に関係ない

• 的確なコンセプトワークで手戻りが減る→短縮はありうる

• 下手な運用次第では逆に時間がかかりうる

Page 5: Designing UX Development

Ideal & Real•「UI / UX の専任がいれば…」• タスクを一任できるわけではない• タスクは複数の領域に跨ぎ、常に別の専門の協力が要る

• 一任できるタスクは「コンセプトワーク」くらい

• 分業が進むわけではない• むしろ全てにおいて「兼任」になってしまう

• 常に「どっちつかず」を懸念される存在

• 「見通しの良い計画…」にはならない• むしろ「レビューによる再考」上等スケジューリング

• 最後までリテイクを受け入れる覚悟が要る

Page 6: Designing UX Development

Where is “Experience” ?

F I UInterface UserFunction

Product / Service

Input

OutputInteraction

C

SocietyCommune

Page 7: Designing UX Development

Where is “Experience” ?

F I UInterface UserFunction

Product / Service

Input

OutputInteraction

C

SocietyCommune

User InterfaceUser Experience

Page 8: Designing UX Development

UX = System >>= Culture

•ハードウェア、ソフトウェア問わず•プロダクト / サービスを提供し•ユーザー文化圏の中で利用され•ユーザーが”体験・体感”するモノ•だから UX Developer は全部やる• ただ、「UX、UX」って呼んでても「体験、体験」って呼んでても、曖昧すぎるし、ゲシュタルト崩壊するし、ぶっちゃけ「UXの専門家です(ドヤ顔)」みたいな人、きらいだし信用できない

Page 9: Designing UX Development

UX = System >>= Culture

• UX は設計しても再現性が「無い」• 設計、設定したところでユーザーに必ずに体験させられるものではない(そりゃそうだ)

• 感じ方や使い方はユーザーの自由ゆえに設計者は結局「あんなこといいな、できたらいいな」のレベルを超えられない

Page 10: Designing UX Development

Developer’s Sadness•UXの因子 「全部やれってか?」• エンジニアリング - Program/System• デザイニング - Concept/GUI/Layout• スタイリング - Style/Image/Decoration• マーケティング - Research/Promotion

Page 11: Designing UX Development

Developer’s Sadness•「わかったよ! 全部やればいいんでしょ!?」• ディテールに深く手を入れるヒマなし• 手付かずを埋めるだけで時間を食われる• 忙殺されてそもそものUXを見直すヒマなし• 気がついたら出来が悪いモノに• これ、よく経験したし、黙ってやってると確実にこうなる

Page 12: Designing UX Development

Developer’s Sadness

•「ディレクションに徹するから 細かいのは各自お願い」• メンバー「口だけのウルセー目の上のタンコブだな…」

• 上司「皆は頑張ってたけど結局キミ何やってたの?」

• ここらへんの憂鬱はよくあるディレクターやマネージャーの悲哀と同じ

• 実は UX Developer の一番正しい人材運用の仕方

Page 13: Designing UX Development

Positioning•UX 設計・開発はシングルコンバットで出来る事じゃない

• 機能に関わる全てを以って初めて「狙い通りに体験してくれるかも…」というモノ

• つまり全部の面倒を見れる技能と知恵を必要とするし、発揮できる状況が求められる

Page 14: Designing UX Development

Positioning•「戦線に立つディレクター」• 進行・調整のディレクションではない• プロダクトの”出来”を専ら監査するディレクター

• いざとなったらそれぞれの前線に入れるスキルと知識が必要

• しかしいつまでも前線にいたらいけない• スタイリストは別要員にすべき

Page 15: Designing UX Development

Aiming for Victory•「戦線に立つディレクター」として運用してもらうために• 何も言わず黙ってると「エンジニアのタスクも投げられる便利なデザイナーさん」として使い潰される

• 「ディレクター? 企画が兼任でいいだろ」になりがち

• 「人手が足りないから開発もデザインも出来る人をとりあえず  ”UXデザイナー” ということで全部やらせました」「エンジニアリングの都合もわかってくれるデザイナーに 全部つじつま合わせてもらいました」 が大抵の真相だったりする

Page 16: Designing UX Development

Aiming for Victory•まずは組織的に認められるように•利益を出して工期も短縮しちゃう•↑さっき売上に貢献しないとか言ったじゃん!

•↑工期の短縮に貢献しないとも言ったじゃん!

•まぁ聞いてくださいよ

Page 17: Designing UX Development

Aiming for Victory• UX Developer をチームに入れて• Design Principles (デザイン原理) を定めさせる

• 徹底したコンセプトワークをさせる• 一貫したコンセプトの元でのデザインワークやエンジニアリング

• マーケティングの精度向上や手早いスタイリング、リテイクも狙えないわけではないよね?

• 事業主にはここで納得していただく

Page 18: Designing UX Development

Aiming for Victory• UX Developer がチームにいることで• メンバーが「いいゾ~これ」って思ってくれるようにDeveloper が働く

• 上長も「面倒みる部分(質の高さとか)が減って嬉しい!」と思ってもらえるように働く

• ディレクターが「進行の把握と計画調整だけになって助かるわ~」と楽になるように働く

• 生々しいハナシですね!!!

Page 19: Designing UX Development

How should it begin?

• 普通にやってると「開発もデザインもできちゃう便利屋」にされてしまうことは前述した

• これまで UX Developer が居なかった場所では”仕事の分担”を分けてもらう必要がある

• 受け入れ態勢が出来てなかったり、”それ”を期待されてない事多々あり

「いや、黙ってコードも書いてデザインもやれよ」って言われないように

Page 20: Designing UX Development

How should it begin?• (その1) ワーキングフローそのものをUX Developer が改善させる

• 自分の職場を UX 設計・開発の対象として演習• これ自体チームメンバーにとって、UX 設計・開発をよく理解してもらう好機になる

• UX Developer にとっては良い練習にもなる• チームの性格で馴染むワークフローが違うので合ったやり方を見極めるのが重要

Page 21: Designing UX Development

How should it begin?• (その2) 企画が持ってるプロダクトの「一番大事なこと」を最大限に引き出す

• (たぶんしたことが無かったであろう)Design Principles の設計

• これまでに無い程の骨太のコンセプトワークをやってみせる

• デザイナーが楽を感じれたらしめたもの

Page 22: Designing UX Development

Homework• (1) 今の自分とチームの取り組み方をUX開発対象として分析する

•ユーザーは自分を含めたチームメイト•仕事のゴールは何だったかの確認•今抱えている問題・課題は何か自分らの問題を考察も解決もできずに見知らぬユーザーのUXなんか考えられるわけないだろと自分に言い聞かせよう

Page 23: Designing UX Development

Homework• (2) 外部要因に依らない、宿題 (1) の問題を改善するアイデアを出す

• 他所様の所為にしてれば楽だけど一向に良くなったりせんよね

• 実際にプロダクト出した時に「”他の所為” でUXが実現しませんでした」とか情けない言い訳できないよね

実際の UX 開発も外部要因は考察と分析の対象であって、設計自体は内部要因をどうするかしか出来ませんと自分に言い聞かせよう

Page 24: Designing UX Development

Homework• (3) 今抱えてる案件のグランドコンセプトをもう一度言語化する

• グランドコンセプトって案外やってるところ少ない創業100年かつデザイナー専用スタジオ持ってる超大手メーカーくらいしかやってないのでは

• 宿題(2)がこれだけで解決されることあり

実際の UX 開発もグランドコンセプトからと自分に言い聞かせよう

Page 25: Designing UX Development

Homework - Hint

•ヒアリングはすべての基本•因果関係の根を探れ•「様々な工夫」より「一つの突破口」•シンプルであるほど強いと知ること案外「お菓子食べながら雑談する時間をつくる」みたいな施策で拍子抜けするくらい上手く行ってしまうことだってあるよ

Page 26: Designing UX Development

Next

よりよい UX を提供するために何を知るべきか

What learn forUX Development

お楽しみに