ちょっと西の湖岸から

@plum_shiga が何かを思い立ったら書くところです

Developers Summit 2015 2日目 報告

概要

に参加してきた!

本記事では @plum_shiga が参加した2日目の各プログラムについて報告する。

ちなみに資料まとめもある

デブサミ2015、講演関連資料まとめ:CodeZine

 

 

実践! クロスプラットフォームモバイルアプリ開発

ハンズオン。

ハイブリッドアプリ(ネイティブアプリ でありつつ Webアプリ でもある)を作ろうというもの。

作ったアプリは、おみくじ。ランダムで大吉~凶までの結果を返すという分かりやすいものだった。

f:id:plum_shiga:20150221154301p:plain

 

開発環境について

基本的にはMonaca上で行った。

html, css, .jsの各ソースをWeb上で編集・保存・プレビューを行えるという分かりやすいシステムになっていた。

また、Apache Cordovaにも対応しているのでネイティブの挙動も対応できる。

今回はバイブレーションだけおみくじを引くと同時にバイブする形で

navigator.notification.vibrate(500);

を呼び出した。

ただ、Monacaではデプロイまではできないので、別途探す必要がある。


開発者こそ知っておいてほしいモバイルコンテンツデザイン -ハコと中身の整え方-

基本的なデザインプロセスの紹介と、登壇者(矢野りん 氏)が考えるデザイナーとの付き合い方について。

箱の話(モバイルコンテンツのデザインプロセス)

ターゲットユーザの定義は大きく2つの特性を使う

 人口統計上の特性(年齢、性別、所得、しょくぎょう、学歴)Demographic information
 心理学的な特性(ライフスタイル・好み、価値) Psychographic information
  例)コミュニケーションの質を求める人 特に女性 とか

定義する理由
 チーム内で統一した対象者像を持つため
 マーケットを絞るため
 デザインの目的をハッキリさせるため、
 サービスやUIのデザインをするとき、ドキュメントに書き添える。

注意すること

 ユーザ定義はざっくばらんな方が良い(細かすぎるとぶれる)
 insightってほどでもないプロフィール的なもの


プロトタイピング
 アプリの操作手続きを理解するために作る。画面の集合
 基本機能を最初に作って→次に拡張を付け足す(既存アプリなら差分だけ作る)

 

なんでプロトタイピングするのか?
 開発に迷惑をかけないため → 事前に問題を洗い出す
 デザイン上の問題を見つける → 効率のいい操作手順になってるかを確認する

 

 

UIテンプレキットまとめ

 speckyboy.com/

 Keynote
 Sketch - UIレイアウトツール
 ZEPLIN デザインガイドラインを作ってくれるサービス

 

デザインのコツ

 グラフィックは仮のもので良いが、言葉づかいだけは仮のものにしない
  例)「OK」ボタンが「わかった」ボタンって世界観がだいぶ変わる……
 あとは複数人の視点を入れて微調整する

デザインレビュー
 デザインの効果をはかって、アプリをよりよくする会議

2種類の指摘

 1. 客観的な事実(集計データ、ユーザからの批評)に基づく指摘

  ※基本はこっちでがんばる
 メリット)
  レビューワーの課題設定能力のばらつきに振り回されにくい
  デザイナー・開発・マーケなどの異なる職域の人間が同じ目標を達成しようとしやすい

 

 2. レビューワーの趣向、主観に基づくもの
  ダメじゃないけど非効率的
  喧嘩になりやすい
   特に経験の浅いデザイナーは感情的になりやすい

   開発経験者は開発コストを下げることに注力する
   PMは権限を振りかざし主観的なこと言う
   → お互いそういうもんだと思って歩み寄る
   自分の言うことを聞いてほしいがゆえの指摘
   → 目的とズレる

レビューのプロセス

  1. デザインを最適化することで達成が見込める・目標を設定 or 確認
  2. 目標が達成できていない部分についてレビュー
  3. 目標を再確認 or 再設定。うまくいっているところはケーススタディとして共有
  4. TODOにしていく

建設的レビューのコツ

 デザインそのもの(見た目)に対する変更は、あまりその場で言わない

  → 会議に時間がかかっていい結果にならない
 些末なレベルはもう、ヤイヤイ言わない(命令しない)。
 デザイナーにはアイデアだけ言ってあげて、そのまま任せる!
 具体的なアウトプットの出力権限はデザイナーに委ねて、修正結果はあらためて確認する
 定義を共有できていない用語については常に注意する(ブランディングっていう言葉とか)
 議事録を取る(あいまいなTODOを作らないようにする!)

 

デザイン評価
 ユーザの定性的な意見を一番尊重する。
  → デザインを良くするにはやっぱりヒアリング

 

KPIについて考える

 デザイナーもKPIあるしMAU背負ってる けど、デザインの質につながらん
  → デザインはMAU、KPIにコミットしにくいもの


中身の話

マイクロソフトのデザイン原則いかしてる

デザインこそがコンテンツである

 

その他のTips

 モバイルに顕著な中身の特徴
  一息で読める文字量を意識 100-140文字
 読みにくい漢字はひらがな
 サービスのユースケーズを常に意識する

 コンテンツの量がUIの姿形を決定する

 

終わりに

 今回はDevlopers Sumiit 2015 2日目の内容をメモ的に報告。

 しかし、個人的なメインイベントである「CodeZineスーパー対談 2020年のUI/UX」について全く触れていないので、それについては別の記事で報告する。