DeNA Creative Seminar Vol.2 #denacrt でスマホUX/UIについて考えた

7/23(月)DeNA Creative Seminar Vol.2 に参加してきました。

「スマートフォンのUI/UXをテーマとして、フロントエンドエンジニア、UI/UXデザイナーなど、スマートフォンアプリやWebサービスのフロントエンドに関わる方々を対象とした勉強会」の第二回です。

特に私はECの中の人という関係上、やっぱりビッダーズのUI/UXがきになるところ。（ビッダーズのUI/UXは、シンプルでいいと思う）しかも天上の空間、ヒカリエに入れる！しかも豪華社員食堂のごはんもいただける！わくわくしないはずがありません。

というわけで本日のメニューはこちら。
セッション１：ブラウザレンダリングについて
NHN Japan　吉田徹生氏
セッション２：ソーシャルコマースサイトの企画と実装
DeNA　鈴木哲之氏
セッション３：スマートフォンにおけるUI/UX改善とscrum開発
DeNA　坪田朋氏

ブラウザレンダリングについて

: このセッションの資料

ブラウザによるレンダリングと、アプリケーションにおけるwebviewについてのセッションでした。

■ブラウザの種類
・Androidはブラウザ種類がたくさんあり、レンダリングエンジンも違う者がある。ほとんどの人が標準ブラウザ使用だが端末ごとにベンダーがいじる。Chromeは4.0から利用可能に。firefoxはレンダリングエンジンGecko利用。auが推奨ブラウザとしてドルフィンブラウザプリインストールという噂。

・iphoneはほぼmobile safariのみ

■ブラウザとwebvie
・Androidは基本はかわらないが、標準ブラウザをベンダーがいれかえてるときもあり、端末によっては違いがある。ギャラクシーSは要注意。

・iOSは性能差があるが、挙動はほぼ同じ。webviewはスクロールがおそい（プロパティで設定変更できる）。

■スクロール中の挙動
・Androidはレンダリングが止まるが、javascriptの処理は止まらない。android2.2からはposition:fixed;がきいてくれる。（固定の位置にヘッダーだしつづけるとかできるよ！）

・Iphoneもレンダリングが止まる。さらにjavascriptの処理も止まってしまう。タイマーとか実装しててもとまる。他imageがあると、テキストだけより表示にひっかかりが生じたりもする。。

このプレゼンきいて思ったこと。
「これ以上ブラウザの違いに悩みたくないです（泣）」

OS、ブラウザごとの違いに加え、さらにアプリでwebviewの機能実装している人の苦労を考えると泣けます。でも、こういう表示に際しての本当に細かい部分を配慮してこそ、ユーザーが使いやすいアプリやサービスができるんじゃないでしょうか。
詳細はプレゼン閲覧することをおすすめします。私の知識量でいろいろ語ると申し訳ないことになりそうなので。。。

ソーシャルコマースサイトの企画と実装

「ソーシャルコマースとスマホUI&UXの落とし穴」という内容でした。

・レスポンシブwebデザインにはしてない。PCとスマホをあえて分断し、スマホに集中。たとえばスマホでは、jsonをローカルストレージに保存し、変換候補を迅速にだしている。オフラインにしたとしてもさくさく候補がでる。

・スマホではソーシャルボタン系、iframe版よりHTML5のほうが重い。。カウントがあるとより重いので、カウントがないものを推奨。

・ユーザビリティ；ISO9241-11有効さ、効率、ユーザー満足度、利用状況。ミニマムデザインを目指してる。インパクトにはかけるけど、好感が得やすい。バナーもガラケーほどぎらぎらしてない。

・定量評価（数値のデータ）と定性データ（ユーザーの声）両方きいてPDCAをぐるぐるまわしている。例：mixiモールスマホ商品ページABテストの結果。スマホはファーストビューが命。商品画像が多少小さくてもおけー。カートを非同期で個数プラスマイナスできるようにしたら、離脱率3.19%から2.81%に。下のほうにボタンがあったら、購入以外の動きがへった。

例：カート改修、定量評価はよかったけど、定性評価は「商品を０にする方法がわからない」という声が相次ぎNGだった。ユーザーからの声をうけて、さらなる改修を実装。

例：404ページの改修。離脱率を指標にした。25.58%が18.46%にへった。サーバーエラー画面も改修検討中

失敗例：会員登録のIDのバリデートチェックを非同期でいれたら、突破率さがった。原因は、重複するようなID入力がおおくて、重複したときの提案のフローがなくなったため。

DeNAの強み、って人によっては色々あると思うのですが。私にとってはこの『定量評価（数値のデータ）と定性データ（ユーザーの声）両方きいてPDCAをぐるぐる』をちゃんとやっていることが、最強の強みの一つだと感じています。

主観ではなく、客観で仮説をたて、アクションし、検証していく。この一見あたりまえの流れは当たり前のようでいて、かなり難しいと思うのです。第一華々しくない。頭を使う。でも、客観的な数値に基づく0.5%とか1%の改善は着実だし、その着実に積み重ねた改善は結果的には確実な成果をもたらします。

そして鈴木氏のプレゼンにもありましたが、失敗も当然あります。でも、なんとなく実装してよかったねーではなく、あくまでシビアに数字をみて施策の成否をだしラーニングをためていくことで、UX/UIデザイナーの施策精度も上がっていくのではないかと思いました。

DeNAはデータドリブンな人がとっても住みやすい世界だと最近は感じます。逆にいうと、データをとるのが苦手な人、データから仮説を導けない人（もしくはその仮説に主観を差し込む人）、施策に失敗したら落ち込むだけで次の施策を考えられない人にとっては、厳しい世界。

私は「本当に売り上げを上げたり、、ユーザーのためになるwebサイト運営するには、数字分析は絶対大事！数字命！数字数字数字！ふがー」と鼻息荒く自社（DeNAグループのはしっこ）へ転職したクチなので、個人的にはこの空気は居心地よいです。もちろん数字がすべて、ではないけどね。

スマートフォンにおけるUI/UX改善とscrum開発

DeNA Creativeseminar#2 from tsubota tomo

ごめんなさい、scrum開発という言葉をたぶん先月くらいに初めて知りました。進行管理やチーム作りに（UIUXほどは）興味がないゆえかもしれません。汗。というわけで、勉強会以前の話から。

・scrum開発とは

「スクラム（英: Scrum）は、ソフトウェア開発における軽量なアジャイルソフトウェア開発手法の1つである。その名称はスポーツのラグビーでのスクラムに因んでいる。」
wikipedia

「大きなチームで最初に詳細計画を作る→進行管理者が進捗を管理し皆が作って完成までたどり着いて→最後にレビュー」という手法ではなく、「小さいチーム単位で進行管理は皆でおぎないつつすぐに動くものを作る→すぐレビューを行う→実装する」という手法のようです。

Agile　Scrumの概要を1分で理解できるイラスト　というブログエントリーがわかりやすかったです！

・スマホ開発に重要なのは、コミュニケーションと専門性。体制考えないとディレクターが作業時間とれないときも。ゆえにマークアップエンジニア、エンジニア、UIUXデザイナー3人でディレクター役を補完してる。

・現場にはスピードが求められている。「マネージメント陣が毛穴からスピードに対する重要性を滲み出し、現場の毛細血管まで浸透させる」がマネージャーのミッション。

・そのスピードを反映するため毎日の行動に反映する。ガントチャートは朝会で代替。mtgは立ってやる。パワポで書いたワイヤーフレームよりホワイトボード。コミュニケーションコスト低減してる。意思決定即決。メンバーだけがプロダクトにコミット。レビューは関係者全員同時に行う。

・たたいてたたいて、よいUIが出来上がる。イケてないUIが生まれる理由。ユーザーニーズの不理解、市場の勉強不足、コミュニケーション不足、チューニング不足。このうち「コミュニケーション不足、チューニング不足」は、scrum体制で解決しえることではないか。

たたいてたたいていいUIが生まれる、はまさに同感。

私もプロトタイプ段階で6人くらいに見せて、動作についてたたいてもらってはじめて気づいたことあるもの。あと、リリース前の改善を目的とした、ライトなユーザーテスト。ユーザーが迷いを見せる行動は、私たちUI/UXデザイナーにとても役立つ情報を与えてくれます。
Scrum体制について、実際に行った感想（不足点やよかったこと）は以下スライドをみていただければと思います。スクラム体制とってなくとも、その日々の考え方〜迅速に施策を考えるための会議体制のみなおし、スクラム内でのコミュニケーションの活性化、すぐに作るための体制〜は学ぶところが多いなと感じました。