商品・注文設計
名入れオプションの動作確認。入力から受注明細まで試す6パターン
文字、数量、追加料金を変え、買う人の画面とお店に届く内容を照合する公開前の確認表。
この記事の内容
文字、数量、追加料金を変え、買う人の画面とお店に届く内容を照合する公開前の確認表。
確認は商品ページの見た目で終わらせない
名入れ欄が表示されても、注文後の明細で文字が読めなかったり、追加料金が数量と合わなかったりすれば制作時に迷います。購入者側の入力、カートの内訳、お店側の明細を一つの条件でつなげて確認します。これは特定サービスの機能を保証する手順ではなく、運用上の点検例です。
本番で注文を試す前に、サービスのテスト機能や決済の検証方法を確認します。実際の決済、在庫減少、購入者へのメールが発生する環境では、その影響を把握してから行ってください。
最小・上限・空欄を別のケースにする
普段の名前だけで試すと、長い文字列や未入力の問題が残ります。「必須欄が空」「許可する最長文字」「上限を一文字超える」のように期待する結果を先に書きます。絵文字や記号を扱わないなら、入力時の案内と注文後の対応が一致するかも見ます。
文字数の数え方はシステムによって違う場合があります。見た目の一文字を何文字と数えるか推測せず、実際の画面で確認し、商品説明のルールと矛盾しないようにします。
料金と数量は掛け算の位置を確認する
架空の設定で商品1個1,000円、名入れ1個200円なら、同一仕様2個は2,400円です。一注文200円の料金なら2,200円で、同じ「追加200円」でも結果が変わります。送料や別の費用は分けて確認してください。
名入れあり・なしを同じカートに入れた場合も試します。片方の入力や追加料金がもう片方へ移らないか、明細で各商品の仕様を区別できるかを見ます。
修正後は問題の条件をもう一度試す
記録には条件、期待する表示、実際の表示、結果、確認日を残します。「直した」で終わらず、同じ条件で入力から明細まで確認して完了にします。変更が数量計算に関わるなら、1個と複数個の両方を再確認します。
公開前の確認と、日々の注文の検品は別です。設定を変更した日にもこの表を使い、受注明細を制作担当者が理解できるか確認しましょう。
6パターンの確認表
実際の商品設定で期待する結果を先に書き、結果欄を埋めて使います。以下の金額は本文と同じ架空例です。
| 条件 | 期待する結果の例 | 確認箇所 |
|---|---|---|
| 必須の名入れ欄を空にする | 未入力の案内が出る | 入力画面 |
| 許可する最大文字数を入れる | 全文字が明細まで残る | 画面と明細 |
| 上限を一文字超える | 定めた上限の案内が出る | 入力画面 |
| 名入れありを1個 | 商品と加工で1,200円 | カートと明細 |
| 同じ仕様を2個 | 1個単位の加工なら2,400円 | 数量と内訳 |
| 名入れあり1個・なし1個 | 2,200円、仕様を区別できる | 商品別の明細 |
送料や割引などはこの例に含めません。実際の設定に合わせて金額と期待する動作を書き換えてください。
| 架空の明細 | 名前 | 数量 | 商品＋名入れ |
|---|---|---|---|
| 行01 | YUKI | 1個 | 1,200円 |
| 行02 | TAKU | 2個 | 2,400円 |
| 合計 | 名前は行ごとに保持 | 3個 | 3,600円（送料別） |
同じ商品を二行にして、名前が入れ替わらないか試す
架空のテスト注文として、同じキーホルダーを「YUKI・1個」と「TAKU・2個」の二行に分けます。見た目が同じ商品でも、名入れの内容が違うためです。カートで二行のまま残るか、数量を変えたときに片方の名前まで変わらないか、店に届く明細でどの名前を何個作るか読めるかを順に見ます。合計3個という表示だけでは、制作指示が正しく届いたとは判定できません。
一個1,000円、名入れは一個200円という架空の条件なら、前者は1,200円、後者は2,400円、商品と名入れの合計は3,600円です。送料はこの計算に含めません。名入れ料金が注文単位の店なら別の計算になります。テスト結果には金額だけでなく、料金を掛ける単位も書きます。
一度直したあとに、カート・メール・受注明細を読み合わせる
入力を間違えた購入者を想定し、「YUKI」を「YUKO」へ直すケースも用意します。画面上の変更が正しくても、注文通知に古い文字が残ると制作担当は迷います。購入前の変更をどこで受け付ける設計かを決め、その正規の操作で修正してから、購入者側の表示と店側の記録を比べます。ブラウザの戻る操作だけで入力内容を確定した扱いにはしません。
記録は「試した操作／期待する結果／実際の表示／修正する場所」の四列にします。問題を直したら同じ操作を再度試し、最初から入力するケースも通します。検証環境の注文番号と確認画像を残し、実注文の住所や決済情報を共有用の資料に転載しないようにします。
公開の判定は、制作担当が明細だけで作れるか
確認する最後の人を、画面を作った人だけにしない方法があります。制作担当へテストの明細を渡し、どの文字を何個作るか言い直してもらいます。「注文者へ聞かないと分からない」という欄があれば、必須入力や明細の見せ方を修正する候補です。書体や色を扱う商品は、文字そのものと選択肢の名前も別々に読める必要があります。
これはテスト注文の点検例で、特定のカートが対応する機能の説明ではありません。本番決済を使う試験ではなく、利用サービスの検証方法に合わせて実施します。注文が制作へ渡る形は商品ごとの行番号と公開前のチェックでも整理しています。
