最新のサイトマップの設計
私の意見では、サイトマップはおそらく、IAまたはユーザーエクスペリエンスプロジェクトにとって最も重要な成果物です。他の作業を開始する前に、Webサイトの構造を固定する必要があります。
以前は、異なる領域ごとに別々のページを持つことが許容されていましたが、現在は、Div、タブ、Ajaxなどの可能性があるため、同じページ内にコンテンツの複数の領域を持つことがより論理的に理にかなっています。
個々のページに複数の追加コンテンツが含まれるようになった場合、サイトマップを作成するにはどうすればよいですか？
例として、カスタマーレビューのタブ/ AJAXエキスパンダー/ UpdatePanel（または構造を固定したときに最適に機能すると考えられるもの）を含む各製品のランディングページを作成するという考えでeコマースサイトに取り組んでいます。ビデオ、完全な製品仕様など.
- これには、これらの各タブのサイトマップに個別のページNode=がある必要があります（ある場合、標準ページからこれらをどのように識別する必要がありますか？）
- または、ワイヤフレーム自体に十分な詳細がある場合は、単一のページノードで十分です。
私は両方を提案するかもしれません。 :)標準のサイトマップを作成してから、動的な詳細情報が必要な場合は、フロー図（サイトマップとは別のページ）を参照します。これにより、「混乱」を最小限に抑えることができますが、複雑さを区分化できます）、またはモジュール（別のページ）に含まれるもののリストで構成されます。
super-high-level "wires"を作成して、その状態のコンテンツのタイプを示すだけでなく、必ずしも場所やサイズなどを示すこともありません。これはクライアントにとって難しい場合があります。でも、文字通りすべてを取ります。
ページのタブを説明するために（これらはAJAXなどとはかなり異なると思います。コンテンツdivではなく、ナビゲーション指向です）、ボックス内のボックスを使用しました。
それは役立ちますか？
ボックスとページの名前だけで一般的なサイトマップを作成し、コンテンツインベントリ（テーブル）をそのサイトマップに添付します。したがって、ページのタブやその他のコンテンツは、私の場合はサイトマップではなく、インベントリに記述されます。コンテンツインベントリはコンテンツの概要を示し（非常に簡単です）、サイトマップはナビゲーション構造を示します。例- スクリーンショット1 ＆ スクリーンショット2
簡単に理解できますが、欠点は、サイトマップとインベントリの2か所に変更を反映する必要があることです。 （私はOmnigraffleを使用しており、テーブルとグラフの関係を自動化する方法がわかりません。）
Dunnoならあなたのケースで使えます。私は自分の会社で設計プロセスを文書化するための独自の基準を設定する自由があります。時には、私が聞いたような文書を混在させることができません。