Information Architecture (IA) — Sitemaps and Wireframes

This section reveals the structure of problems that actually occur in projects that skip information architecture—including broken user flows, inflated bounce rates, and the mechanism by which costs balloon in later stages.

"The design looks great, but somehow users can't find the page they're looking for"—this is a complaint heard frequently in web development. It's not uncommon for a site to launch, and then for analytics to reveal bounce rates above 70%. In the vast majority of cases, the root cause is that the Information Architecture (IA) phase was skipped entirely.

Company A, a services business, commissioned a web development firm to renew their corporate site. After a brief discovery session, the firm went straight to creating design mockups, and Company A approved the visuals and launched the site. But after launch, inquiry volume reached only one-third of expectations. Checking Google Analytics revealed a site-wide conversion rate of just 1.2%—an extremely low number.

Investigation revealed the problem. There was no link from the services listing page to the inquiry page; users either had to find it in the global navigation or scroll all the way to the footer. The services were also divided into three categories, but the navigation labels used internal company terminology that meant nothing to a first-time visitor.

Fixing these issues required the development firm to charge an additional 600,000 yen and one and a half months of work. Had a formal IA design phase been conducted, these structural problems would have been caught before a single pixel was designed, and there would have been no additional cost.

Projects that skip IA tend to fail in predictable, recurring patterns. First, design gets started before the content volume is confirmed, so when the actual text and images are dropped in, the layout falls apart. Second, because each page's role is never defined, similar content ends up scattered across multiple pages, diluting SEO value. Third, every time the global navigation changes after design is underway, every page must be redesigned.

All of these are problems that can be prevented at the design stage. The next section provides a systematic breakdown of what IA actually is.

This section organizes the definition and four components of IA and presents the overall design picture that both clients and directors should share.

Information Architecture (IA) is the practice of organizing, classifying, and structuring content in websites and applications so that users can find the information they need. The concept was systematized by Peter Morville and Lou Rosenfeld in their book Information Architecture for the World Wide Web (O'Reilly) and is now widely recognized as the foundation of UX design.

IA consists of four components.

Organization System

This component determines how content is classified and grouped. Common classification axes include topic-based (products, services, company information), task-based (buy, consult, download), user attribute-based (individual, corporate, partner), and chronological (latest news, archives). The core design question is which axis best matches the user's mental model—the intuitive structure of information that users carry in their heads.

Labeling System

This component determines the words used to represent each classified piece of content. "Company Profile" or "About Us"? "Contact" or "Talk to Us"? The same content can produce vastly different comprehension speeds and click-through rates depending on the label. Using internal jargon or industry-specific terminology results in navigation that first-time users simply cannot parse.

Navigation System

This component designs the mechanisms users use to move through the site. Global navigation (shared across all pages), local navigation (within a specific section), breadcrumbs, and related links are combined to ensure users can reach their destination from any page.

Search System

This component handles the design of site search. It defines the placement of the search bar, the scope of searchable content, and the sort order and filter options for search results. On content-heavy sites, navigation alone cannot cover all user needs, making search system design especially critical.

These four components are interdependent: change the organization system, and labeling and navigation must change with it. IA design is the work of building this entire picture with consistent logic.

The key point for clients to understand is that IA comes before visual design—the sequence is sitemap first, then wireframes, then visual design, then coding. Respecting this order minimizes rework in later stages.

This section explains the hands-on process for creating a sitemap—the first deliverable of IA design—along with guidance on avoiding common design mistakes.

A sitemap is a document that represents the entire page structure of a website as a hierarchy. It shows which pages exist and what parent, child, and sibling relationships connect them. It is sometimes confused with the navigational page published for users on the site itself; in this context, we are discussing the sitemap as an internal design document shared among the project team.

Step 1: Create a Content Inventory

Start by listing all the content the site will need. For a redesign, record every existing page in a spreadsheet. For a new site, enumerate necessary content based on business objectives, target users, and competitive analysis. At this stage, focus on exhaustiveness—don't worry about classification yet.

Step 2: Group Content via Card Sorting

Group the inventoried content from the user's perspective. The most reliable method is card sorting—a research technique where participants freely sort cards labeled with each piece of content into groups. When budget or time is limited, running a simplified version with internal stakeholders who approximate the target audience still yields useful signal.

The results of the grouping exercise determine the top-level navigation categories (first tier). Generally, five to seven items in the global navigation is considered optimal from a cognitive load perspective.

Step 3: Design Hierarchy Depth

Design the internal structure of each group (second and third tiers). The deeper the hierarchy, the more clicks users need to reach their destination, increasing the risk of abandonment. As a practical guideline, design so that primary content is accessible within three levels.

One trap to watch for is "orphan pages." When migrating content during a redesign, pages from the old site often get left in a "keep for now" state without being positioned in the sitemap. These pages become unreachable from navigation and unindexed by search engines. Establish a rule at the design stage: if a page doesn't appear in the sitemap, it doesn't get built.

Step 4: Assign URLs and Page IDs

Assign a URL structure to each page in the sitemap. URLs should reflect the content's position in the hierarchy, and changing them after launch resets SEO value and breaks external links. Finalizing URL architecture at the design stage avoids this costly rework.

Step 5: Record Owner, Priority, and Status

On large sites, note the content owner, publication priority, and production status for each page directly in the sitemap. This makes overall progress visible without requiring a separate project management tool.

Once the sitemap is complete, the client and production team review it together against the same document, agree on any additions, deletions, or moves, and only then proceed to the next phase (wireframes). Starting wireframes without this agreement results in the page structure changing mid-project, invalidating large portions of completed wireframe work.

This section explains the hands-on process for creating wireframes that define the information layout for each page based on the structure established in the sitemap.

A wireframe is a monochrome blueprint defining the layout and priority of information elements on a web page—text, images, buttons, forms, and so on. It excludes visual elements like color, typography, and illustration, and focuses entirely on the information design question: "What goes where, and at what size?"

Creating wireframes lets designers focus on visual expression and lets clients focus their review on the soundness of the information design rather than aesthetic preferences. Without wireframes, feedback like "that button should stand out more" or "that text block isn't needed" ends up being processed as visual design revisions, multiplying production hours.

Step 1: Define Content Blocks

List the content elements needed for each page. For a homepage, this might include: hero area (headline + CTA), service overview, proof points/numbers, testimonials, latest news, and a footer CTA. Rather than aiming for exhaustiveness, focus on the elements necessary for that page's business objective—whether that's driving conversions, building credibility, or delivering information.

Step 2: Determine Information Priority (F-Pattern, Z-Pattern)

Users tend to read web pages top to bottom and left to right. What appears in the above-the-fold area (visible without scrolling) directly affects both bounce rate and conversion rate. The foundational approach is to place high-priority information at the top and left, and secondary CTAs and supplementary content lower and to the right.

Step 3: Design Mobile-First

On most sites today, mobile traffic exceeds desktop. A rational approach is to determine information priority using the mobile screen as the baseline, and then handle desktop as a layout expansion—showing content side by side or adding supplementary elements. Starting with the mobile wireframe and then expanding to desktop ensures information priorities stay clear.

Step 4: Design CTAs

CTA design is the heart of wireframing. Verify that the path from "which page" through "which CTA" to "which destination page" is complete. In particular, use the wireframe stage to confirm that multiple routes exist to reach conversion pages (inquiry, purchase, resource download, etc.).

Step 5: Estimate Content Volume

Note the actual text length (character count) and image aspect ratios in the wireframe. Vague instructions like "text goes here" create a disconnect between the content volume the designer assumes and the actual content, resulting in "the copy is too long and breaks the layout" problems discovered after the design is finalized.

Regarding wireframe fidelity, adapt to the project stage. At the early structural-confirmation stage, hand-drawn sketches or rough wireframes (low fidelity) are sufficient. For client review and developer handoff, a polished version in a dedicated tool (Figma, Balsamiq, etc.) is appropriate (high fidelity).

This section presents the process for jointly reviewing IA deliverables, along with a checklist for formally approving the start of visual design.

IA design deliverables—sitemaps and wireframes—are not documents that a production team creates and presents unilaterally. They are the product of a collaborative dialogue between clients and developers. Skipping this collaborative process leads to the worst-case scenario: structural problems discovered after the design is finished, requiring a restart from scratch.

Sitemap Review Criteria

When reviewing a sitemap, clients should verify:

• Does a page exist for every business objective (inquiry generation, recruitment, branding, etc.)?
• Is the content classified in the way the target users would intuitively search for it?
• Are navigation labels in plain user-friendly language, free of internal jargon and industry terminology?
• Is the structure flexible enough to accommodate future content additions (new services, products, hiring pages, etc.)?
• Are there any redundant pages or duplicated content?

Wireframe Review Criteria

When reviewing wireframes, focus on the soundness of the information design—not visual preferences.

• Is each page's business objective clearly defined, and does the CTA correspond to that objective?
• Are multiple routes to conversion pages accessible from multiple pages?
• Is the most important information and primary call to action placed in the above-the-fold area?
• Does the information hierarchy match the user's expected reading pattern?
• Does the layout remain functional on mobile?

Formalizing Approval

IA design approval should be documented in writing—via email or a project management tool—rather than made verbally. Since this approval marks the start of the design phase, both client and developer should agree in advance that post-approval changes to the sitemap or wireframes constitute scope changes subject to additional cost and timeline adjustments.

From a change management perspective, it is recommended to distinguish between "minor revisions (label changes, adding or removing elements)" and "structural changes (hierarchy modifications, page consolidation or splitting)"—with the latter requiring re-estimation and re-approval.

Completion Criteria for the IA Design Phase

The following conditions define completion of the IA design phase and authorization to begin visual design:

1. The sitemap's page count, hierarchy structure, and navigation items have been approved by both client and production team.
2. Wireframes for high-priority pages (homepage, key services, inquiry page, etc.) are complete and approved.
3. Content owners and deadlines for each page are confirmed.
4. URL architecture is finalized, and a list of old URLs requiring redirects has been created.
5. Content volume affecting design (character counts for primary copy, image quantities, presence of video) is confirmed.

If visual design begins without these conditions met, the risks and costs should be formally documented and accepted by the client, with an advance agreement in place for any resulting change costs.

IA design may appear unglamorous, but it is the phase with the greatest impact on the overall ROI of a website. Investing time and budget into "what goes where" before visual design ultimately maximizes the business outcomes that the site is built to achieve.

References

• Nielsen Norman Group. "IA vs. Navigation." Nielsen Norman Group.
• Usability.gov. "Information Architecture." U.S. Department of Health and Human Services.
• Nielsen Norman Group. "Site Map Usability." Nielsen Norman Group.
• Nielsen Norman Group. "Wireflows: A UX Deliverable for Workflows and Apps." Nielsen Norman Group.
• Balsamiq. "What Are Wireframes?." Balsamiq Studios.
• Adobe. "Information Architecture in UX Design." Adobe XD Ideas.
• Wikipedia. "Information architecture." Wikipedia.