読者です 読者をやめる 読者になる 読者になる

パターンで考えるスマートフォンのUIデザイン - UX Kyoto #08 メモ

開発 iOS

 パターンで考えるスマートフォンのUIデザイン - UX Kyoto #08に参加してきたので、メモ書きの公開。自分がわかるように書いているので、見にくいかもしれません。全般的に非常に面白い話が聞けました。情報をどう見せるか、ユーザの操作をどう導くか、そしてそれを実装していくときどう気をつければいいか、その点がまとまって発表されたのがよいですね。

スマートフォンのUIデザイン

スマートフォンのためのUIデザイン  ユーザー体験に大切なルールとパターン

スマートフォンのためのUIデザイン ユーザー体験に大切なルールとパターン

UIのパターン化・ルール化

  • 画面全体をコンポーネント単位に分割
  • 昨日やユーザ体験居合わせてコンポーネントのパターンを選ぶ
    • タブのデザインでもいくつかある
  • 適切なデザインが必要
  • デザインの引き出しを増やす
  • 方法論である

プラットフォームの流儀

  • iPhoneAndroid、Smartphone Site
  • iPhoneAndroidはガイドラインあり
    • 違いは?
    • ハードウェアの装置が違う
    • プラットフォームによって画面が違う
      • 例:ヘッダ部分
      • 例:画面の切り替える部分
      • 例:Facebookの場合、同じような形で提供している
    • プラットフォームの流儀にそろえる・そろえないことによるメリット
      • そろえる
        • そのPF使っている人がわかりやすい
        • デバイスの機能が使える
        • それぞれに対応した情報の出し方ができる(それぞれに作る必要あり)
        • 開発の分離がしやすい
      • そろえない
        • どれを使っても同じように使える
        • 口コミがひろがりやすいのではないか
        • 移行しやすい
        • デザインや開発のプラットフォームを統合できる

画面パターン

  • スマートフォンの画面はたくさんある
    • 実際のところ5つぐらいに分けられる?
    • 導入、トップ、一覧、詳細、入力管理
  • 一覧:検索結果ギャラリー
  • 詳細:記事、写真、商品(ここにたどり着くためにユーザは操作する)
  • 画面をパターン化するメリット
    • 目的をはっきりする -> シンプルでスピーディな画面設計ができる
    • 画面の行き来を意識したコンポーネントの配置
    • 引いた視点でプロジェクトを見ることができる

UIコンポーネント

  • いくつかパターンがある
  • 基本コンポーネント、アイコン、情報のビジュアル化
  • 基本コンポーネント
    • ヘッダとか
    • タブ型ナビゲーション iOSとAndroidの流儀の違い
  • 通知・メッセージ
    • モーダルメッセージ ボタンのラベルにも注意が必要
    • モードレスメッセージ 元の画面の操作もできる、メッセージはフェイドアウト
      • フェイドアウト時間はメッセージの文字列長によって変える
    • それぞれの使い道
      • モーダル
        • それだけに操作を集中させる(大事な操作)
        • のちの操作に影響を与える
        • ユーザの行動を事前に注意するのに適している
      • モードレス
        • 情報の通知(ツイッターのリプライ)
        • 他の操作に影響を与えない
        • 事後に確認する
  • ナビゲーション/コントロール
  • 情報のビジュアル化
    • 読み込み中、点数、グラフ
    • コンテンツに対する評価(レーティング)
      * ユーザに対するフィードバック
      * コンテンツの評価を第三者に伝える
      * 自分のための分類とする
      
    • 見せ方による表現の広さ狭さ
  • アイコン
    • 視覚的なメタファーを用いて機能や画面の象徴を表現したもの
    • いろいろなアイコンの意味
    • アイコンの形のでき方(具体的、抽象的、年月が意味を付けた)

パターン化・ルール化とクリエイティブ

  • クリエイティブとパターン・ルールは相反する?
    • そんなことはない -> 物語、映像
    • 物語の要素を記号的にとらえる、「行って」、「帰る」
    • 日常と非日常 -> 一覧と詳細

実践事例

  • クックパッド内でのパターン化・ルール化
    • ドキュメントが用意されている
  • Cookpad UI Design Rules
    • きっちり決められている
  • Sara Design Framework(皿から来ている)
  • 課題
    • UIはパターンにできる、ユーザの体験はパターンにできない
    • パターン化されたUIが意図した使い方になっているかは開発者次第
    • パターンに縛られすぎて、必要なコンポーネントが作られにくい

パターン化の及ぼす影響

  • デザイナが少ない場合 -> パターンとルールがあればある程度いける
  • デザイナーが別れる場合
  • 継続的な開発を続ける場合

最後に

  • パターンやルールは方法論の一つ
  • いつもクリエイティブに
  • ユーザメリットのためであることを忘れずにs
  • ユニークな面にも目を向け心惹かれるデザインを心がける

質疑応答

  • iOSアプリのクックパッドが若干独自
    • レシピを探すところに集中
    • ユーザーテストもいろいろやった
  • クックパッドは青を使わない
    • 料理の写真は縦長が基本
  • パターン化のドキュメントのやり方

スマートフォンのためのUIデザイン in Action

はじめに

  • パターンが役に立つとき
    • デザイナーとエンジニアが共同作業する場合
    • 未知のプラットフォームで設計する場合
    • 新しいパターンを生み出す場合
  • 実際の場合どうかというところを話す

パターン調査

  • 実装するアプリのイメージを膨らませる
  • 調査結果(パターン)をデザイナーと共有

パターン検討

  • パターン毎にペーパープロトタイプを作る
  • いろいろやってドリルダウンを採用
  • ユーザテストはペーパープロトタイプを使ってテスト
  • スワイプナビゲーション(避けてきたけど、そろそろ)
  • 使ってるパターンが古くなってきたらそろそろ見直し時期?

実装コスト

  • 標準から外れたUIは高コスト
  • パターンがSDKに含まれているかが重要
    • デザインガイドラインに出ているか?
    • 組み込みアプリで使われているか?

まとめ

  • 共通言語になる
  • 実装コストを見る場合もパターンが役に立つ