System record

Website Transformation

Reframing a professional website as a coherent information system rather than a collection of disconnected marketing pages.

Status
Implemented
Role
Strategy, architecture, and implementation
Period
2026

Context

Website Transformation is the redesign and rebuild of woodard.pro, my personal professional website. It exists to help a first-time visitor understand how I approach problems, what I have worked on, and what evidence supports those project records.

The goal was not to create a traditional portfolio or online résumé. The project became an exercise in information architecture, editorial design, and evidence-based storytelling: organizing professional experience, project records, and writing so they form a coherent account of the work without flattening it into generic claims.

Problem

Conventional portfolio structures flatten systems work into isolated projects and generic claims. The design problem was how to show relationships among operating domains, project records, and reflective writing without presenting every project as a finished product.

Constraints

The structure needed to preserve those relationships while keeping the implementation small and inspectable. Project and writing content needed to remain portable, routes needed to be generated from structured source content, and shared presentation rules needed to work across page types and screen sizes.

The repository also establishes an evidence constraint: it contains the site implementation and its history, but no deployment configuration, uptime record, maintenance baseline, or performance study. The case study can demonstrate what was built; it cannot establish operational impact.

My role

I developed and implemented the initial Systems Atlas foundation, including its content architecture, visual language, shared layouts, and static routes. The content and evidence layers continue to evolve.

Approach

The design organizes work as territories, systems, and field notes. Content lives in portable Markdown, while a small set of components creates consistent navigation and presentation.

Key decisions

Organize the work as an atlas

Territories provide the broad map, projects document systems in different states, and field notes hold interpretation and working principles. This preserves relationships that a flat portfolio list would hide.

Separate content from presentation

Typed content collections hold project and writing records. Shared layouts and components render those records, so a structural or accessibility change can be made without rewriting each Markdown file.

Use static generation without a CMS

Astro generates the routes from tracked source files. This keeps the content portable and the implementation surface small. The tradeoff is that editorial changes follow the repository workflow rather than a browser-based publishing interface.

Make evidence limits visible

Project metadata now separates status from evidence availability. The Projects index and project records state when direct artifacts exist and when the public record is primarily documentation.

What was built

The tracked implementation includes:

  • typed collections for project and writing content;
  • a data-backed territory model;
  • shared base, page, project, and article layouts;
  • reusable navigation and content-list components;
  • generated territory, project, and field note indexes and detail routes; and
  • project status, evidence, and related-record metadata.

These are implemented source and route structures. They do not, by themselves, prove that the site is easier or less expensive to operate.

Evidence

  • Repository history. The tagged Systems Atlas foundation replaced the generic Astro starter with the current content model, layouts, components, routes, and visual system. Later commits expanded the homepage, About page, territory narrative, AMBER record, and cross-page consistency.
  • Inspectable implementation. The content schema, Markdown collections, territory data, shared components, shared layouts, and static route files are all present in this repository.
  • Generated routes. Local production builds generate the homepage, project, territory, writing, About, Resume, Contact, and Now pages. The Projects index exposes the complete project collection with status and evidence boundaries.
  • Evidence limits. This repository does not contain a deployment record, canonical production URL, uptime history, maintenance study, or performance baseline. No claim about deployment quality or operational improvement is made here.

What changed

Repository history shows a structural change from the generic Astro starter to the Systems Atlas foundation. The implemented source now separates territories, projects, and field notes; renders Markdown through shared layouts; and generates dedicated routes for each content type.

The current iteration also adds a complete Projects index, normalized project statuses, explicit evidence metadata, and direct pathways between project records and related writing. Those are observed changes in the tracked site structure, not claims about visitor behavior.

Current state

The foundation is implemented. Content, evidence, and cross-linking remain active editorial work.

What remains unmeasured

The repository does not establish visitor adoption, task completion, maintenance time, operating cost, accessibility outcomes, or deployment resilience. The long-term effect of the information architecture has not yet been measured.

What I learned

I learned to treat information architecture as an argument about meaning. For this project, the most useful structural choices were the ones that made relationships and evidence boundaries visible rather than merely accommodating a list of pages. Whether that structure improves visitor understanding still needs validation.

The project connects Personal Systems with Delivery & Program Management. Its systems framing is explored further in Everything Is a System.