takeshi nagayama's blog

A weblog about Design, Tech, Japan and Kyoto.

クックパッド流UIの作り方

なんか突然東京行きたくなったので、ひょひょいと行ってきた。
たまたま立ち寄ったクックパッドっていう会社でクックパッド流UIの作り方という勉強会してたので、偶然持ち合わせていたはてなステッカー渡したりおいしい料理いただいたりした。

f:id:nagayama:20120726221917j:plain

f:id:nagayama:20120726204059j:plain

UI/UXのためのSass

  • 池田さん / サービスデザイン部
  • Sass / Haml (エンジニア・デザイナー問わずに)
  • Github
    • デザイナーもpull req
  • 一つのサービスを複数チームで開発
  • 各デバイスで速いサイクルでの開発
  • Sassとは → ぐぐれ
  • 全体のデザインを束ねる → デザインガイドライン

ガイドライン

  • Sassで統一的なものを提供する
  • 画像を使わずにCSSでデザインするメリット
    • mixinをつかって統一できる
    • 画像編集がいらない
    • プロパティの変更によってデザインに幅をもたせる事ができる
    • mixinの中身は応用がきくような仕組みにしておく
  • 検証をする
    • デフォルトのカラーコードを変更する事で、横(他のチーム)に展開ができる
  • カラーコードをガイドラインにする
    • ではなくSassにしておいて、変数で呼び出す事で
    • overrideもできる
  • ロゴガイドライン
    • mixinで定義しておく
      • 事前padding 10pxとかしておく
    • 会社全体のブランドを定義しておく
  • 一貫性のあるユーザー体験が提供できるようになる
  • UIの細かいことを考えずにUXの改善に集中できる
  • フィードバックを全体に反映しやすい
  • サービス開発者もまきこんだガイドライン

クックパッドの事例

  • 自社css frameworkを利用
    • 最近導入した
    • 導入にはどのくらいかかかった?
      • 人数→ tikedaさんだけ
      • 他の仕事をしながら2ヶ月くらいで
      • すでにあるサービスに導入するのでその調整が大変だった
      • ユーザーにマイナスにならないようにするのが大変だった
  • UIのコンポーネント
  • Sass上で色の調整をかなりしてる
    • カラーパレットとかはつかわないのかな?
  • 全ての色を一気にかえて検証をするという事がしやすい
  • 社内ツールなども高速に高品質のものが提供できる
  • まだ導入したばっかりだけど、運用を続け定着させていく事が大事

クックパッドのUIデザインプロセス

  • 片山さん / UIデザイナー
  • デザイナー 4名
  • プログラミングスキルも求められる
  • iPadからテーマをスマホWebに変更しました

UXデザインについて

  • 2秒で理解できるように
  • クックパッドのトップではラベルの長さを13文字以下にしている

開発の流れ

  • 要件定義 → 開発 → 評価
  • 要件定義
    • ユーザーの目的
      • レシピをさがしにきた → キーワード検索結果で離脱
      • なぜか(レシピがみつけられないのか)を考える
  • 開発
    • プロトタイピング
      • ペーパープロトタイピング、ホワイトボードに書くなど
      • 「UIデザインはプログラミングに似ている」
        • UIのパターンを学ぶ
        • 類似サイトをサーベイする、最前線の事例を参考にする、自分のセンスを過信しない
        • なぜこういう設計になっているのかを分析して参考にする
  • 評価
    • プログラミングとちがって自分がデバッガになる必要がある
      • エラーとかでない
    • 実際にリリースする前にアイディアが有効かどうか試す
      • 少人数にお試し公開してGoogle Analyticsでクリック率などを計測をする
        • Analytics ?
      • コストがかからない評価方法
        • 1.自分の目でみる ← 一日おいてみたりするとか薄目でみるとか
        • 2.友達や隣の人にみてもらう
        • 3.ターゲットユーザーになりきってもらってインタビューをしてみる
    • 評価を基に学びを得る
      • 仮説に対する答えを学ぶ事ができる
  • 「ユーザーの目的を達成するのがよいUI」
    • UIデザインは手段である
    • エンジニアも積極的にUIデザインに関わっていきましょう

UIで変わるマネタイズ

  • 高本さん / 会員事業部

会員事業部とは

  • 売上の6割が会員事業(残りは広告やマーケティング事業)
  • 4人でやっている
    • ディレクター2、エンジニア2

会員事業部の責任

  • 入会促進(有料会員になってもらう)
    • 価値を伝える
  • 退会抑止(そのまま継続してもらう)

施策

  • 入会導線の改善
  • エンジニアが企画・実装・成果検証までやっている
  • 超高速でA/Bテストをしている
    • CVRが指標
    • 価格に敏感な層への有料会員の提供はむずかしい

例1

  • 価格を表示したほうがいいかどうかをテスト
    • CTRは価格記載がないものがよかった
    • CVRは価格記載があったものがよかった
    • 期待ギャップの有無
      • 無料だと思って押したら有料だった
      • がっかり → 機会損失
      • 期待ギャップを無くそう

例2

  • コピーの計測
    • 事実をのべるものから感情にうったえるものまで用意したが…
    • シンプルなものが一番効いた
      • 「今日なにつくろう?が解決」<<<「クックパッドプレミアム会員になる」
      • 少なくとも1案はシンプルな案を入れよう

例3

  • ランディングページ
    • シーン訴求したり、視覚的な装飾をしたりした
    • ファーストビュー内に入会ボタンがあるケースでCVRが高かった
    • 視覚的装飾などは効果ゼロだった

部長の導線6箇条

  • シンプルに勝るものなし
  • 期待ギャップをなくせ
  • ファーストビューで勝負
  • 遷移の数は極力少なく
    • スクロールさせてたほうがいい
  • 画像は効果的に用いよ
  • 数ではなく質を狙え
    • 新しい導線を新設するより一つ一つの質をあげる

質疑応答

  • 仮説の検証の時間
  • 今回のスマホの事例だと
    • 1週間
      • 月〜金で開発
      • 金でテスト
      • 週明けに評価
    • もちろん規模による
      • iPadの場合は1ヶ月くらいかかった
  • 計測する取り組みはどう自分の中に定着したか
    • エンジニアにも強く計測を求められる会社だった
    • 会社のカルチャーという部分もある
      • 何をもって改善したの?というのが数字で求められる
      • それが評価にも結びつく
  • 迷っているか、一発でみつかっているかどういう風に見極めてるか。CTRで判断できないのでないか
    • CTRだけではなく他の指標もつかっている
      • マイフォルダーにいれる機能をつかっているかとか
  • 仮説はそれぞれ別のプロセスで計測するのか
    • 開発は平行しているが計測は別にする
    • どれが影響しているかわかるように、ひとつだけ計測する
  • お試しユーザーの基準
    • 社内ツールでセグメントできるようになっている
  • ファーストビューが大事でシンプルがよいとおっしゃっていたが、何個くらいの要素があると効果的なのか
    • いくつか試しているが結論まではいたっていない
    • 少ない方がよさそうだという感触はある
  • 要件を決めるフェーズはどういったフローか
    • 同じチーム内
    • ディレクター1人、エンジニア2人というユニットでとりくんでいる
    • エンジニアが課題を見つけるところからやっている
    • 各チームに裁量があたえられているので自主的にやっている
  • 有料プラン実施のために注意書きを掲載する必要があって複雑さが増してしまった。改善案はないだろうか。
    • 別なページに誘導するとか
    • できるだけ削ったほうがいいと思う

f:id:nagayama:20120726212025j:plain
終電ぎりぎりだったけどたのしかった。

とかいたら
ということなので
↓とか参照するとよさそう。