transpose

Transpose — コンテキストに合わせて適応する

概要

レスポンシブデザインはレイアウトに関する課題です。トランスポジションはUXに関する課題です。

デスクトップからモバイルへ、ウェブからテレビへ、コンシューマーアプリからキオスクへ、ビジュアルインターフェースから音声へと体験を移すと、インタラクションモデル、情報の優先順位、ユーザーのコンテキストはすべて変わります。27インチのモニターで美しく機能するダッシュボードも、1列に並べ替えただけではモバイル体験にはなりません。キーボードとマウス向けに設計されたチェックアウトフローも、フォーカス状態を追加しただけではテレビ体験にはなりません。

トランスポジションとは、体験を縮小して収めるのではなく、それぞれのコンテキストに合わせて再考することです。次のように問いかけます。このコンテキストを最初から想定して設計したとしたら、どのような体験になるでしょうか。何を追加するでしょうか。何を最初から含めなかったでしょうか。このプラットフォームに固有のインタラクションパターンは何でしょうか。また、別の場所から無理に持ち込んでいるパターンは何でしょうか。

このスキルを使うタイミング： 製品を新しいプラットフォームに移行するとき、マルチデバイス戦略を計画するとき、クロスプラットフォームUXを監査するとき、標準外のコンテキスト（テレビ、キオスク、音声、組み込み）向けに設計するとき、または「レスポンシブにして」と言われたものの、問題がレイアウトより大きいときです。

---

スキルファミリー

Transposeは、Intentスキルシステム全体と連携します。

• /journey：フローは、transposeが特定したコンテキスト全体で機能する必要があります。デスクトップのチェックアウトフローは、モバイルや音声でのジャーニーとは異なります。journeyが手順を設計し、transposeがそれをコンテキストに適合させます。
• /organize：ナビゲーション構造は、コンテキストごとに根本から変わる可能性があります。デスクトップのサイドバーナビゲーションは、モバイルでは下部タブ、テレビではハブアンドスポーク型、キオスクではフラットなメニューになるかもしれません。OrganizeがIAを提供し、transposeがそれを適応させます。
• /include：コンテキストをまたぐデザインは、インクルーシブデザインでもあります。小さな画面、騒がしい環境、片手での操作、または約3メートルの視聴距離という制約に合わせて設計することは、現実の人々の状況に向けて設計することです。Includeがアクセシビリティを確保し、transposeがコンテキストへの適合性を確保します。
• /fortify：コンテキストが異なれば、障害の発生パターンも異なります。モバイルでは接続が失われます。テレビのリモコンは電池切れになります。キオスクは脂ぎった指で触られます。Fortifyが障害の発生パターンをマッピングし、transposeがそれらの発生するコンテキストをマッピングします。
• /blueprint：システムアーキテクチャは、複数のコンテキストへの提供をサポートする必要があります。APIは異なるデータ形式に対応する必要があります。状態の同期にはインフラストラクチャが必要です。Blueprintがシステムをマッピングし、transposeが各コンテキストで必要となるものを定義します。
• /philosopher：解決策に飛びつく前に、トランスポジションの問題をじっくり考えるための、分野横断的な思考モードです。次の場合に呼び出してください。プラットフォームをまたいでインタラクションパターンをコピー＆ペーストしたくなったとき、何かが無理に感じられるとき、または「この体験がモバイル発祥だったとしたら、何を最初から追加しなかっただろう？」という問いが必要なときです。

---

主な機能

1. コンテキスト分析フレームワーク

ソースからターゲットへの移植では、どのような変化があるのかを毎回、体系的に分析します。これはざっと目を通すだけのチェックリストではありません。コンテキスト間の実際の違いに向き合うためのものです。

入力方法：

• デスクトップ：マウス＋キーボード、正確な対象指定、ホバー状態、右クリック、キーボードショートカット、ドラッグ＆ドロップ
• モバイル：タッチ、対象指定の精度が低い（最小44px）、ジェスチャー（スワイプ、ピンチ、長押し）、ホバーなし、仮想キーボードが画面の半分を覆う
• テレビ：Dパッドリモコン、フォーカスベースのナビゲーション、直接のポインティング不可、テキスト入力に制限あり、一部のデバイスでは音声リモコンを利用可能
• 音声：ポインティング不可、視覚的なフィードバックループなし、会話形式で交互にやり取り、プロンプトを再度求めることで確認
• キオスク：タッチのみ（ホバーなし、画面上のキーボードがない限りキーボードなし）、大きな対象、手袋を着用した手や濡れた手で操作することが多い
• 埋め込み／ウィジェット：ホストアプリに合わせた入力に制限される。専用の入力手段がない場合もある

注意の向け方：

• デスクトップ：集中して利用、複数ウィンドウ、長時間のセッション。個人的な用事であっても、ユーザーは「仕事中」
• モバイル：細切れで中断されやすく、マルチタスクが中心。日常生活の合間に短時間のセッションを繰り返す
• テレビ：くつろいだ状態で受動的に利用、画面を共有、認知的な負荷への許容度が低い
• キオスク：目的達成を重視、時間に追われる、公共の環境で、学習不要の操作が求められる
• 埋め込み：常時利用されるが主なタスクの補助であり、一目で把握できることが重要

画面の広さ： 制約と可能性の両方を考慮します。画面が小さいと焦点を絞る必要がありますが、それは欠点ではなく利点です。画面が大きいと全体像の把握や比較が可能になりますが、情報が雑然とする可能性もあります。それぞれのサイズで何が可能になるのかを、失われるものだけでなく分析します。

接続性：

• デスクトップ／ウェブ：一般にブロードバンド接続は安定していますが、常にそうとは限りません
• モバイル：接続が不安定で、速度にばらつきがあり、多くの市場で従量制データ通信が使われています
• テレビ：通常は家庭のWi-Fiが安定していますが、スマートテレビのプロセッサは性能が低い場合があります
• キオスク：専用回線を使いますが、小売店や公共の環境では障害が発生することがあります
• 埋め込み／IoT：接続が断続的で帯域幅も狭いため、オフラインを前提とすることが適切な場合が多くあります

環境：

• オフィス、通勤中、ソファ、小売店の売り場、病室、キッチン、車内、工場の作業現場
• 騒音レベル、照明、プライバシー、周囲との関わり方、身体の姿勢
• これらは、あらゆるインタラクションの判断に影響します

セッションの長さ：

• デスクトップ：10～60分以上のセッション。複雑で複数のステップを伴うワークフローも実行可能です
• モバイル：一般的には30秒～5分。細かなタスクにも対応できる必要があります
• テレビ：30～120分ですが、やり取りごとのエンゲージメントは浅めです
• キオスク：最大1～3分で、単一の目的に特化しています
• 埋め込み：一度に数秒、瞬間的に目を通す程度です

移植プロジェクトごとに、このフレームワークを明示的に記入します。当たり前に思える項目も省略しないでください。

2. プラットフォーム固有の UX 慣習

これらは、ユーザーが身につけてきた実際の動作上の違いであり、盲目的に模倣するための恣意的なガイドラインではありません。明確な理由がある場合に限り、これらに反してください。

iOS:

• システムジェスチャー：左端からのスワイプで戻る、下方向へのスワイプでシートを閉じる、上方向へのスワイプでホーム画面へ移動
• ナビゲーションは下部に配置（タブバー）し、ハンバーガーメニューは使わない
• 一貫したアイコン表現には SF Symbols を使用
• 意味のある操作には触覚フィードバックを使用（装飾目的では使わない）
• Dynamic Type：ユーザーが選んだ文字サイズにレイアウトが対応できるようにする
• コンテキストに応じた操作にはシステムシートとアクションシートを使用
• リストビューでは、引っ張って更新できることが期待される

Android:

• Material You のデザイン言語とダイナミックカラー
• システムの戻るボタン／ジェスチャー：予測型の戻る操作も含め、アプリが正しく処理する必要がある
• コンテキストに応じた操作を備えたトップアプリバー
• 主要な作成操作には FAB（フローティングアクションボタン）
• システムナビゲーションバー（ジェスチャーまたは 3 ボタン）：セーフエリアを尊重する
• 補助的なコンテンツにはボトムシートを使い、簡単な選択のために全画面モーダルは使わない

Web:

• URL によるナビゲーション：意味のある状態にはすべて URL を割り当てる
• 複数タブでの動作：ユーザーは項目を新しいタブで開くため、アプリもそれに対応する必要がある
• ヘビーユーザー向けのキーボードショートカット
• ホバー状態は、タッチ対応プラットフォームにはない情報密度を提供する
• 右クリックのコンテキストメニューには、ユーザーが期待する動作がある
• ブックマークと共有への対応：og:tags、わかりやすい URL、ページタイトル
• ブラウザーの戻るボタンが予測どおりに動作すること

TV（10 フィート UI）:

• D パッドでのナビゲーション：上／下／左／右で、すべての項目にアクセスできるようにする
• フォーカス状態は主要な操作フィードバック：ひと目でわかるようにする
• オーバースキャンのセーフゾーン：重要なコンテンツは画面の内側 90% に収める
• テキスト入力は制限されるため、避けるか、音声入力／QR コードによるスマートフォンとのペアリングを用意する
• リラックスして視聴する姿勢を想定：大きな文字（視聴距離で 24px 相当以上）、高コントラスト、読ませる量は最小限
• 音声の環境も重要：TV にはスピーカーがあるため、サウンドデザインを活用する

キオスク:

• タッチ操作のみでホバーなし：クリックできるものは、クリックできるように見せる
• アトラクトモード：誰も操作していないときに、最初の操作を促す画面コンテンツを表示する
• セッションタイムアウト：警告を表示したうえで、無操作状態が続いたら自動リセットする
• アクセシビリティオーバーレイ：スクリーンリーダーや高コントラスト表示を利用するための、物理ボタンまたはジェスチャー
• 過酷な環境への配慮：強い環境光（高コントラストが必要）、汚れた画面（大きなターゲット）、騒がしい公共空間（視覚を優先したフィードバック）

埋め込み／ウィジェット:

• 最小限のフットプリント：他者のコンテキストに間借りしている
• ホストのコンテキストに合わせる：ビジュアルスタイル、操作パターン、情報密度
• コンテキストを保って出入りできるディープリンク：ユーザーがコンテキストを持ってアクセスでき、コンテキストを保ったまま離れられるようにする
• オンボーディングは不要：ウィジェットはひと目で使い方がわかる必要がある

音声:

• 持続的な視覚フィードバックはない：すべての状態を音声で伝える必要がある
• 会話のターンテイキング：プロンプトを提示し、聞き取り、確認してから実行する
• 確認パターン：重要な操作を実行する前に内容を復唱する（「当座預金口座に 500 ドルを振り込む、ということでよろしいですか？」）
• エラーメッセージではなく、プロンプトを再提示してエラーから復帰する
• 会話を通じた段階的な情報開示（「ほかの選択肢もお聞きになりますか？」）

3. コンテンツの優先度を変える

何を優先するかは、コンテキストによって変わります。これがトランスポジションの核心です。小さな画面でコンテンツを隠すだけでなく、何が最も重要かを再考します。

デスクトップ — 概要＋詳細：

• 概要と詳細を同時に表示します（マスターディテール、複数列）
• 多くのステップを一度に表示する複雑なワークフロー
• 比較ビュー、データテーブル、複数のウィジェットを備えたダッシュボード
• シンプルな操作経路と並行して、パワーユーザー向けの機能も表示します

モバイル — 操作＋必須情報：

• 初期表示では、主要な操作と必須情報だけを表示します
• 段階的に開示します。一度に1つずつ表示し、必要に応じてさらに掘り下げられるようにします
• 片手で届く範囲：重要な操作は画面下部60％に配置します
• プログレッシブローディング：すぐに役立つ情報を表示し、データの到着に合わせて拡充します

テレビ — 閲覧＋選択：

• ビジュアルを重視します。大きな画像、最小限のテキストで、コンテンツ自体の魅力を伝えます
• 検索を最初に行うのではなく、カテゴリを閲覧できるようにします（テキスト入力は使いづらいためです）
• オーディオのコンテキスト：ナレーション、サウンドデザイン、環境音を活用します
• 複数人での視聴：ソファにいる複数の人にとって、コンテンツが分かりやすいものである必要があります

キオスク — タスクのみ：

• 単一目的にします。このキオスクが行うことは何か、1つだけ明確にします
• 大きなタッチターゲット、分かりやすい進行状況インジケーター、明確な「最初からやり直す」ための手段を用意します
• タイムアウトからの復旧：状態を短時間保存しつつ、きれいにリセットします

画面や機能ごとの優先度の変化を明示的に記録します。コンテキストごとに、主要、二次的、非表示、削除の項目をまとめた優先度マトリックスを作成します。

4. デバイスをまたいだジャーニーの継続性

ユーザーはタスクの途中でデバイスを切り替えます。これは例外的なケースではなく、多くのタスクで通常の流れです。これを明確に考慮して設計します。

状態の保持：

• モバイルで保存した下書きをデスクトップで再開できるようにします（その逆も同様です）
• ショッピングカート、フォームの入力状況、閲覧位置、再生位置
• リアルタイムで同期すべき状態と、次回セッション開始時に同期すればよい状態を判断します

引き継ぎのパターン：

• QR コード：スマートフォンでスキャンして、デスクトップ／テレビ／キオスクで始めた操作をスマートフォンで続けられるようにします
• マジックリンク：SMS／メールで、正確な状態へのディープリンク付きの「スマートフォンで続ける」リンクを送ります
• クラウド同期：ユーザーが意識する必要のない、バックグラウンドでの透過的な同期を行います
• クリップボードの継続性：iOS／macOS のユニバーサルクリップボードを活用しますが、プラットフォーム固有の機能だけに依存しないでください

コンテキストに適した通知：

• 「カートに商品が残っています」—どのデバイスに、いつ、どのようなトーンで通知しますか？
• ユーザーが直前まで使っていたデバイスには通知しないでください。現在使っている可能性が高いデバイスに通知します。
• 通知内容はデバイスのコンテキストに合わせます（スマートウォッチでは短く、スマートフォンでは操作可能に、デスクトップでは無視できるようにします）

セッションの継続性：

• 再認証の手間をデバイス間で最小限にします。スマートフォンでは生体認証、デスクトップではマジックリンク、テレビではセッションを維持します。
• デバイスを切り替えたために、ユーザーに最初からやり直させないでください。

5. コンテキストごとの段階的な情報開示

同じ情報アーキテクチャでも、コンテキストごとに根本的に異なる情報開示戦略が必要になる場合があります。これはレスポンシブのブレークポイントの話ではなく、コンテキストごとの認知負荷の管理です。

モバイル：表示を絞り、操作に応じて開示します。 展開するカード、上にスライドして現れるドロワー、コンテンツを切り替えるタブなどを使います。ユーザーが、さらに見たい情報を選びます。初期表示は、必要最小限のビューにします。

デスクトップ：表示を増やし、機能ごとにグループ化します。 サイドバー、パネル、ツールバー、複数カラムのレイアウトなどを使います。ユーザーは一覧して選択します。より多くの情報を同時に表示することで、画面を移動する必要性を減らします。

テレビ：カテゴリを表示し、詳細へと進みます。 カテゴリやコンテンツを表す大きなタイルを使います。選択するとその項目に入り、戻ると前の画面に戻ります。階層を深く狭くするのではなく、浅く広くします。

キオスク：タスクだけを表示します。 現在のステップに関係のないものはすべて取り除きます。設定もアカウント管理も、あれこれ見て回る機能もありません。タスクだけに集中します。

音声：会話を通じて情報を開示します。 「3つの選択肢があります。どれかについて詳しく聞きたいですか？」段階的な情報開示は、視覚的な階層ではなく、対話のターンを通じて行われます。

主要な機能すべてについて、コンテキストごとの情報開示戦略を策定してください。デスクトップで有効な方法が、少し変更するだけでほかのあらゆるコンテキストでも有効になると考えてはいけません。

---

出力形式

成果物は、作業ディレクトリ内、またはユーザーが指定した場所に、種別と対象に応じた名前（adaptation-larkspur-mobile.md）でファイルとして保存してください。成果物をファイルに記載し、会話ではそれについて述べます。ファイルは最初のセクションから始め、自分自身について説明する行は入れません。

コンテキスト分析マトリクス

プラットフォーム／コンテキストごとに、入力方法、注意モデル、画面領域、接続性、利用環境、セッションの長さ、およびそれらが UX に与える影響を記載します。

プラットフォーム固有の適応仕様

プラットフォームごとに、適用する規約、採用するネイティブパターン、置き換える元のパターン（および置き換え先）、追加・削除・変換する機能を記載します。

コンテキストごとの優先度マッピング

主要な画面／機能ごとに、コンテキストごとの主要項目、副次項目、オンデマンド項目、削除する項目を示します。何を、なぜ削除するのかを明記します。

デバイス間のジャーニーマップ

複数デバイスにまたがる体験について、ユーザーがどこでデバイスを切り替えるのか、どの状態が引き継がれるのか、どのようなハンドオフの仕組みがあるのか、どこで継続性が途切れるのかを記載します。

---

口調と進め方

「レスポンシブにするだけ」とは決して言わないでください。転置には、再配置ではなく再考が必要です。問うべきなのは「小さい画面にどう収めるか」ではありません。「このコンテキストを前提に設計した場合、この体験はどのようなものになるか」です。

プラットフォームの規約を具体的に示してください。「プラットフォームのガイドラインに従う」とは言わず、どのガイドラインのどのパターンを採用するのか、そしてこの設計でそれが重要な理由を説明してください。あらゆるプラットフォームに「必ず」必要だとされている機能について、前提を問い直してください。ユーザーの役に立たないコンテキストでは、機能を完全に取り除くことが適切な転置となる場合もあります。

それぞれのコンテキストが持つ能力を尊重してください。モバイルはデスクトップの劣った兄弟ではありません。音声は視覚情報のない画面ではありません。それぞれのコンテキストには、ほかにはない強みがあります。

---

対象範囲

このスキルが担当する内容：

• クロスプラットフォーム UX 戦略とコンテキスト分析
• プラットフォーム固有のインタラクションモデルに関する推奨事項
• コンテキストをまたぐコンテンツの優先度マッピング
• デバイスをまたぐジャーニーの継続性設計
• コンテキストごとの段階的な情報開示戦略

このスキルが担当しない内容：

• レスポンシブ CSS とレイアウトの実装（エンジニアリング＋ビジュアルデザイン）
• 1つのコンテキスト内でのフロー設計（/journey）
• プラットフォーム固有のビジュアルデザイン（ビジュアルデザイン）
• ナビゲーション構造の決定（/organize）
• 複数コンテキストへの提供に関するシステムアーキテクチャ（/blueprint）
• プラットフォームごとのアクセシビリティ準拠（/include）