App Meet Up #3 に参加したので、簡単なまとめです。

登壇

フラー株式会社
AppApe の運営会社

株式会社グッドパッチ
デザイン会社

FROSK株式会社
クラッシュ分析ツール- smartbeat -の開発会社。

データ視点で考える本当に良いアプリとは by フラー

結論

シェアやMAUだけでなく、アクティブ率などエンゲージの高さで評価しよう。

なぜか

シェアはブランドや知名度で獲得できるが、エンゲージの高さは、UXが大事。

たとえば

料理系アプリ
クックパッド、DELISH KITCHEN、クラシルを比較。
MAU はクックパッドが圧倒的。
月間利用率もクックパッドは65%、DELISH KITCHENは53%、クラシルは55%。
しかし、ヘビーユーザーの比率に注目すると、クックパッドとクラシルはどちらも2.5%前後で同水準。

月間利用率は、アプリをインストール中、かつ、月一度はアプリを起動するユーザーの比率。
ヘビーユーザーは定義をメモできず。。ライトユーザーが3日に一度、普通のユーザー層を挟んで、ヘビーユーザー層でした。
毎日使うぐらいのイメージでしょうか。。

地図アプリ
GoogleMapのMAUが一番。
でも、Yahoo!乗り換え案内は、利用頻度が高い。これは、毎日通勤で使う、という背景が影響してる。

ランニングアプリ
Runtastic のMAU が一番。
しかし、利用頻度は、STRAVA が断トツ。
STRAVA には、コミュニティ機能があり、自分が走らないときも、仲間の状況をチェックするから。
ちなみに、STRAVA のヘビーユーザー層は15%ほど。（他アプリは一桁なので断トツ）
またインスタへのランニング結果の投稿数は、ナイキが一番。
ナイキは、シェア画像のカスタマイズ性が高い。それが利用を促進してる。

まとめ

MAUが多い = ヘビーユーザーが多いではない。
拡大戦略だけじゃなく、エンゲージメントを高める工夫をしよう。

余談
ユーザー一人当たりのアプリ利用数は、25前後。数年横ばい。
ランチタイムは片手操作系アプリのアクティブが増える。両手操作のゲームアプリは伸びない。

運用改善フェーズにおける課題設定からUIに落とし込むプロセス by Goodpatch

結論

運用改善はKPIドリブンにいこう。
UI設計はコンセプトドリブンでいこう。
UI の詰め込みすぎにも注意。余白を意識しよう。

運用改善のやり方

カンバン方式。issue には、課題に加えて、KPIとユーザーストーリー（どう解決するか）を記載する。
issue のクローズは、KPI検証が終わってから。実装しっぱなしはやめよう。
KPIは、KPIツリーで俯瞰。KPIツリーはちゃんと四則演算の関係を保つように作ろう。
issue には、ビジネス的優先度とUX的優先度のラベルを貼る。複数視点から最終的な優先度を決めよう。
issue には工数見積をする。荒くてもロードマップを作るために。
見積が難しいときは、プランニングポーカー。みんなでせーので、工数をいって、乖離があると、話し合う。
ロードマップは、クライアント含めて共有する。
差し込みissueが発生したら、都度チーム相談。コミュニケーションを密に。

UI設計のやりかた

コンセプトドリブン
コンセプトを決めたら、それを体現するようにUI設計する。アプリに人格を与えよう。
コミックDAYSを作ったときは、マイクロインタラクションにこだわった。

マイクロインタラクション
以下の工夫をした。

いいねのアクション
アニメーションをつけて気持ちよさ、を意識した。

エラー表示
エラー表示にも世界観を与えた。
たとえば、漫画のキャラクターが「システムエラーです！」と伝えるなど

高速スクロール
スライダーでのページめくり操作では、パラパラ漫画のようなアニメーションを実装した。

これらはすべて、「夢中でマンガ読もう！」のコンセプトを実現するための工夫。

余白を与える
機能に余白を与えよう。リリース時は、必要最低限の機能にしよう。
あったほうがいい機能を実装していくと、機能がパンクする。

たとえば、
コミックDAYSの場合は、タブを 3 つだけにした。ヘッダーにもなるべくアイコンを配置しなかった。
今後ユーザー要望などで機能が増える可能性があるため。
機能の配置変更などは対応コストが高い。機能に余白があれば、その分拡張もしやすい。リリース時は、MVPがおすすめ。

余談
コミックDAYSのデザインチームは2人。デザインコンセプトは、ひとりのデザイナーが担当。
ひとりでやりきることで、各プラットフォームのすりあわせは起きないようにした。
コミックDAYSは、テーマカラーが赤だった。そのため、エラーカラーをどうするか、などは UI を作りながら調整した。

アプリの品質管理 - ユーザー離脱とその対策 - by frosk

結論

アプリの品質（UX）は、UI x 速度 x 不具合 で構成される。
不具合は、決してなくならない。うまく共存しよう。
不具合が多いと以下の問題が発生する。

1. ユーザーの離脱
2. ダウンロード数の低下
3. PDCA精度の低下

ユーザー離脱

大半のユーザーが週1でクラッシュを経験する。
クラッシュの経験有無で30日後の継続率に10％前後の差が発生する。
（もちろん、クラッシュなしのユーザーが高くなる）

クラッシュ対策は、継続率向上に大きな影響を与える。戦略的に改善しよう。

ダウンロード数の低下

クラッシュが発生すると、レビューに書くユーザーが多い。
低評価レビューが集まり、★が低くなると、ダウンロード率もさがる。
★★★ まで下がるとダウンロード率は ★★★★★ の50％程度に下がる。
（ちなみに★★★★は95％程度）

クラッシュが多いときにレビュー促進すると逆効果。
また不具合は公開することが大事。非公開の場合は、はやく直して！という思いから低評価レビューが集まりやすい。

PDCA精度の低下

クラッシュが多いと、原因が UIUX なのか、クラッシュなのか、わかりづらい。
それは、データ検証の誤判断に繋がる。クラッシュを抑えて、しっかりPDCAをまわせる環境を構築しよう。

なぜクラッシュは発生するか

すべての環境でテストできないので、必然。
特に、Android は上位20端末揃えても30％以下のシェアにしかならない。

クラッシュへの向き合い方

対策サイクル
1. 現状把握
2. クラッシュ率のKPI化
3. 影響範囲の大きいものから改善
4. クラッシュの影響を小さくする（レビュー対策など）

優先度
影響の大きいものからやろう。
発生回数、対象ユーザー数、急増中のクラッシュなど、ちゃんと把握しよう。
発生ベースで対策するのは、NG。

ちなみに、有名アプリのバグ改善アップデートは週1が多い。

クラッシュ率

非ゲームは1.5％が目安。これより高いとレビューが下がる傾向がある。

余談
firebase やストア系のConsoleで検知できるエラーには限界がある。
sumartBeatと比較すると、何十倍も差が発生することがある（smartbeatさん、すごい）。

おわりに

我ながら、だいぶ雑なまとめ。

誤りあったらすみません。
その場合、ご指摘くださいませ！修正します〜。