【レポート】「いいチーム」を育てるUX – CS HACK #07
こんにちは。デザイナーの たなかゆきこ です。 カスタマーサポートを愛してやまない人達が集まり、「CS」を徹底的にハックするCS HACKに参加してきました。今回はUXデザイナーによる組織作りをテーマに、ユーザーファーストな組織作りや横断したプロダクト作りができるチーム作りについてのお話ということで、当日の様子をレポートします。
イベント概要
https://cshack.connpass.com/event/66273/
世の中には多くのサービス、製品があります。そして同じ数だけカスタマーサポートが存在します。
このイベントではカスタマーサポートを愛してやまない人達が集まり、情報交換やディスカッションを通じて「CS」を徹底的にハックします。※CSには、CustomerExperience、CustomerService、CustomerSuccess、CommunityManager、UXデザイナー、UIデザイナー等のコミュニケーションが主となる職種を全て含みます。
「CS」をハックし深く知ることで"再現性"を高め「どんなサービスであっても最高のCS対応」が出来る世界を目指します。「CS」は素晴らしい仕事だということを広め、業界を盛り上げていくためぜひご参加ください詳しくはグループ詳細をご覧ください。
ちなみに"個人"で開催しています！ここ大事！
イベント詳細
UXでプロダクトを、チームを、ネクストステージに。
岡村 邦博 さん
ferret のUXデザイナー 岡村さんによる「チーム作りとチームでプロダクトにどうかかわっていくのか」の話でした。岡村さんは「デザイン組織を作るためにbasicにジョイン」されたそうです。
ネクストステージのチームってなに？
ネクストステージとは 「視野を広げて、価値を高める」
「デザインはデザイナーだけに任せておくには重要すぎる」 IDEO CEO Tim Brown
今の時代、デザイナー・デザインに求められるものが大きくなっている。それにあわせて、デザイナーも成長する必要がある。ビジネスに対しても、問題解決できるようにならないといけない。
IDEOの思想「優れたデザイン」は、グラフィックや造形だけでなく、世の中の問題点や課題を明確にして、解決策を導きだすことであると考えている
そういうことができるようになるのが、ネクストステージ だと思っている。
もちろん全部できないといけないわけではないし、いろいろな人がいるというのはわかっているとおっしゃっていました。
いいチーム＝一人ひとりの集合体
弱みをなくして、強みを最大化する
一人一人の能力が高いという訳ではなく、組織として成果をあげるチーム＝いいチームとして定義している
成果をあげるってなに
プロダクトやサービスによって違うが「チームでUXを最大化させる」という仮定で話す
チームの成長に比例して、UXが向上していくことを理想としている。 成果を出せるチーム→プロダクトの成長 「成果を出し続けること」UXで最大化
なんで、そのチームを作るのが難しいのか困っていること
- 企業の憂鬱
- デザイナーのノウハウがない。どうやってマネジメントしたらいいのか不明
- デザイナーってどこで能力評価するの
- 正直、デザイナーをどう扱っていいのかわからない
- デザイナー側
- 納期ファースト
- いわれたものをつくる。モチベーションあがらない。調査したいのに時間はもらえない
- しっかり評価されない
上記を埋めるには「いい関係性をもって取り組む」 みんなと創っていく
ギャップを埋める コミュニケーションで解決
- ウォーターフォールをやめて、スクラム開発
- ボタンを赤くしたい、ではなく、なぜお客さんは赤にしたいといったの？赤くしたいわけではないのでは？ただ目立たせたいのかもしれない
- それって、ユーザーテストとか数値でみたりするものじゃない？数値に基づいて実装を決めたい。
だからチームを創ろう
ベーシック＝WEBマーケティングの会社 2年半前：これからはデザイン組織を持つ企業が勝つ
- デザイン思考が一般にひろまってきた
- デザイン思考を行える組織を社内に持つことになる。先立ってやれるようになりたい。
なにから始めた
「チームってどうやってつくるの」から始めた。
- 姿勢：なぜやるか
- 合意形成。組織としてなにをやるのか
- なぜ、デザイン思考が大切なのかを、言い続けること
- うまく伝わらないこと＝デザイナーとしての武器（かっこいいものをつくる）
- 先にやっちゃう？
- デザイナーの裁量を増やす
- はやめに相談される関係性をつくる
- 調査をしたい
- テストをしたい
- 手法：どうやるの
- 成果を出す。測りやすい手法を使わないといけない
- 成果を出すには、早く結果を - デザイン思考やリーンスタートアップの実践と周知徹底
- ビジョン・ミッション：なにをするの
- なぜやるのか
- チームによってのビジョンは、同業他社にはなかった。なのでチームでのビジョンをつくった
- 育成・評価：未来のはなし・どうなるの。ここにいたらなにがあるの
- どういうものを求められているの？
- 会社としては、どういう状態になってほしいの？
- 個人としては、どうなりたいのを評価に組み込む
- 会社は、個人は今どのステージであるのかなどを明確にしていく
上記、4つでチームを作る チームとして、プロダクトのUXを最大化する＝成果を出す
事例
- ferret:WEBマーケティングに強くなるメディア
- ferret One : サイトを創って提供するCMS。マーケティグ一気通貫できるサービス
メンバーが大所帯のプロダクト。チームがたくさんある。 役割が設定されていて、それぞれにKPIが設定されている。
- ユーザーファーストが忘れられがちになってしまう。
- 縦割り組織だと目の前のKPIを追うことに捉われがちになる
- 「そもそも何がしたかったのか」を再度言わないといけない
- デザイナーはそれを解決できる「ユーザーはだれでしたっけ」と言える。仮説を立て、ユーザーヒアリングをして、分析できる。デザイン思考を持っている。
- 縦割り組織だと目の前のKPIを追うことに捉われがちになる
- なぜデザイナーができるのか
- 「横断して解決」UX改善は広い視野をもたないといけない
- マーケチームや広告から、アプリまで横断できるのはデザイナー
- オーダーベースになってしまうのを防ぐために、スクラムでストーリーを書く。なんでやるのかの背景を書く。これができるとどういうストーリーができあがるのか。
デザイナーも定量的に測れる数値を持つ方がいい。KPIをもちましょう
なんとなくかっこいいものを作るではなく、定量的にデザイナーの価値を作る。 横断しているチームのKPIの一個前のKPIをもつ
- マーケチームがリード数KPIをもつならば、デザイナーはリード数をとるための広告、APのクリエイティブの部分（コンバージョンレート）などの数値にデザイナーが責任をもつ
- カスタマーサポートチームがヒアリング数ならば、デザイナーはユーザーテストの数値を測れるように施作し、満足度数値に責任を持つ など
定量化することが大切
上記の取り組みで、グロースハックと、プロダクト評価UXデザインというキャリアパスを作っている。
いいチームの中で、キャリアパスを描けて、プロダクト改善ができればみんなハッピーになれる。
チームの相談
一緒に考えよう！みんなで考えるとなんとかなる
Q&A
顧客視点で考えるときに一番大切にしていること
- 毎週ユーザーヒアリング
- CSメンバーの中にデザイナーも入って、声を集める
- 声を集める
- ひとつの声じゃなくて、定量的なものを決めておく。方向性を決めておく
- ユーザーの声だからといって、必ずしも聞かなければいけないわけではない
- 声を集める
- POの価値ベースでむかっていくものを決める。どこに向かうのかなどを合意してきめていく。
横断するチームのKPIの数値に責任を持つ
- LPのコンバージョンレートなどを常にとっておいて、デザイナー自身がABテストを回す
ユーザーのためのデザイン。ユーザーのためのデザイン組織。
クラウドワークス 廣瀬 健 氏
今年3月「UXデザイングループ」というデザイン組織発足
単純なデザイナー組織ではなく、エンジニアなども含めたプロダクトに関わる人間を含めた組織 UXデザイングループは組織を横断的に関わる
- デザイナー・UXデザイナー・コピーライター・エンジニアで構成
- 定性調査（ユーザーインタビュー、ユーザビリティテスト）
- デザイン手法・文化の導入
なぜデザイン組織が必要だったのか
なかったころは、プロダクト開発にデザインが入ってなかった
- 必要なときにデザイナーがスポットで対応
- デザイナーとエンジニアはお互いのことをよく知らない
- エンジニア主導であったがために、デザイナーが全く関わらない機能がリリースされる。デザイナーがみるとこれダメじゃないかというものがリリースされる
そもそも「なぜデザイン」が必要か
Designとは問題解決を行うためのメソッドであり、ユーザー視点から”どう見えるか”よりも”どう機能するか”を主軸にしたプロセスである。 デザイナーとは職種ではなくマインドセットである http://blog.btrax.com/jp/2016/10/18/designer-mindset/
デザインとは問題解決をするメソッド=見た目だけのはなしではない
Designをつくるにはユーザーはいったい何を望んでいるのか？を考える
- そのときユーザーはどういう状態？
- そもそもユーザーはどんな課題を持っている
上記を考えた上で、デザインは出来上がる。UIがユーザーにとって、問題解決できるものであるのであれば、それはUXのデザインといえるのではないか。
デザインによって、プロダクトはもっとよくできる。だからちゃんとデザインを取り入れていきたい
どうやってプロダクトに取り入れる？
- デザインは、デザイナーだけでできるものではない。
- プロダクトに関わる人間がいっしょになってつくっていかないとつくることはできない。（協調的努力）
- デザイナーは、その中でデザイナーを中心にチームでデザインを考えることの必要性を訴え（デザインの理解）、どうやってプロセスを実践していくかを提案する立場にある。（デザイン思考を持っているから）
そのためにデザイン組織というものが必要だ
デザインを理解してもらうためにやったこと
見た目の話ではない。体験をデザインしている
ユーザーがいったことをそのままやればいいのか？
全員の言葉を受け止めたら誰にとっても使いにくいものができる。
では、良いユーザー体験とはなんなの？
- UXガイドラインをつくった
- こういう体験が「よい体験」と呼ぶというものを作った
- UXガイドラインを製本して配布した
- オンライン共有と合わせて少しでも気軽に読めるように
- UXガイドラインのワークショップをおこなった
- こういう風につくったらいいよねというようなものを体験してもらう
ユーザーって誰なんだろう
- なんちゃってユーザー（想像のユーザー）
- ユーザーインタビューの実施
- 発足してから28名
- それをエンジニア含めた組織に開示
- 分析（ペルソナ・カスタマージャーにマップ）と合わせて、インタビューを行なっている現場にも来てもらった
もっとデザインを知ってもらうために
- 社内図書館をつくった空いている机にデザイン関連の書籍を並べた（私物）
- そういうところで、こんなことをやっているというものを発信した
- 外部発信（ブログ・イベント登壇）
- UXっていわない（ UXが便利なことばとして蔓延してしまっていた状態だったので、いわない ）
デザインを実践していくために
デザインが大切なことは、わかったんだがそもそもプロセスに含まれていない。
- 最初にSlackに相談チャンネルを作った（なんでもいいから話をしてというチャンネル）
- プロセスに含まれていないものを、いれたらどうなるだろうというものの共有
- 実際に、そのまますぐにガイド通りにはできない。そういうもの。
- そういったものがあるという意識づけができたことが大事
UXデザイングループ単体で独自の施策を実施
- どんなことができるか
- どんなことをやっていこうとしているのか
- 具体的に伝えるひとつとなった
地道な努力で、徐々に、デザイナーが関われる箇所を増やす
2017年7月 部分的にチーム担当制を導入
当初から求められていたが、意図的に設けていなかった。理由は、 デザインとは何かを理解していない状態で行うと、絵を作る担当としてしか機能しなくなる危険性 があったため。
デザインとは何かを理解してようやく導入。
- デザイナーは絵を作るだけの存在ではない
- 施策の立案・実施のためのデザイナー
- ユーザビリティテスト導入
- プロトタイピングツール導入
一部では、デザインが機能している状態をつくりあげることができた。
週次勉強会
- エンジニアと話をするために、デザイナーがRubyなどを勉強する
読書会
各自の勉強にもなるが、他の人に、自分がやっていることを伝える練習
朝会留学
デザイナーがマーケチームの朝会や営業の朝会などに出席していろんな知見を得る
現状：施策にデザイナーが関わるようになった 課題：デザイナーが足りない
これから - デザインガイドライン - デザインシステム の策定を行いたい
- サポートに寄せられる声を改善につなげる
まとめ
- とにかくやってみる
- そのとき、そのとき必要なことをやっていく
- 根本は、「プロダクトを通して、ユーザーの課題を解決したい」
感想
デザインとは何か。デザイナーの中では当たり前でも、エンジニアや他の職種の方々には、わかりにくいものである。
頭ではわかっていたつもりであっても、やはり地道な努力が必要であると感じます。また。それを聞いてくれるという組織の話でもありますね。
聞いてくれる環境を作るためにも、普段のコミュニケーションなども大切。熱意や、発信についてもやはり怠っていると厳しいものだと思わされる内容で、自分のデザインの知識が深くなければ、伝えることもままならないものだと思います。広い知識、大きな視点で見ることを思い出させてくれるセミナーでした。ありがとうございます。
