Embedded Files
Designing From the Work Backward
Designing From the Work Backward
Product improvements often began with something going wrong in the production workflow. People might be working around the software, discovering information too late, or dealing with a problem the system could have prevented. Sometimes the software simply didn't match the work people needed to accomplish.
As product owner for internal digital-publishing software, I translated those operational problems into requirements and worked with Product and Development to determine how to address them. I carried the resulting functionality through UAT, testing it against real production scenarios rather than treating technical completion as acceptance.
My responsibility extended through user acceptance. If functionality I owned didn't meet its operational requirements, I sent it back to Development for correction. Development determined when releases occurred; I determined whether the functionality was ready to be released.
| The starting point wasn't “What feature should we build?” It was “What is making the work harder than it needs to be?”
Making Hidden Information Visible
Making Hidden Information Visible
Sometimes the information people need already exists in the system. The problem is that they can't see it when they need to make a decision.
Designing an EPUB for Review, Not Delivery
Designing an EPUB for Review, Not Delivery
Digital-publication reviews were performed using the same black-and-white EPUBs created for eventual retail delivery. Those files showed the publication content, but not the production information reviewers and conversion operators needed to identify and correct problems efficiently.
Stories had unique internal IDs, but those IDs weren't visible in the standard EPUB. Reviewers sometimes had to infer them from the publication structure, and unusual story flows could make that inference wrong. Images presented a similar problem: retail variants could support different numbers of images, but reviewers couldn't immediately tell which image had been designated as primary.
I identified the problem and proposed a separate Review Variant EPUB designed specifically for production review.
Exposing the Information Reviewers Needed
Exposing the Information Reviewers Needed
I determined which production information could already be inferred from the EPUB structure, which information needed to be exposed explicitly, and how those callouts should appear without interfering with the content being reviewed.
The resulting Review Variant made previously hidden production information visible:
the internal story ID alongside the headline
article and child-article relationships
image page identifiers
a dashed blue border identifying the primary image
The Review Variant exposed internal story identifiers and article relationships that reviewers previously had to reconstruct from the publication structure.
______________
Image identifiers and a dashed blue border made image placement and selection visible during review.
______________
| Product principle: Make hidden system information visible when people need it to identify or correct a problem.
Carrying the Solution Through Development
Carrying the Solution Through Development
After Product approved the concept, I wrote the feature request, user stories, specifications, and acceptance criteria. I created mockups and worked through implementation options with designers and developers.
Because the Review Variant had to represent many possible EPUB configurations, acceptance testing required more than confirming that the file successfully generated. I checked whether the information displayed in the Review Variant accurately represented the underlying publication structure.
Early builds repeatedly exposed problems with image identification and display. I sent those builds back to Development for correction and continued testing until the functionality met the operational requirements.
I also provided builds to conversion and review teams for feedback before acceptance.
Product ownership continued from problem definition through release acceptance, with UAT and user feedback creating an
iterative path back to Development when requirements weren't met.
______________
Becoming Part of the Daily Workflow
Becoming Part of the Daily Workflow
Once released, the Review Variant was used daily by conversion and review teams during mid-conversion reviews, formal quality review, and correction cycles.
Putting production information directly into the review artifact eliminated some of the detective work reviewers had previously performed. They could identify stories and image roles directly instead of reconstructing that information before communicating a correction.
Based on my experience with the workflow, I estimate that the Review Variant reduced overall processing time by approximately 10% *estimated reduction in overall processing time per title. This was particularly meaningful for publications operating on turnaround times as short as 24 hours from receipt of source PDFs to final retailer delivery.
*Operational estimate rather than a formal time study.
Moving Feedback Earlier in the Workflow
Moving Feedback Earlier in the Workflow
Other product problems weren't caused by missing information. They happened because the system revealed the result after the point when someone needed to make the decision.
Previewing a Result Before It Became Rework
Previewing a Result Before It Became Rework
A text-removal feature allowed operators to remove text layers from images during publication conversion. But the initial implementation provided no way to preview the result.
Operators made the decision during conversion, but couldn't see what the resulting image would actually look like until the entire title had been processed and an EPUB generated.
If text remained embedded in the image or the removal produced an unacceptable result, the operator had to return to the conversion software, correct the setup, rebuild the publication, and review it again.
| The feature technically worked. The interaction didn't support the decision the operator had to make.
Adding the Preview Where the Decision Already Happened
Adding the Preview Where the Decision Already Happened
I advocated for moving that feedback earlier in the workflow and designed a preview interaction around an existing tool operators already used.
The interface already allowed users to locate a publication, scroll through page thumbnails, and open the full page PDF. Rather than introduce another application or separate workflow, I proposed adding a No Text option alongside the existing Page PDF action.
Selecting it generated a preview showing what would remain after the system removed the PDF text layer, allowing the operator to evaluate the result before processing the entire publication.
| Product principle: Put new capabilities into the workflow people already use when a new workflow isn't necessary.
Reconstructed example showing how the No Text preview exposed the result of text removal before full publication processing, allowing operators to identify problems earlier in the workflow.
______________
Testing the Preview Against the Final Output
Testing the Preview Against the Final Output
The preview had one critical requirement: it had to accurately predict what the EPUB packaging service would produce.
During UAT, I compared preview results with the corresponding images in generated EPUBs. When they didn't match, the feature failed acceptance.
Testing revealed that the preview and EPUB packaging services were using different text-removal logic. I sent the feature back to Development until the preview behavior accurately represented the eventual packaged output.
UAT compared the preview directly with the packaged EPUB output. A mismatch failed acceptance
and returned the feature to Development for correction and retesting.
______________
| UAT principle: Acceptance means validating the user's outcome, not simply confirming that the feature runs.
Designing for Adoption
Designing for Adoption
The preview was adopted immediately after release. Because the new capability was added to a tool operators already used, it didn't require them to learn or remember a separate workflow.
More importantly, it moved feedback closer to the original processing decision. Operators could identify unsuitable text removal before full publication processing rather than discovering it during downstream EPUB review.
Product Ownership as Operational Translation
Product Ownership as Operational Translation
Product ownership required understanding both how the software worked and how people depended on it to get their work done.
The operational problem gave me the starting point. From there, my job was to make sure the eventual solution actually addressed it, through design, development, testing, and revision.
Sometimes that meant creating a new output designed around the needs of reviewers. Other times it meant changing an interaction so people could see the consequence of a decision before it created downstream rework.
When functionality I owned didn't meet its operational requirements, I sent it back for correction. When it did, it became part of the production workflow.
| A feature wasn't finished because it worked technically. It was finished when it worked correctly for the work it was designed to support.
_____________________________________________________________________________________
Explore Another Special Project
Explore Another Special Project
Google Sites
Report abuse