失敗しない！Webサービスのリニューアル
数百万人規模のアプリリニューアルで実践した失敗しないテクニック
株式会社メンバーズポップインサイト カンパニー CX/UXストラテジスト／岡 昌樹さん
リニューアルで私たちは何を一新したいのか？
UI／UX／システム／オペレーション／ぜんぶ・・・
失敗例
・UIが古くなった
→ 目的がはっきりしない
→ UIだけではなくあれこれ触り始めてしまい終わらなくなる
→ 誰の何を解決したいのかが不明確に
・ビジネス的に新しく推したいものがある
→ ユーザーがやりたいことができなくなる
→ 会社の推したいものとユーザーの使いたいもののアンマッチ
なぜ失敗するのか？
脳は変化を嫌う
→ もともと持っている情報（経験／学習）が役に立たなくなる時
→ 過去まで時間をかけて慣れてきた「道具」
→ 投資した時間や労力に比例して大きなストレスが溜まる
→ 顧客のJOB（やりたいこと／ニーズ）を把握する必要がある
リニューアルプロセス
・ロイヤル顧客（上位20％のヘビーユーザー）のJOBの把握
ユーザーの習慣的・非言語的な体験を観察し、ユーザーのJOBを把握する
→ 基本情報／利用背景：サービス利用に至った背景
→ 現行のサービス利用再現：利用時の行動把握
→ 確認と重み付け：価値や未充足の価値不満を洗い出す
・コンセプト評価
リニューアルのコンセプトを作成し、コンセプトの評価を実施する
→ 課題がずれていないか？顧客の共感が得られるか？
→ 共感を得られないユーザーはどんな人で理由は何か？
・既存と新規の体験マージ
の体験の中に新しい訴求を混ぜる
→ 新しい機能や価値を使ってもらうためにいつもの体験を混ぜ込めないかを考える
・プロトタイプでネガを最小化
実際のUI/UXをテストし、ネガティブ評価の理由を確認する
→ 既存のヘビーユーザー
普段のシチュエーション利用でJOBが達成できるか
→ 新たな対象ユーザー
通常の動作に価値を感じるか、効率的に操作できるか
・計測と判断
コミュニケーションとKPIを設定しトラッキングする
→ ハードクレーマーの声岳に惑わされずに顧客の声に耳を貸しながら定量でも判断し、冷静に対応する
Webサービスリニューアルを成功に導くデザイナーのドキュメンテーション -実践方法と具体的手法-
株式会社ニジボックス クリエイティブ室マネジャー／神田 智哉さん
避けるべき事象
・コンセプト設計時：合意形成の遅れによる後続タスク遅延
・制作開発時：仕様理解のズレによる手戻り
・運用時：前任不在による制作経緯のブラックボックス化
コンセプト設計時：不変な資料
目的：コンセプトのビジュアライズ
留意点：プロジェクトに携わるすべての職能人へ伝える必要がある
・共有と保存が容易なスライド資料を作成する
・図版化することを意識する
・原理原則で説明する
・伝えたいことは一言で
・1ページ1コンテンツ
・プロジェクトに携わるすべての人が容易に取り扱えるドキュメント
制作・開発時：不変＋可変な資料
目的：情報の相互理解を促進する
留意点：対峙する人により専門性の理解度が異なるので、ドキュメントを使いわける
・モダン開発ツールとスライド資料の併用
→ モダン開発ツール：可変（流動的）
→ スライド資料：不変（普遍性）
→ 確定したことや認識のすり合わせをスライド資料で
運用時：可変
目的：品質維持／生産性向上
留意点：ガイドラインは常に編集する前提
・業務支援ツールとモダン開発ツールの併用
→ 業務支援ツール：動向や経緯を残す
→ モダン開発ツール：ガイドラインをどんどん更新する
・エンハンスにおいてガイドラインの更新は必須
・ガイドラインの厳守に固執しない
→ リリース後の改修スピードにあわせ、ガイドラインを改修する
デザインガイドライン＝根拠＝運用に合わせて更新されている
デザインコンセプト＝根拠の根拠＝不変的な土台
→ 根拠を残すことでプロジェクトの効率化を目指す
超高速配信を達成したオウンドメディア構築の裏話 - 脱WordPress、Jamstack採用の技術面の落とし穴 -
株式会社ICS代表／池田 泰延さん
ウェブサイトは勝手に壊れる
・ブラウザの変化
→ 常時SSL化、トラッキング防止など
・技術サポート期間
→ PHP5.6やFlashPlayerサポート終了など
→ セキュリティ対策を怠るとウェブサイト改竄などのリスクがある
OSやブラウザのアップデートによってユーザー体験が損なわれることがある
・時代の変化に対応するための必要な改善
→ リスク回避
・事業価値最大化のための改善
→ ユーザー満足度向上／競合優位性
WordPressをやめ、JamStackへ
・JAMSTACKは新しいウェブアプリケーションのためのアーキテクチャー
・フロントエンドの技術で静的HTML群を作成し静的ファイルとして配信する
→ 読み込みが早い
→ セキュアで安心
→ アクセス数増加に強い
→ 開発体験がよい
失敗例
・アクセス数
→ ページ分割UIを廃止したことによる見かけのアクセス数の現象
→ 短期的な変動に一喜一憂せずにさまざまな尺度の評価基準で検証する
・更新の手間
→ WoredPressではプラグインで容易に実現できることも自前で開発する必要がある
→ ビルド時間が長い、下書きプレビューができない、予約公開ができないなど
→ ヘッドレスCMSの有効活用やJSフレームワークの進化
・クラウド費用
→ EC2からS3+CloudFrontへ変えてコスト減
→ クラウド破産などで困らないために日頃のサーバウォッチは重要