WordPress のサイトを作るとき、サイトマップやワイヤーフレームを見ながら、何をどう機能に充てていこうか考える作業をします。
それを「WPサイトの設計」と呼んでいます。
WPサイトを設計するときに考えていることをまとめました
この記事はこのページを含め、6つの記事で構成されています。
- はじめに（この記事です）
- 投稿タイプ編 サイトマップにあるページをどの投稿タイプに当てはめるか？判断のコツを解説しています
- URL編 WPでサイトを作る時、各ページのURLがどのように決定されているか解説しています
- テンプレート編 サイトを作る時にどんなテンプレートファイルが必要になるか解説しています
- カスタムフィールド編 フィールドってそもそも何というところから、設計のコツを書いています
- まとめ編 いつも使っているプラグインのことや、管理画面、マニュアルとレクチャーなどについて思うことを書いてあります
あくまで、とあるコーダーの個人の思想です
WPで作ることが前提なら、サイトマップやワイヤーフレームの段階で、その辺りのことを決めてくれているディレクタさんもいるのかもしれませんが、あまりそういうことはないので、お引き受けするとき、見積もりをお出しする際にそれらの資料を元に設計を考えて、費用を算出します。
WPサイトの設計をするときに何を考えているか、以下にあげて見たいと思います。コーダーの頭の中を少し分かってもらえたら嬉しいです。
まずはサイトマップを確認
だいたい、トップページがあって、ツリー構造で「◯◯について」「商品紹介」「サービスの特徴」「我が社の強み」「会社概要」「お問い合わせ」とかとかのページがあります。他にも、「お知らせ」「スタッフブログ」「実績紹介」とかがよくあるでしょうか。そういうものをWPの機能のどこに当てていくかを考えます。
それをしながら、サイトマップに抜けているページがないか、確認します。例えば、要件定義に「サイト内検索」があるのに、検索結果のページがない、個別のページ行くための一覧のページが必要そうなのに抜けている、お問い合わせフォームでもサンクスページの必要・不要やプライバシーポリシー、特商法に基づくページなどです。
各ページのワイヤーフレームをもらっていれば、ワイヤーのナビゲーションを確認して、サイトマップにあるページと対応しているか確認します。
URLの指定がある場合は特に注意が必要
WPで作るサイトは、URLがページを呼び出すためのクエリになります。ディレクタやクライアントが思っているようなURLにするのが困難な場合があるので、指定されているURLでの設計が可能かどうかよく確認します。
連載3回めぐらいの記事で触れる予定なので、詳しくはそちらも参照ください。
404ページを忘れないで…
404というのはhttpのエラー番号ですが、リクエストされたURLに対して該当するWebページが見つからなかった場合に返ってくるエラーです。サイトのナビゲーションが正確に設計されていればこのページは決して表示されないため見過ごされがちですが、必要なページです。滅多に表示されないんだからテキトーに、という考え方もあるかもしれませんが、リニューアル後のサイトだと頻繁に表示される羽目になるページでもあります。ちょっと気の利いた404ページは、もしかしたらユーザーフレンドリーの点数を上げることにも繋がるかもしれません。サイトマップになっていたり、アクセスの多いページへの誘導になっていても便利かもしれませんね。
要件定義とサイトマップがないと見積もれない
WPサイトを作るとき、設計を考えると大体の作業量が見えます。作業量が見えればお見積もりを書くことができます。この作業量をある程度正確に見積もるためには要件定義とサイトマップが必須です。
要件定義とは、サイトで何ができるのかを記した一覧です。例えば、
・お知らせはクライアントで更新できる
・お知らせには「イベント」「サイトの更新情報」など分類が欲しい
・お問い合わせフォームが必要（2種）
・サイト内検索ができる などなど
これらが一覧化されていると望ましいです。
要件定義の書き方については、一度まとめて見たいと考えています。
サイトマップは、サイト内の全ページを一覧にしたものです。全てのページが拾われていることと、各ページへたどり着くための道筋が見えていることが重要です。トップページを頂点にしたツリー構造で描かれることが多いと思います。単に必要なページの一覧という形で提出された場合は、各ページにたどり着く道筋の例をいくつか確認した方が無難かと思います。ワイヤーフレームと照らし合わせて、それぞれのページにたどり着くための必要なナビゲーションが揃っているかを確認するのも重要です。
個人的には、要件定義とサイトマップとワーヤーフレームは、この順番で考えていくのが妥当と思いますが、要件定義をまずは思いつくだけ書いて、続いてサイトマップを書いて見たら追加要件が見つかって直して、ある程度できたところでワイヤーフレームを書いているうちにまた追加の要件やページが見つかって。。。というふうに、行きつ戻りつしながら進めることが多いです。なので、最初はとにかく手書きで、ささーっとやんちゃに書いて、8割型出来上がってから清書します。理想を言えばこの段階でもうひとり誰かと相談して抜けながないか確認してから清書します。
まとめ
脱線しすぎました。とにかく、WPに限らずサイトのコーディングには要件定義とサイトマップがとても重要な役割を果たします。
次は、サイト内のそれぞれのページを、WPの投稿タイプに当てはめていく作業になります。明日の更新をお待ちください！
とてもわかりやすいです、続きが読みたいです^_^
ワイヤーフレームと照らし合わせて、それぞれのページにたどり着くための必要な…ところですが、これ遷移図の事でしょうか？もう少し詳しく読みたいかなーと思いました。私も最初遷移の見える化が分かってなかったので汗
サイトマップと遷移図はちょっと違うものじゃないかなーと考えてます。
サイトマップは、サイトの情報構造を明らかにして、全てのページがどのような体系にあるかを示すものかと。
それらの各ページを、実際にどんな風に遷移するのか（各ページへたどり着くための道筋）、というのはフローチャートとかいうもので、サイトマップに書き添えられてたりする感じのものかなあ、と思っています。
トップページ＞お知らせの一覧＞個別のお知らせ詳細という情報構造を示すのがサイトマップで、でもトップページにお知らせ最新5件がピックアップされてて直接詳細にたどり着ける道筋がある、という情報が「画面遷移」かなあ、と思います。
言葉のアヤ？難しですね、、、、
ワイヤーフレームは、サイトマップや遷移図をもとに作る次の資料と考えていて、WFに書かれたナビゲーションが、本当にサイトマップに書かれた全てのページにたどり着けるように設計されているか〜？を確認するのは大事、という話でありました。