雑な感想とメモ | Geeks Who Drink in Tokyo -Design Renewal Edition-(デザインリニューアルのしくじり特集)@ヌーラボ 20170526

Geeks Who Drink in Tokyo -Design Renewal Edition-(デザインリニューアルのしくじり特集)に行ってきたのでその感想と、話を聞きながら書いたメモを共有する。あくまで自分の備忘録として書いているので、抜け漏れ解釈違いなどはあると思う。

感想

※お前の感想じゃなくてまとめだけ見たいという方はこちら

デザイナー、フロントエンドの担当が数字に敏感

両者(フリルさん、ヌーラボさん)でおっしゃっていたが、デザインや導線を決めるときにもっと数字に敏感になったほうがよいということだった。
当たり前のようで忘れがち。
結局感情や直感で決めるにせよ後々の理由付けのため、という意味でも数字は非常に有効。

目的への立ち返り

こちらも両者で述べられていたが、目的を事前に明確にし、事あるごとに立ち返って良くしていこうということだった。
これも忘れがち、というか、仕事してたらそんな余裕が無いことは多々ある。。自戒。

結局はコンバージョンしてくれるユーザーを獲得することが大事

流入元がWEBのユーザーのほうがアプリから入ったユーザーよりも回遊率が高くコンバージョン率も高い、とフリルさんがおっしゃっていた。 検索からの流入を見込んでWEBを強くしたという話だったが、流入の違いによって以下の属性の違いがある。

  • WEBの商品検索から入った人 → その商品を買うためにフリルに出会った
  • 始めからアプリをダウンロードした人→なにかいいものがないか眺めている

という感じで、ハナから目的が違うので、たしかに動きも違いそう。
アプリを使っているユーザーという一括りでみると、わざわざアプリをダウンロードしてくれているという意味でブランディング的にロイヤルユーザーが多いと安直に考えがちだが、流入元を見てユーザーをもっと細かく分析することが今後は大事になってきそう。

見た目はユーザーのリアクションを見て調整できるようにしておく

Backlogのβテスト期間で見た目の調整に継ぐ調整を行っていたという話だった。
この話を聞いて僕が思ったことは、いま自分が作っているものはこんなに簡単に隅々まで調整できないんじゃないか、ということ。
CSSについては全然わからないが、なにか見た目に関わるものを作っている場合は、簡単に調整できるように設計しておくことが必要だと感じた。
ユーザーの意見を反映するには、反映へのハードルを下げられる開発をしておくことが重要。(後にA/Bテストにも使える)

以下、本編

「小さく早く試す」 フリルのリニューアルの舞台裏

株式会社Fablic プロダクトマネージャー / デザイナー 山口 有由希さん フリルの分析、企画

アプリファースト

  • 2014年ベストアプリ
  • 2016年ベストデザインアプリ

フリルWebリニューアルプロジェクトの話

手付かずなWEB
→最適化により流入量の増加を見込める

WEBでは購入の口がなかった
→WEBきっかけのユーザーをもっと増やせる

WEBメンバー

  • 企画・デザインフロントエンド(本人)
  • サーバーサイド * 2

現状分析・調査

  • 検索流入の最大化
    • フリルの現状
    • 3ヶ月で実現可能なKPIの策定
  • 購入動線の最適化
    • 現状フローのCVRを調査

フリルの現状を知る

購入導線の調査する

データ参照元

  • GA
  • Party Track
  • DB →現状の離脱ポイントとConversion Rate(コンバージョン率: CVR)の洗い出し

ECサイトのカートのCVRを調査し、現状のフリルと比較 分析結果から指標を仮置きし試算すると、アプリでしか購入ができないのは、かなり筋が悪いことが発覚

リニューアルの目的 = WEBきっかけで登録・購入するユーザを増やす

検索流入の最大化のために

オーガニックUU目標を設定

購入動線の最適化のために

WEBで完結するように機能追加

やること

  • 拡張しやすい構造にして組み直す
  • 適切なページを増やす
  • 各ページで適切なワードが表示されるようにする
  • 欲しい商品を見つけやすくする

やらないこと

  • 登録・購入までのステップ以外のUIの最適化はやらない
  • その他のアイコンなど、ディテールの最適化

どのようにしたか

  • 検索については、SEOで段階的なリリースによるトライ&エラー
  • 並行して、様々な機能を順にリリースし、最後に購入機能をリリース

WEB登録、購入が可能にするには工数が必要だったので、ちゃんと時間を取った

結果

  • オーガニックUUは3倍
  • 登録ユーザ数は20倍

振り返って、デザイナー視点でもっとやりたいこと

  • 購入に至る経路以外の体験の最適化
    • ユーザーインタビューを重ねて突き詰めたい
  • ディテールへの最適化

今回の目標は達成できた

目標に対してしっかり結果を出す

  • リニューアル時に最初から全てを完璧にやりきるのは時間的にもコスト的にも難しい
  • 結果がついてくればまたチャレンジできる
  • 経営判断を引き出せる
  • 引き続き改善もできる

ゴールに合わせて都度最適な手段を選ぼう!

質問コーナー

  • リニューアルの設計タイミングで定性的な調査をしたか?
    • テストをして問題無いことは確認した
  • WEBとアプリでカスタマージャーニーの違い
    • 違う性質のユーザーが来るという想定
    • WEBは大量の検索からフリルに入る、アプリはフリルを使うと決めている
    • 上記の動機の違いを意識した
  • 登録後のユーザーはWEBでフリルを使うか?
    • 積極的にアプリに流したい
  • 実際に行った施策で狙った目標まで到達したか?
    • 購入導線を改善して、出品者への確認が必要、ECのCVRを超えることはできなかった
  • もともとWEBはあったわけだが、新しく作ったという認識で良いか?
    • 徐々に全部作り変えたので、順次りりーすだが、結果全く違うものになった
    • 新機能だらけ
  • 効果測定、WEBの改善によるアプリへの影響
    • WEBで登録した人をアプリに流す施策を打ったので、アプリのユーザー数も増加した
    • WEBからアプリに入った人のほうが、アプリから入った人よりもよい動きをしてくれる
  • CMなどの影響とWebリニューアルの影響はどう違うのかを判定できたのか
    • CMなどの広告では基本アプリを宣伝するので、今回に限っては分けて考えることができた

Backlog UIリニューアルの舞台裏

株式会社ヌーラボ Webデザイナー 中川 裕二

  • typetalk: チャット
  • cacoo: デザイン
  • backlog: プロジェクト管理

リニューアル

5年ぶり2度目の大規模リニューアル

目的

  • これからの時代にあったデザイン
  • ユーザーがやりたいことに集中できる
  • 新機能などを追加しやすくする

どんな問題があったのか

“課題”(backlogの1つの単位)の詳細についての情報が一番重要だが、周りに情報が多すぎてわかりづらい、分散している

やること

「仕事の中に楽しさを」というBacklogのコンセプトをひきついでかつ、画面をスッキリして、整理

やらないこと

大幅な画面構成の変更

約一年に渡るビッグプロジェクトになったが、開発の後のリリースまでの話をする

リニューアルに当たって事前にケアしたコト

  • リニューアルのストレスを最小限に
    • 大幅な画面構成は変更しない
    • 既存機能の削除はしない
  • ユーザビリティテストをする
    • 自分たち以外の人に使ってもらう
  • β期間を設ける
    • いつでも新旧を切り替えられる

結果

ユーザーから不満の声が大量に…

フィードバックの主な経路

→Typetalkで議論しBacklogに課題として登録、対応

現実的なすり合わせと対応

  • ダッシュボード
    • タブで切り替えるようにした→3つの情報が俯瞰して見れない
  • コントラスト
    • 今風なものにした→目が疲れる…
  • メリハリ
    • よりスッキリに→コンテンツの境目がわかりにくい

Backlogの課題でやり取りしつつ週次のデザインMTGで議論 - Cacooでのイメージ共有 - デザインカンプ - プロトタイピング - 実装してから暫く使う

コンセプトに立ち返ろう

ダッシュボードのしくじり

  • 大幅な画面構成をしてしまった→戻す

    コントラスト、メリハリのしくじり

  • 見づらい→下地とコンテンツの背景色を逆転させた
  • フォントがぼやけて目が疲れる→フォントの変更
  • wikiで整形後のテキストにメリハリがない→差し色を入れる

ちょっとずつ前のデザインに戻る?生まれてくる葛藤

  • 慣れと使いづらさ →新デザイン + 旧デザインの良さ 溶け込ませる

リニューアルの極意(1): 旧デザインの優れていたところは活かす(featuring)

眩しさの原因を調査

  • 報告のあったディスプレイを買ってまで調査
  • 背景がグレーが真っ白で緑が目に痛い

→ 実際辛い 色という色の調整した

何が悪かったか

ユーザビリティテストは、人はもちろん様々な環境でテストをするべきだった

眩しさの葛藤

  • ディスプレイによって違う
  • どの環境が最もあるべき状態なのかわからない

→眩しさは辛くて仕事にならない、これは一番ダメ P/D/T型 色覚で状態の色が見分けづらくなった リニューアル前程度に見分けられるように再調整

  • 少しずつ濃くしていった
  • 背景や文字色も更に濃く

遠目からの比較

  • 必要な情報にパッと目が行く

リリースしてみて

  • 実際暗さに対する意見はなかった
  • ユーザーからの良いフィードバックがあった

機能は削除せずに画面をすっきりさせてやりたい作業にという目的の達成

リニューアルの極意(2): 三歩進んで二歩下がれ!(ユーザーの皆さんにとってはインパクト大!)

β提供後一ヶ月経過、フィードバック二期を取られて気づかなかった問題が…

新デザイン使ってる人、少なすぎ問題(10%)→このままリリースしたら間違いなく炎上

  • ブログ
  • アプリ内ヘッダーにお知らせ
  • βリリースのお披露目イベント
  • 目立つダイアログ

答えられないと旧デザインに戻れないアンケート

  • 大きな声が上がっていたものを出す
  • どれも主観的なところなので実際どのくらい調整できているかわからないから、だったらユーザーに直接聞いてみた

アンケート結果の分析

  • 旧デザインに戻したユーザーが8%
  • 良いFBを得た→修正

→予定通り切り替えても良さそう

リニューアル後の効果

  • これからの時代にあったデザイン
  • やりたいことに集中できるデザイン
  • さらなる機能追加・改善の余地を作る
  • 嬉しい意見もたくさん

最近はA/Bテストもやっている

こちらが提供したいUIと求められているUIを比較

まとめ

  • コンセプトを持つ
  • ユーザーとコミュニケーションをする
  • 数値の計測と分析をする

質問コーナー

  • β版で出そうな問題を事前に潰すためにはどうすれば良いと、今は思いますか?
    • ちゃんといろんな環境でチェックする
    • ユーザーの多様性を考える
    • ユーザーインタビューの徹底
  • Twitterエゴサーチは毎日してるの?
    • 日常的に使うアプリのアプリなので、Twitterへの書き込みが多いこともあり、良くしている
    • 社内チャットにエゴサ専用のチャンネルが有る
  • UI改善の契約数への影響
    • 全体的な成長もあるので、確実な情報がない
    • しかし、最近はトライアルが増えていて割合的には正式登録数が減っている
  • 1年にも及ぶリニューアルへの社内の合意を得るために
    • 社内の合意を得ることは全く問題なく、ユーザーの反発を防ぐことに注力した

両者への質問

  • 辛かったこと
    • フリル
      • プロダクトオーナーデビューだったので、結果への要求とデザイン、マークアップに忙殺された
    • Backlog
      • 調整期間で、なにが良いのかわからなくなって、葛藤する
      • 自分の判断の正しさがわからなくなる
      • 自分は何と戦っているのか
  • 開発とデザインはどのように連携していたか、日程調整、QA(Quality Assuarance)的な意味で
    • フリル
      • 密にコミュニケーションを取っていた
    • Backlog
      • スクラムで、デザインは開発の1週間前に始める
  • 予想できなかったアクシデントの印象的なエピソード
    • フリル
    • Backlog
      • ちゃんとしてれば予想できたんじゃないかなーと思ってしまう
      • 毎日Backlogのことを考えていたので、わからなくなってしまった