Information Architecture

Purpose

This section defines the organizational logic underlying the sitemap and navigation. It establishes how content is categorized, labeled, and cross-referenced to align with users’ mental models.

Information architecture answers: How is content organized so users find what they need?

This differs from:

• Sitemap (Section 4): What pages exist and how they relate hierarchically
• Navigation (Section 5): How users move between pages visually

Information architecture defines the conceptual structure that makes both work.

Organizing Principles

Multiple Entry Points

Research shows buyers approach products from different mental models:

Implication: The same product must be discoverable through multiple organizational schemes simultaneously.

A silicone masking cap (e.g., KMRC series) should be findable via:

• Category: Products → Caps → High-Temp Masking → Silicone Caps
• Application: Applications → Masking Protection → Powder Coating → Recommended Products
• Industry: Industries → Automotive → Masking Solutions
• Brand: Brands → MOCAP → Browse Products
• Search: “KMRC”, “silicone cap”, “powder coating mask”, “high temp cap”

Research basis: Competitive analysis found winning sites provide “multiple navigation paths (by application, industry, product type)” while MOCAP’s current site uses “product-code navigation” that requires users to already know what they need.

Use-Case Hierarchy Over Product Taxonomy

Traditional approach (failing):

Products > Caps > Threaded Caps > ST-300 Series

Modern approach (winning):

Applications > Masking > High-Temp Paint Masking > Products

Why: Buyers think in problems (“protect threads during powder coating”), not taxonomies (“threaded plug”).

Research basis: Competitive analysis showed Caplugs and Pöppelmann outperform competitors by organizing around use cases. Customer survey confirms: customers selected “Better search” (73%) over any organizational improvement, indicating the current taxonomy doesn’t match how they think.

Implementation: The sitemap maintains product taxonomy for Veterans who know what they want, while the Applications and Industries sections provide problem-based entry for Problem Solvers.

Shallow Depth for Common Tasks

Maximum clicks to reach any product: 3

Research basis: Competitive analysis notes “over-filtering (landing on ONE product)” and “too many steps (>5 = abandonment)” as common failures. CrazyEgg data shows users scan only the first 8-20 rows of product tables before abandoning.

Taxonomy Structure

Product Taxonomy

The product taxonomy follows a four-level hierarchy:

Note: The sitemap includes an “All Products” aggregate view in addition to the 10 categories, providing filtered access to the complete catalog.

Level 1: Categories

Level 2: Subcategories

Subcategories group products by:

• Form factor: Tapered, flanged, straight
• Function: Sealing, general-purpose, pull-tab
• Thread type: BSP, metric, NPT, JIC
• Material: Vinyl, silicone, EPDM
• Shape: Round, square, rectangular

Level 3: Series

Series represent product families sharing:

• Base design and tooling
• Material options
• Size range

Example: T Series (Tapered Caps) contains 50+ size variants in multiple colors.

Level 4: SKU

SKUs are unique variants defined by:

• Series code
• Size specification
• Color code
• Material variant

Example: T-250-RD1 = T Series, 0.250” size, Red, Standard material

Application Taxonomy

Applications organize around customer problems:

Cross-reference rule: Application pages link to products; products do not “belong” to applications. A silicone cap appears in Masking Protection, Thread Protection, and Shipping Protection based on use case.

Industry Taxonomy

Industries are flat (single level) with curated content:

Research basis: Personas analysis identified these seven industries. Competitive analysis showed Pöppelmann succeeds with “vertical-specific landing experiences” that “speak each industry’s language.”

Labeling Conventions

Product Naming

Current problem: Product codes are opaque. MOCAP Catalog Analysis notes “Codes are opaque (What is TWF? RN? GPM?)” as friction point.

Naming hierarchy:

Labeling rules:

• Use customer language, not internal codes, in navigation
• Display series codes secondarily (for Veterans who know them)
• Include key differentiator in name (material, form, function)

Example transformation:

Attribute Labeling

Standardize attribute labels across all products:

Measurement system support:

• Default to user preference (stored in account/cookie)
• Provide a toggle on all specification displays
• Support: Decimal inches, Fractional inches, Metric (mm)

Research basis: Customer survey feedback: “Measurements given in engineering, fractions, and metric scales. Be able to select which scale I wish to use.” Live call interviews: Linda Yang requested a metric/imperial toggle for the China site.

Terminology Glossary

Define standard terms for customer-facing content:

Research basis: Customer survey feedback: “The nomenclature was all new to me and I didn’t realize some tubes were closed and some were open.” First-time buyers need clear terminology, not assumed knowledge.

Cross-Reference System

Product to Product Relationships

Implementation rule: Cross-references are bidirectional. If Product A links to Product B, Product B links to Product A.

Research basis: Customer survey feedback: “Maybe a reference chart showing which caps fit specific nominal size tubes?” Currently, customers must “pretend to order” tubes to see compatible closures; cross-reference data exists, but it is buried in transaction flow.

Product to Content Relationships

Implementation rule: Content links appear on product pages, not just in the Resources section.

Content to Product Relationships

Implementation rule: Content pages always include a path to purchase.

Search Architecture

Search Scope

Search must index:

Query Types

Research basis: Search log analysis shows most queries are part numbers (e.g., “RVC9044”, “KMRC1.875-2”). Current search returns errors for valid part numbers. Ildar Zibarov estimates 20-25% sales increase from fixing search.

Search Results Organization

Results display in priority order:

“No results” handling: Never show empty results. Always provide:

• Suggested search terms
• Browse by category links
• Contact support option

Research basis: Competitive analysis notes “Dead ends (no results + no alternatives)” as a common failure.

Autocomplete Behavior

Autocomplete suggests:

Suggestion types:

• Product SKUs matching input
• Series codes matching input
• Category names matching input
• Recent searches (logged-in users)

Research basis: Search currently receives only 6-7% of homepage clicks despite 73% of customers prioritizing better search. Autocomplete reduces friction for users who know partial information.

Filtering and Attributes

Product Listing Attributes

Standard attributes for product listings:

Attribute behavior:

• Show count of matching products per attribute value
• Allow multiple selections within an attribute (OR logic)
• Apply AND logic between attributes
• Update counts dynamically as filters are applied
• Persist filters in URL for shareability

Research basis: CrazyEgg data shows 46-54% of clicks on product tables. Users expect filtering. Customer survey: 0 respondents selected “Sortable/filterable product tables” as an improvement, but 73% selected “Better search,” suggesting they don’t trust the current filtering and default to search.

Table Sorting

All product tables support sorting:

Default sort: By size (smallest to largest) for dimensional products.

Research basis: CrazyEgg shows users click column headers expecting sorting. 11-12% of table interactions result in dead clicks because current tables are static. “Interactive table functionality is not a ‘feature request’, it’s a baseline expectation.”

Content Types

Product Detail Page (PDP)

Required elements:

Research basis: Customer survey: 58% prioritize “Product images that match selected color/size.” CrazyEgg: 21.2% of product page clicks on images, with rage clicks when images don’t zoom.

Category Landing Page

Required elements:

Application Landing Page

Required elements:

Industry Landing Page

Required elements:

Regional Content Architecture

Content Inheritance

Content follows inheritance hierarchy:

Content reuse: 90-95% of content is identical across regions (per brief). Regional differences are:

• Language translation
• Currency/pricing
• Stock availability
• Shipping options
• Local certifications
• Contact information

Translation Architecture

Measurement localization:

Metadata Architecture

SEO Metadata

Every page requires:

Title tag patterns:

Structured Data

Implement schema.org markup:

Product schema required properties:

• name
• image
• description
• sku
• brand
• offers (price, availability, currency)

URL Structure

URL patterns by content type:

URL rules:

• Lowercase only
• Hyphens for spaces
• No special characters
• No trailing slashes
• Maximum 5 segments

Summary: How Information Architecture Supports User Goals

The information architecture ensures every user—Veteran, Problem Solver, or Researcher—can find products through their preferred mental model while maintaining consistent product data across all entry points.