Parts Town: Navigation and Information Architecture

Start with what the customer knows

Someone looking for a replacement part may know a part number, the equipment model, a manufacturer, or simply the type of part they need. Each is a useful starting point. The experience has to help them move from that clue toward an appropriate product without losing the information they have already supplied.

My engagement with Parts Town focused on navigation and information architecture: how customers enter the catalog, narrow their choices, understand where they are, and move between related experiences. I brought a systems perspective to questions that often appear first as menu, filter, or breadcrumb problems.

The central question was how to make discovery more flexible while preserving the product relationships and rules that make a result trustworthy.

Establish what the experience actually does

I combined storefront inspection with catalog analysis, stakeholder conversations, and competitive research. These sources answered different questions. A captured interface showed the behavior a customer could encounter. Catalog material helped explain the structure behind it. Conversations supplied context, constraints, and questions that needed further investigation.

Stage1, my website inspection tool, supported the interface work. Its captures provided a record of navigation, category structures, filters, and breadcrumbs that I could revisit while developing the assessment. Guided capture supported journeys that required direct interaction. Comparing stored evidence also made it possible to correct an interpretation without relying on memory or an isolated screenshot.

I kept the limits of that evidence visible. A finding from a sampled web journey did not automatically describe every customer, account state, or mobile experience. Competitive patterns were useful comparisons, with their relevance judged against the task and the catalog.

Make the underlying distinctions explicit

One important distinction was between an equipment hierarchy and a part-type vocabulary. The equipment tells you what the part serves. The part type tells you what it is. Those relationships support different ways of looking, and both need to remain available.

That led to a recommendation for shared product meaning with deliberate variation in the customer journey. A familiar label alone cannot establish whether a product fits, whether an alternative is appropriate, or which information must be collected before comparison.

Design question	Recommended direction
Where should a customer begin?	Support entry from the information they already know, including equipment, brand, identifier, or part type.
What should be shared?	Clear object identities and relationships that different surfaces can interpret consistently.
When should a journey vary?	When compatibility, product policy, or customer context changes what can reasonably be shown.
What should survive the next step?	The customer’s selected context, a clear sense of location, and a usable return path.

This connected visible interface decisions to their dependencies. A category entry point needs relevant products behind it. A filter needs meaningful attributes. A compatibility label needs evidence. Each recommendation had to account for those conditions.

Preserve the customer’s work

Navigation includes what happens after the menu. Choosing a category, a brand, or a model is useful work. The next screen should make that context understandable and let the customer revise it.

I treated catalog ancestry and return-to-results behavior as separate needs. Breadcrumbs explain where an item belongs; returning to results restores the path a person was using. Trying to make one control carry both responsibilities can obscure the experience.

The same principle applied across surfaces: shared information needs explicit behavior in each client. I developed recommendations for visible context, navigation continuity, and filters alongside the broader IA direction.

AI was part of the working method

I used Reasonbook, then called CMOS, extensively to manage the engagement’s work, decisions, and context across sessions. It provided continuity as new evidence arrived and recommendations developed. TraceLab supported the research behind the work, including background on parts procurement and field-service workflows. Stage1 supplied inspectable interface evidence.

Together, these tools supported an AI-assisted practice spanning research, analysis, and delivery. AI helped me work through material and develop drafts; I checked the claims against sources, reconciled conflicting evidence, and owned the recommendations. Stage1’s capture and analysis pipeline supplied recorded evidence for that process.

The distinction matters to my work: a generated explanation can be useful, but it still needs to survive comparison with the actual interface, the catalog, and the people responsible for the experience. These projects also informed my writing about objects, context, and the structure software needs as AI becomes part of everyday work.

Deliver a direction the team can evaluate

The deliverables covered the current state, comparative findings, a unified IA recommendation, navigation, filters, breadcrumbs, and implementation considerations. They connected the customer experience to the decisions and dependencies beneath it.

I recommended validating a bounded journey before expanding the approach: choose an entry point, apply the relevant rules, reach an appropriately scoped result, and preserve the customer’s context. That gives a team a concrete way to examine coverage, behavior, and technical implications together.

The outcome presented here is the assessment and recommendation. Production implementation and subsequent customer or commercial results are outside the claims of this case study.

This is the work I bring to complex products: turn a visible experience problem into a clear set of product, design, and technical decisions, supported by evidence and a practical next step.

Explore the tools behind the practice: Reasonbook, TraceLab, and my systems and frameworks.

Related writing: Some Things Can’t Be Filtered develops the distinction between product attributes and the relationships a catalog needs to represent.