【勉強会】「UX Sketch」vol.1:事業企画とUXのコンセプト設定について
本日も勉強会メモです。事業計画とUXという非常に渋めなタイトル!事業会社でのお話から受託のお話まで、幅広く伺うことができました。戦略的になんでもやるのが大事なんだなあ。
開催概要
- MTL勉強会「UX Sketch」vol.1:「事業企画とUXのコンセプト設定について」
- 日時 :2015年6月26日(日) 19:30〜22:00
- 場所 :MTLcafe
- 目的 :Media Technology Labでは、6月26日(金)19:15~22:00にUXについて考える勉強会「UX Sketch」を開催。初回は「事業企画とUXのコンセプト設定について」
プロダクトオーナーの隣でUX導入した話(竹中哲 ランサーズ)
なぜUXを考えるのか
- 入社時に「今よりサービスをかっこよくして!」といわれてはいった
- だが実際のニーズは「今よりサービスを使いやすくして!」だった
- そういうことならとUXを導入
- 当時の組織が抱えていた課題:
- 増えるメンバー、増えるコンテンツ
- つぎはぎリニューアル
- いつのまにか追加される新規機能
- デザイナーに与えられた課題:
- 中長期含めて、成果を生むプロダクト
- 統一されたプロダクト品質を保つ
- そこでやったこと
- Coineyのデザイン指標「3つのE」を参考に、Lancersのデザイン指標を考えてみた
- Capitalize 使えるか?
- Communicable 伝わるか?
- Charm 魅力的か?
- そしてこれに当てはまらないものは作らない、と宣言した
- Coineyのデザイン指標「3つのE」を参考に、Lancersのデザイン指標を考えてみた
- UX原則策定前は、新規機能のLPでは淡々と機能を説明していた
- UX原則制定後は、「モノ」より「コト(体験)」を説明する文言にした
- 「顔の見えない取引から顔の見える取引へ」
- そうして「ユーザーが何が起きるか理解でき、使いたくなる」、魅力的なプロダクトを作れるようになった
どうUXを考えたのか
- UXの社内浸透のためにやったこと
- 発言の回数を重ね、価値観・目線を合わせる
- 呼ばれて無くても反応する
- 社内勉強会
- 前者懐疑で低減・宣言
- ユーザーインタビュー
- ワークショップ
- 小さなことから、だんだんできることが増えていった
- そんな中で一つ、うちのPMの特徴を発見した。それは「バズった施策に飛びつきやすい」ということ
通常、UXフローは、開発の最初と最後に導入しやすい(逆に言うとチャンスを逃すと挽回がむずかしい)
- cf. 「UXナンパ」:相手が望むタイミングに合わせて提案すると、UXが導入しやすい
- 【勉強会】UXなまトーク_150225 - Curiosity
トリガーが外部要因(世間でバズってた、みたいな)でタイミングが急でも、始まってしまえばこっちのもん
- 様々なバズワードに乗っかり、かたっぱしから実践していった
- ペルソナ策定
- UX指針
- ポジション分析
- ペーパープロト
- DesignSprint
- などなど
- このうち、ペルソナはマストでやるべき。なぜなら開発者は主観に陥りやすいから
- ランサーズではペルソナは20個位つくってる
- そしてデザイナーはポジション分析がマスト。その目的は、オーナーとの認識合わせ
- これも10種くらいつくった
- どれが効果的だった、とかは正直あまりなく、どれもやらないよりはやった方が効いた
- UXがあればなんとかなる、は幻想。上流と開発サイドの認識合わせと、時代に合わせた課題設定は常に必要です
すぐできるUX実践
- これまでの状況
- 定量分析:GAは全社員が見に行ける状態
- 定性分析:
- 問い合わせ内容は、サポートチームなど一部の人のみが見れる状態
- サポートがとりまとめ、依頼として上がってくるものを対応
- そこで、「疑うわけじゃないんですが、生の声が見たいです」と言ってみた
- → お問い合わせの内容がチャットで随時流れてくるという状況ができた
- → ディレクタ・デザイナ・エンジニアが、内容を見て、即座に改善に動ける世界になった
- ただしこういう試作は、時期とリソースと対応者次第では形骸化しちゃう場合もある
- なのでサービスの特性に合わせてやっていくとよい
- ほかにもこんな分析をしています
- ユーザーと同居(!?)
- インターンや新人研修でサイトを操作してもらう
まとめ
質疑応答
- (司会)ペルソナが20あるということですが、それだけの数が必要だったということですか?
- (竹中)たまたま10だったということで、数に意味はないですね。性別、年齢、職業などの属性を洗い出して行ったら10は簡単に超えて、そこから特に重視したいところを選ぶと10になったという感じです。作る機能毎に、どこのターゲットにたいして作るのかという認識を合わせるためにペルソナを使っています
- (司会)ポジションマップもたくさんありますね
- (竹中)マップは本当にずっと作っていました。社長が暇そうにしていたらすぐ捕まえて作ってたので、嫌われました(笑)
- (司会)ポジションマップの更新頻度は?
- (竹中)うちでいうと、1年に1回くらい。あと気をつけているのは、役員やオーナーが変わるタイミングでぜったいやるという点です
- (会場質問)お問い合わせをチャットに流すことについて、形骸化しないための施策ってなにかありますか
- (竹中)お問い合わせの中でも気になるものをリスト化して、それを常に更新するようにしていました。すでにサポートチームにそういうリスト化のフローがあったので、自然とできるようになっていきました
- (会場質問)UXのガイドラインって、他社さんと組むときにはどうしているの?
- (竹中)あんまり外部の方に押し付けるようなことはしないように考えています。とはいえこれまでの外部連携は単発のキャンペーンが多くて、一緒にサービスをつくるところまで(=UXについて議論するところまで)はあまりなかったです。ただ今後は、そこまで踏み込んでやりたいなと考えています
事業とUXデザイン(馬場沙織 リクルートテクノロジーズ)
事業とUXデザイン
- UXとUXデザイン
- エクスペリエンスのデザインプロセス
- 人間中心設計
- ユーザーからのフィードバックを得てPDCAを回す
- ユーザーと組織、両方の要求を満たすようにする
- 人間中心設計
- 事業フェーズにより、UXデザインの目的(ビジネスニーズ)が変わる
- 一番大きな分岐点はスケール可能なビジネスモデルが成立しているかどうか
- ビジネスモデル成立後のUXデザインの目的:成長
- ビジネスモデルからブレークダウンした各種指標向上が中心
- ビジネスモデル成立前のUXデザインの目的:探索・検証
- ビジネスモデルとサービス・プロダクトコンセプトの同時探索・検証が中心
事業フェーズとUXデザイナーの役割
mixiの事例紹介
ノハナの事例
- 関わった時期:2012年〜2014年
- 社内企業精度で初期メンバーとして参加
- リリース前のビジネスニーズ:事業計画立案
- ターゲット市場のカスタマーニーズを把握したい
- サービス・プロダクトの初期コンセプトの設計をしたい
- これに対応するため、野良ユーザーインタビューみたいなことをやっていた(予算があるわけではなかったので)
- リリース後のビジネスニーズ:ビジネスモデル探索
- 運用コスト削減のためにサービス・プロダクト改善をしたい
- アップセル・クロスセルのために、サービス・プロダクトコンセプトの設計・実装・評価
- 詳細はこちら → http://www.slideshare.net/SaoriBaba/uxer
勉強サプリの事例
- 関わった時期:2015年4月〜
- ビジネスニーズ:追加投資獲得
- 追加投資獲得のために各種指標向上させたい
- 成果を上げるための環境づくりをいまやっているところ
UXよもやまばなし
- ビジネスニーズを分かるためには、ビジネスのお作法をしらなければならない
- とくにビジネスシーンでは数字をメインに語るので、デザイナーとして自分たちのビジョンを語るためにちょっとずつ数字を使うようにしてきた
- カスタマーだけ見ていても、サービス全体のパフォーマンスは上げられない
- 外側のシステムと内側のシステム、両方のパフォーマンス向上が必要
- UXデザインをサービスデザインに使おう!
- UXとブランドデザイン
- UXはフロー(一時的UX)とストック(エピソード的UX、累積的UX)の両方を含む概念
- ストックの評価:満足度評価→ブランド評価
- ストックを向上させて、継続・獲得につなげよう!(予期的UX)
質疑応答
- (司会)最初に出てきた人間中心設計の考え方のなかに、事業企画要件とユーザー要件の両方を満たすと書いてあったんですが、それらは両方共ちゃんと満たしきれていると感じますか?
- (馬場)そこが難しいからUXデザイナーの仕事があるんだと思います(笑)
- (馬場)事業でも組織でも、まず何をするにも目標設定が必要になりますよね。組織では目標達成が体制の問題であったりリソース管理の問題であったりで複雑になりがちです。でも、そういうところにも働きかけるようにしないと最終的にユーザーまで価値を届けることはできないので、UXデザイナーとしてできることはなんでもやろうと思ってやっています。最近はUXという言葉も一般的になってきているので、経営陣もそのへんを良くしたいというのは当然考えるようになってきています。ただ具体的になにをすればいいかというのは当然わからないので、そこに対して働きかけていっています
事業企画とデザイン(西村和則 root inc.)
- よくある意思決定者とデザイナーのやりとり
- 言ってることが抽象的で絵に起こしづらい
- 言われたまま作ると修正の回数がやたら多い
- 意思決定者の意見がころころ変わる
- 見栄えはすごくいいけど結果がでない
- いまもとめられているデザイナー像
- サービス開発におけるデザイン:表面的な制作デザインだけでは成り立たない
- ユーザー体験の設計も含めたデザインスキルというものが求められている
- 今日のゴール:事業企画をプロダクトに変換する第一歩を身につけること。その考え方を伝えます
課題解決のアプローチについて
- rootでやっていること
- とあるクライアント(ベンチャー企業)さんと、事業立案フェーズからフロントエンド開発までいっしょにやっていった
- 当然ながら、課題は山積み
- 制作の前にまずは、解決すべき問題を定義する必要があった
- そこでまずは、問題を整理してみた
- 組織課題:やりたいことが多い、ソリューションばかり考えて実行に落ちない(創りたいプロダクトがあるので、それをつくってくれと言われるとか)、などなど
- プロダクト課題:既存ユーザーの意見に引っ張られる(本当にやりたいことが実現できなくなってしまう)、競合プロダクトを参考にアイデアを考える、などなど
それぞれの解決に向けたアプローチについて詳しく見ていきます
組織課題に対してのアプローチ:
- ビジネスと開発、双方の計画には大きな乖離があり、これらは対立しがち(ビジネス側の要望だといつまでに公開したい…とか、一方開発側はできないとか)
- この状況で機能要件を考えたりすると、議論がいつまでも終わらないということになる
- なのでデザイナーは、ビジネスと開発との中立的なポジションでコミュニケーションを取っていく必要がある = 両者の橋渡し的な役割を担う
- 具体的には、事業フェーズごとに解決すべき問題にプライオリティをつけていった
- プロダクト課題に対してのアプローチ:
- 機能要件は、実現すべきユーザー体験を定義することから始まる
- プロダクト課題の解決に向けた流れ
- 実現すべきユーザー体験の設計
- ユーザー体験にそって必要なソリューションをピックアップする
- それに対して何を機能化するのかを定義(ここで機能要件の策定)
- 実現すべきユーザー体験にプライオリティをつけ開発計画に落とす
- ユーザーとのコミュニケーションの最適化(ビジュアルデザインやライティング)
- 実現したいユーザー体験から逆算して、「常に立ち返るべき問題を定義しておく」ことが大切
今日からできる「問」の定義
- ○○をデザインしてほしいと言われたら「なぜ?」を繰り返す
- 事業企画者の「これをつくりたい!」に対して、なんでこれを創りたいのか?というのをしつこく問うていく
- 創りたいものを考える前に、実現したい提供価値(UX)を定義しなければならない
- デザイン思考のプロセス(共感 → 問題定義 → 想像 → 試作 → 検証)も、まずは対象を深く知ることから始まる
- 「誰のためのデザイン?」を読んでみよう
- ハイブリッド型デザイナー「デザインディレクター」が必要とされる時代です!
質疑応答
- (司会)クライアントから依頼がきた時点で、「そこで認識されている課題は違うものだ」という前提で進めていくのがいいんですかね
- (西村)そうですね、そのパターンが圧倒的に多いですね。UXデザイナーが入ってる状況で依頼がきたのであればそのままでもいいのかもしれませんが…。「なぜ」を考えないで進めた場合は、表面的なデザインが評価されたとしても、事業的には評価できないということになりがちだと思います