オンラインで小さな贈り物を渡す体験は、画面を数枚つなげれば完成するように見える。しかし、リンクをコピーした瞬間から、受取人に何が見えるのか、送り主が間違いに気づいたときに何ができるのか、受取人がすぐ反応できないときにどんな圧力を感じるのかが品質を左右する。
本稿は公開UIをブラックボックスとして読んだ設計・テスト用メモである。ソースコード、認証方式、保存期間、決済やアクセス制御の実装は確認していない。状態図と型は観察した実装ではなく、共有リンク型のUIを議論するための提案である。
先に分けるべき四つの責務
共有の体験を「作成完了」という一つの箱に入れると、仕様の抜けが増える。少なくとも次の責務は分けたい。
| 責務 | ユーザーが判断したいこと | 仕様に必要な問い |
|---|---|---|
| 宛先 | 誰に向けたものか | 表示名と連絡先は別に扱われるか |
| 内容 | 何を渡すか | 各アイテムを削除・並べ替えできるか |
| 作成 | どこまで確定したか | 未入力や失敗を戻せるか |
| 共有 | 誰が開けるか | リンクの有効範囲、失効、再発行をどう説明するか |
公開された A Little Box of Goodies を入口にし、A Little Box of Goodies APP で見える宛先・送り主の入力、アイテム選択、チェックアウト、完成リンクのコピーと共有を一般的なフローとして考えられる。この Virtual Care Package のような体験では、コピーできたことと、安全に意図が伝わったことを同じ成功として扱わない点が重要だ。
状態を「送った後」まで書く
リンクの生成だけを終端にすると、失効や再送、コピー失敗を後から例外として足すことになる。最初から送信後の状態を置いておくと、確認文言とテスト条件を作りやすい。
受取人がまだ開いていない状態を計測するかどうかは、公開UIからは判断できない。だからこそ設計では、閲覧状況を表示する前に、何を取得するのか、送り主にどう伝えるのか、受取人に不要な監視感を与えないかを別途確認する必要がある。
会話のための最小データモデル
// これは実装の推測ではなく、要件レビュー用の提案例である。
type PackageDraft = {
recipientLabel: string;
senderLabel: string;
items: Array<{ id: string; kind: "note" | "link" | "media" }>;
sharing: "not-created" | "link-ready" | "revoked";
};
type ShareMessage = {
packageId: string;
note: string;
replyExpected: boolean;
};
replyExpected は送信ボタンの値である必要はない。コピーする文面の設計で「返信は不要」「都合のよいときに見てね」と明示できるかを確認するフラグとして置いている。気遣いのUIで、暗黙の返信期限を生まないことは機能要件に近い。
仕様レビューで使うテストケース
| 条件 | 期待する挙動 | 確認する理由 |
|---|---|---|
| 宛先が未入力 | 次の工程へ進めず、修正箇所が分かる | 作成後に宛先の意味が曖昧にならない |
| アイテムが0件 | 空のパッケージを共有しない、または明示確認する | 受取人の混乱を避ける |
| コピーに失敗 | 成功表示を出さず、再試行手段を示す | 「送れたつもり」を防ぐ |
| 長い名前や絵文字 | プレビューと共有文面が崩れない | モバイルを含む表示品質を守る |
| 無効なリンク | 内容や宛名を過剰に露出せず、次の行動を示す | 共有後の境界を守る |
リンク共有は、暗号化や一人だけが閲覧できることと同義ではない。公開前に、URLを知る人の扱い、期限の有無、取り消し方法をUI文言で正確に説明することが必要だ。画面がそれらを提供していると仮定してはいけない。
受取人視点の受け入れ基準
最後に、作成者ではなく受取人の最初の30秒を確認する。誰から来たか、何を開くのか、今すぐ返事をしなければならないのかが短い文で分かるだろうか。説明なしでは意味が通らないアイテムや、共有してはいけない個人情報が混ざっていないだろうか。
共有リンク型の贈り物は、機能を増やすほど丁寧になるわけではない。送り主が理解してから渡せて、受取人が自分のペースで受け取れること。その二つを状態、文言、失敗時の導線に落とし込めたとき、体験ははじめて要件としてレビューできる。