AMP Storiesを試すときは画像を並べる前に通常記事へ残す説明とlinkを決める

AMP Storiesを試すときは、通常の記事を短く切って画像を並べることから始めません。storyで最初に伝える一つの場面を決め、詳しい条件、根拠、問い合わせへの入口は通常のarticleへ残します。storyはmobileでtapしながら読み進める見せ方であり、料金、対象条件、申込みの方法までを全て置き換える形式ではありません。読者が最後まで見たあとに、本文、商品ページ、問い合わせのどこへ進むかを決めてから作ります。

Google Developers Blogは2月13日、AMP StoriesをAMP Projectのdeveloper previewとして案内しました。AMP Storiesは、newsやinformationを画像、video、graphicとともにtapして読むmobile向けのformatです。publisherは自分のsiteにAMP StoryのHTML pageを置き、site内のほかのpageからlinkできます。mobile browserでpublisher名を検索すればGoogle Search上でも試せると案内されています。ただし、この段階ではdeveloper previewであり、Googleは今後ほかのproductでの表示とSearchでの見せ方を広げる予定としています。

storyで伝えることと通常articleで説明することを分ける

storyに向くのは、写真、短いvideo、図で順序を見せる内容です。イベント会場へ行くまでの流れ、商品ができるまでの三工程、施工前後で変わる場所のように、一枚ごとに場面が切り替わる説明は読み進めやすい。一方、細かい価格条件、契約の範囲、比較表、長い手順、資料の出典は、通常articleの方が読み返しやすい。

たとえば、新しい商品を紹介するとき、storyでは特徴を三つの場面に分け、写真と短い説明で見せられます。しかし、サイズ、価格、発送条件、購入方法は商品pageに残します。storyの各画面に文章を詰め込むと、tapして読む形式の長所が消え、通常articleにも同じ説明を二重に書くことになります。逆に、storyに写真だけを置くと、興味を持った読者が次に何を確認すればよいか分かりません。

公開前に、次のように役割を決めます。

この表は、全てのcontentを三つ作るためのものではありません。通常articleだけで十分なら、storyを作らない方がよい。写真やvideoを使うことで、読者が短い順序を理解しやすくなるときだけ、storyを別の入口として使います。

最初のstoryは一つの問いへ答える

developer previewのformatを試すときは、companyの全紹介や複数商品の一覧を最初のstoryに入れません。一つの問いへ答える小さな内容を選びます。「このサービスでは何をしてくれるか」「初めて来る人はどこを見るか」「この商品はどの順で使うか」のように、一枚ごとの役割を決められる問いが向いています。

たとえば、店舗で受け取る注文の流れをstoryにするなら、一枚目で受取方法を示し、二枚目で受取場所を示し、三枚目で受取時間を示します。その後に、詳しい注文条件があるpageへlinkします。注文できる商品、在庫、支払方法、変更や取消の条件までstory内で説明しようとすると、画面の文字が多くなり、読者がtapするたびに判断を止めることになります。

一枚の画面には一つの判断材料を置きます。写真なら、何が写っているかを短く説明します。videoなら、再生しない人にも場面が分かる題名を置きます。文字が読める背景か、buttonとlinkが押せる場所かも確認します。視覚的なformatでも、文字を読まなければ判断できない条件を画像の中だけへ入れないようにします。

最後の画面は次のpageへ進む理由を示す

storyを最後まで見た人は、関心を持っている可能性があります。そこで「詳しくはこちら」だけを置くより、どのpageへ行くと何が分かるかを示します。「価格と注文条件を見る」「施工の詳しい手順を読む」「予約できる日時を確認する」のように、link先で得られる情報を短く書きます。

link先は一つに絞ります。storyの最後にtop page、商品一覧、SNS、問い合わせ、採用pageなどを並べると、読者はどれを選べばよいか分からない。storyで伝えた場面の続きを最も詳しく読めるpageを選びます。問い合わせを目的にするなら、formへ直接送る前に、料金や対応範囲を読めるpageを挟んだ方が、相談内容を具体的にしやすい場合もあります。

storyと通常articleをlinkで結ぶときは、URLを誰が管理するかも確かめます。campaignが終わるたびにstoryを消すなら、そこからlinkした通常articleを残すのか、別の案内へ移すのかを決めます。外部serviceのURLや短縮URLだけへ頼ると、storyを見返した人が必要な情報へ戻れなくなることがあります。自分のsiteに置くHTML pageと通常articleのURLを、公開後も管理できる形にします。

速さや表示場所を目的にして本文を減らさない

AMP StoriesはAMPの技術基盤を使い、presetのlayout template、standardized UI control、sharingやfollow-on contentのcomponentを持つformatとして案内されています。作るための技術的な手間を減らすことと、contentの判断を減らすことは別です。formatが用意されていても、どの写真を使うか、何を本文へ残すか、link先はどこか、公開後に誰が更新するかは決める必要があります。

Google Searchで見えることを期待してstoryを作っても、どの検索で表示されるか、読者がどこまで見るか、問い合わせが増えるかは決められません。developer previewの段階では特に、表示場所だけを狙って大量に作らない方がよい。一つのstoryを公開し、通常articleへのlink、画面の読みにくさ、更新の手間を確認してから増やします。

AMP Storiesを使うなら、最初に通常articleへ残す条件と出典を決めます。次にstoryで答える問いを一つ選び、各画面の役割を分けます。最後に、読者が次に読む一つのpageへlinkします。この順序なら、新しいformatを使っても、画像を増やすことと読者が判断できることを混同しません。