CSS nite LP33「UX/UI」の会にいってきた。

UX侍の森田氏（サムのほうらしい）、深津氏（ライのほうらしい）が二人揃ったり、私が勝手に憧れてるGoodpatch土屋氏やクックパッド池田氏も出演されるという豪華極まりない会。なんというフェスティバル感！

そんな豪華な会だったけど。個人的にはちょっとものたりない、腹6分という印象だった。
UXデザインは、チームで行う仮説＆実装＆検証のプロセスであるということ、サービスの事業面にも直結する、という肝部分の実例がもっとほしかったなあと思う・・・・たとえるなら、あんこう鍋のスープのあん肝、あと少し足りない状態だったのだ。

なんだかCSS niteでの話は、「デザイナーが考える理想のデザイン」の話が多かった印象だったのだ。「理想のデザイン」はもちろんベースとして必要なんだけど。

抱いた理想について、ユーザーのためによりよいサービス（含UI）をいかに実現するか？を組織内、時にはクライアントを説得し、合意し、実現し、検証し、次の施策へつなげてく過程にこそ、価値があると私は考えている。

時にはビジネス面での話になり、KPIや人月の話、損益計画書まで持ち出されるなど血みどろな戦いになるこの過程。他の組織でどう行っているかの実例気になってしょーがなかったのだ。

もっと言及してほしかった「デザインカンプでいいけど、データ入れたらなんだか使いにくい問題」

たとえばchatwork新免氏が提起した「デザインカンプでいいけど、データ入れたらなんだか使いにくい問題」。
えてして現場で生じるやっかいな問題だ。

・実際のデータをいれてみると印象がかわる
・インタラクションの確認ができなかったので実際にさわると使いにくい
・静止画でＵＩデザインを繰り返し調整しても根本解決にはつながらない

↓手法改善してみた

・早い段階でのプロトタイプでの検証
・触れることで静的なデザインでは気づけなかった問題点に気づく
・本番に近いデータやインタラクションを実装することで確認

「本番に近いデータやインタラクションを実装することで確認」＝「本番に近いテキストをデザイン段階で流し込んで利用する」そう新免さんはおっしゃったけど。
私はそんなテキストながしこみレベルで解決する現場ばかりじゃないよなあ、って思う。

たとえば私が今いる現場でも、早い段階で本番に近い画像＆テキスト流し込みでのプロトタイプはしてる。
たとえば旅行なら、安い広告宣伝系の未定商品並べたり、逆にリゾート系の商品のデータをデザインでいれてみたり、とか。

それでも解決できないものとして、例として以下がある。

とか。
その画面をみているユーザー体験を考えるなら、データとシステムとUI、さらにはカスタマーサポートが連携した状態でのベストを考えないといけない。チーム戦だ。

私たちデザインの立場の人間がデザインを作ってるのと同時並行で、エンジニアはAPIや検索エンジン等を作成してる。こうしたときに、なるべく早い段階で「本番に近い」プロトタイプを考えるのは難しい。
私が担当している旅行系ECはその難易度が顕著だとは思うけど。多かれ少なかれ、同じような悩みを抱えた現場はあるように思う。

エンジニアとデザイナーのコミュニケーションについて、グッドパッチ土屋氏はこう語っていた。

グッドパッチのデザイナーは、どのようにインタラクションデザインのイメージをエンジニアに伝えているか？
・After Effectを使う
・Flashで作る
・アプリのアニメーションパターン
・captivate http://capptivate.co/　を一緒にみる。FlashとかAfterEffectさわれる人はいいのだけど、時間はかかる。もしよさそうな例があればcapptivateのようなイメージできるものを提示している。
・とにかくコミュニケーション！

このあたり、「でもエンジニアじゃないとできない部分はあるよねー。そこどうするかだよねえ」という話は土屋氏と懇親会でウーロン茶のみつつ話したテーマだった。

ちなみに私は以下のような工程つくってどーにか凌いでる。「エンジニアじゃないとできない部分」にどう首突っ込んで議論するのかがやはり課題だ。

• 何回もエンジニアと細かい動きについて話し合う。
• システムとデータを理解する。エンジニアからAPIの状況要望伝え合ってAPIの状況によってデザインを変えたり、ローディングを追加したりする。その工数もみておく
• 「実際のデータをいれてみてからさわる時間を設けてよー」といいまくる。でてきたら触りまくる。
• カスタマーサポートの運用内容を知ったり、日報よんだりしてどんな問題おきてるか知ってアンテナたてとく。プロジェクトにカスタマーサポートに理解がある人を意思決定に入れる

チームで反復デザインと仮説検証を繰り返した実例話がもっとほしかった

あと一点、css niteで気になったのはチームで反復デザインと仮説検証を繰り返した実例話がもっとでてきてほしかった点。。
もちろん、今回深津氏やグッドパッチ土屋氏の話で、完成度はプロトタイプつくっていくごとにあげていく、という話はでてきてた。

だけど、途中で反復デザインはこうしてるとか、リリースしてから仮説と比べてどうだった、というような検証の話が薄かったように思う。
たとえば私が今回のセッションと、それにまつわるブログ記事で知りたかった話の例としては、森田氏のカスタマージャーニーマップの話。

一応、実例的な辺りで付け加えるならば、弊社（ツルカメ）はかつてレーシックのクリニックのWebサイトリニューアルを承ったのですが、その業務において最初のリニューアルコンセプトを構築する際、競合として分析をしたのはH.I.S.でした。旅行会社の。

これは何故かといえば、詳細はちと実例すぎて言えないのですけれども、10万使って心機一転するというユーザの心情を鑑みるというケースにおいて、レーシックと近場の海外旅行はどちらも選択肢になりうるという「仮説」に基づいて（この仮説そのものは、「企画」によって生み出されます）、H.I.S.が10万円の旅行をどのようにして扇動しているか（H.I.S.さんすみません）を分析し、こうしたコンテクストの構築によって、人は財布から10万円をスルッと出す、みたいなことを検討したわけです。

CJMでいえば、なぜかレーシック屋のCJMではなくH.I.S.のCJMを勝手に作って検討するとか、それくらいの勢いなわけです。
http://necomesi-ceo.hatenablog.com/entry/2014/04/27/115206

↑まさにこういう話あたり。胸キュン。

ここ、私は自分完全オリジナルにやってしまってるので、他の方がどのように進めてるのかをとにかくききたいなーと思っていた部分だったのだ。

というわけで自分の例をさらしてみる。
「自分はこうしてるぜ！」という人がいたらお茶でも食事でも飲み会でもして語りたいです。。。

私がチームでやってる反復デザイン、仮説検証例

プロトタイプ作成からデザインにおいて、私は以下のような工程で進めている。

1. プロトタイプ作る前に→考え方の違うUI例をチームみんなでみて、どういう方向性にしたいかざっくばらんに話す。
   たとえば「写真が超大きくパターン（写真9:情報1）」「写真と情報バランスよく（写真6:情報4）」「情報多めパターン（写真4:情報6）」とか。
2. excelでのプロトタイプ→1日でざっと作成、考え方の違うUIバリエーション5種くらい作って、ユーザーテスト的な確認して修正をくりかえす。
3. デザイナー　デザイン案→作ってもらうのは1種だけど、「考え方の違う」部分のUIはいくつか作ってもらったり、デザイナーの案があればそれをみたり。ここでも迷ったらユーザーテストをするなどして、デザインを検討しまくる。
4. コーディング＆エンジニア→一度作ったHTMLは、どんどんチーム内で再検討して改善していく。必要なパターン等あれば追加したり、なおしたり。

とにかく細かく反復作業をいれる、反復すること前提にワイヤーフレームをスピード重視であげている。

またリリース後に関しては以下のような動きを毎回やってる。

1. 事前に何の数値を成果目標とするかきめておく。
2. 数値をどうやったらとれるかを考える。コンバージョン以外にも、カスタムリンク等の途中指標も取得を考え、仕組みを実装してもらう
3. リリースされたら毎日にらにら見る。
4. リリース3日目くらいで超速報をだしてチームへ報告。この時点でクリティカルなものが見つかったら即アラートあげて追加調査＆会議招集
5. 一週間～二週間くらいでコンバージョン数がたまってきたら精緻な分析を1人日くらいかけて行い、課題を見つける
6. デザイナー、コーダー、エンジニア、サプライチェーン、カスタマーセンター等、全ての人へ結果を伝える（概要はA4一枚とか、メール数行にまとめて詳細資料添付とか）
7. 見つけた課題はリスト化しておき、他ユーザーインタビュー、ユーザーテスト等の分析もまた並行して行い、次の施策だしにつなげる

深津氏の言葉をかりれば「みんなで参加して」「ビジョンを共有する」「他人ごとにしない」。
森田氏の言葉をかりれば「それは合意のためです」。

視点がどうしてもUIのデザインで、もったいない印象

秋葉氏のセッション終了後、「いつも新幹線に乗る時、何番線に行くべきかわかりづらい。新幹線のチケットに○番線に乗るとか記載すればいいですよね」という話が司会の方からでてきた。
その後、「番線は変わることがあるから、チケットに書けない」と言う解説がでてきて「さすが鉄道通はすごいですね！」でその会話はおわってしまったのだけど。

「じゃあそこをどうやってユーザーに『自分がのる電車は○番線か』を気づいてもらうか？」って問いがまったくその場ででてこないことに違和感があった。だって、その問いから、UXデザインがはじまるんだから。

時間の問題もあるし、別にその場で議論しろって話ではない。
ただ「鉄道通はすごい」で納得したというスタンスで会話をおわったら、『いつも新幹線に乗る時、何番線に行くべきかわかりづらい』という問題解決にむけての議論は広がらなくないよなと思ったのだ。

ユーザーが困ってる姿を見て、そのUIの理由をきいたらすぐ納得してあきらめるデザイナーのスタンスに見えてしょうがなかった。深読みしすぎかもしれないけど。イベントで「UI/UX」ってうってる意味てどーなんだろう？

CSS niteではUIデザイン視点から「ユーザーがこうあってほしい」という理想を掲げるのにはよい会だと思う。

けど、全体を通してユーザー体験の中のごくごく一部であるユーザーインターフェース、それもデザイナー自身の視点に焦点があたってしまってたのがもったいないと思う。それがCSS niteですといえばそれまでなんだけど。

組織内で「なぜこれを作るのか？ユーザーにどんな価値を提供できるのか」を共通認識をもち、皆で考えた仮説が正しかったか検証をし、また皆で改善をしていく。
これがUXデザインの肝ではないのだろうか。
苦いし好き嫌いあるし鮮度高く料理すんのむっちゃ大変だけど、達成すれば相当の価値がある。そんなあん肝部分について、もっと言及されたらよりおもしろかったのになーと思った。

自戒をこめて

最後に。森田雄さんのプレゼンの最後に「UXデザイナーが悩むべき8つのこと」という項目があった。
もうこれって、UIがどうこうというよりは、サービス運営者の考慮することそのものだ。

1.サービスを提供するのに相応しい市場やユーザーのセグメントを見極めて選び出すにはどうすればよいか。

2.競合他社のサービスと自社のサービスを差別化するにはどうすればいいか。

3.ビジネスそのものを成長させるにはどうすればよいか。

4.より強いブランドを作るにはどのようなエクスペリエンスであるべきか。

5.顧客のロイヤルティを長期間にわたって維持するにはどうすればいいか

6.どの顧客こそが大切かを見極めるにはどうすればよいか。

7.広告、販促、PRの投資効果を最大化するエクスペリエンスとは何か。

8.企業の他の部門もUXデザイン思考をするためにはどうすればよいか。

UIのデザインで達成できるUXってほんのわずか。
それ以外の領域も存在すること、そこに改善できるチャンスがあるかどうかを見つけ、施策をうててはじめて「UXデザイナーです」って自信をもっていえるようになるんだと思う。

UIばかりに目をむけがちな自分へも、自戒をこめて。