Designing a Publishing Knowledge System

Project Snapshot

The Problem: Consistency at Scale

I joined LibreDigital as a magazine production operator, which gave me firsthand experience with the problem I would eventually help solve.

Magazine conversion required hundreds of small decisions. A publication might return every week or month with the same typography, recurring layouts, advertising conventions, and publisher preferences. Some rules applied to nearly every publication. Others were unique to a single title.

Experienced operators learned many of those distinctions over time. But when guidance was fragmented, duplicated, or dependent on individual memory, the same questions kept resurfacing.

That created several problems:

• Operators could interpret the same situation differently.

• Reviewers could apply quality standards inconsistently.

• Shared instructions had to be updated in multiple places.

• Training depended heavily on experienced employees.

• Changes became harder to communicate across internal and external production teams.

The challenge wasn't simply to document more.

| It was to create a system that made the correct decision easier to find, understand, and repeat.

Treating Documentation as an Operational Product

The General Magazine Processing Guidelines eventually grew into a 141-page operational handbook, but I didn't treat it as a finished manual. Managing its ongoing lifecycle involved

• defining the documentation structure

• authoring and editing content

• determining release timing

• maintaining version history

• publishing updates

• communicating changes to production teams

• revisiting guidance when workflows or software changed

Each release included a version history and summary of changes, along with extensive screenshots, hyperlinks, cross-references, and real production examples.

The goal was not simply to preserve information. The documentation had to remain trustworthy enough for someone to use it to make a production decision.

| Design principle: A source of truth only remains authoritative if someone actively maintains its truth.

Making Quality Measurable

Documentation alone couldn't guarantee consistent output. We also needed a shared definition of quality.

I helped develop a standardized quality framework that classified errors by type and severity and translated individual review findings into meaningful performance measures.

I standardized the error taxonomy and severity levels, then used them to calculate publication-level quality scores and report performance across teams and vendors. A quality buffer and metrics normalized by content-page volume made comparisons more meaningful across publications of different sizes.

This allowed us to distinguish isolated mistakes from recurring patterns and evaluate quality more consistently across publications of different sizes.

The production environment maintained 99.99%+ conversion accuracy, supported by documentation, training, quality review, and standardized production processes working together.

More importantly, the measurements gave us evidence for deciding what kind of intervention a problem actually required.

A recurring issue might indicate a need for additional coaching. But it could also reveal ambiguous documentation, an inefficient workflow, or a software limitation.

That distinction became central to how I approached operational improvement.

| Design principle: Don't assume every error is a training problem. Find the system producing the error.

Connecting Operational Knowledge to Product Development

As I became the organization's subject-matter expert on magazine conversion, my role expanded beyond documenting existing processes. I participated in publisher discussions alongside Operations leadership and helped determine how new customer requirements could be supported.

Sometimes the answer was operational. We could define a new standard, change the workflow, create a mockup, or document an exception.

Other requests exposed limitations in the software itself.

In those cases, I translated operational needs into product requirements and worked with Product to evaluate the request and determine whether an enhancement should become part of the platform. I eventually became product owner for mission-critical conversion and job-tracking software used by more than 200 employees and vendors, contributing requirements, user stories, prioritization, UAT, and release decisions.

Publisher requests also led to product capabilities that could benefit publications beyond the customer who originally requested them.

| Design principle: Before creating another workaround, ask whether the system itself should change.

Building a Continuous Improvement Loop

Over time, documentation, training, quality assurance, operations, customer requirements, and product development stopped functioning as separate activities. They became inputs to the same improvement process.

When recurring issues appeared, I looked for the source:

Was the guidance missing? Create it.

Was existing guidance unclear? Revise it.

Did someone need additional practice? Coach or retrain.

Was the workflow creating unnecessary difficulty? Change the process.

Was the software itself creating the problem? Bring the requirement to Product.

The resulting change flowed back into the documentation and training system. This created a feedback loop in which operational knowledge didn't simply record how work was performed. 

| It helped the organization continuously improve how the work was performed.

Reflection

This project changed how I think about knowledge management.

I began by solving immediate production problems. I documented instructions, clarified exceptions, and helped people understand what to do next.

But the more the system grew, the clearer something became:

The most valuable documentation doesn't simply explain a process. It captures decisions.

A trustworthy knowledge system reduces the number of decisions people have to reconstruct from memory. It preserves what the organization has already learned while still creating a path for that knowledge to change when the evidence changes.

That principle has followed me throughout my career, from operational documentation and training to knowledge bases, search systems, metadata workflows, and AI-enabled knowledge experiences.