Reframing Requirements to Simplify Content Architecture

At Oracle, I discovered that the custom long-form article tool we had built wasn’t necessary to meet the underlying business requirements. By separating user needs from the existing solution, I determined that nearly all required capabilities could be supported through our standard authoring ecosystem.

A custom tool designed to help customers find relevant content faster had resulted in an unscalable architecture that lacked critical functionality. A single publication could expand into hundreds, creating significant maintenance overhead that was compounded by limited bulk-management capabilities. The architecture also failed to support common use cases such as versioned products and content reuse. Usability and reliability issues drove some writers to develop content in wikis, moving it into the tool only for release, while trust had eroded to the point that teams refused to onboard new writers.

Current-State analysis

To understand how well the existing solution addressed the underlying business need, I reviewed the original requirements and evaluated how writers actually used the custom article tool.

Requirements review

Looking back through the historical project artifacts, I found several key issues:

  • Only one requirement—publication-level filtering—could not already be met through the standard authoring tool set or DITA.

  • The architecture introduced hundreds of smaller publishing units based on an unvalidated assumption that reducing publication size would improve publishing speed.

  • The project had been restarted several times with different teams, resulting in the loss of important context around the original requirements and decisions.

Writers experience

I conducted a controlled observational study with six writers to evaluate task completion, efficiency, and satisfaction with the article tool.

Writers successfully completed 81% of the tasks they attempted, but time-to-completion was quite long. Most tasks averaged around four minutes, while versioning multiple articles took substantially longer. Usability issues, knowledge gaps, and build failures contributed to both long completion times and unsuccessful tasks.

  • Most writers found the interface confusing or annoying, while the underlying workflow made publication management unnecessarily complex.

  • Knowledge gaps around publication management led writers to take unnecessary steps and follow inefficient workflows, problems amplified by the large number of publication objects required by the architecture.

  • The usability was so poor that some writers developed and reviewed their content in Confluence, then copied the final content into the article tooling before release.

  • Writers sometimes remained on established tools that took 5 to 10 times longer to complete common tasks because they trusted those processes more than the newer article-management functionality.

USER RESEARCH DATA

Solution analysis & recommendation

The current-state analysis showed that the business needed the article capabilities, but not the separate application built to deliver them.

Based on that analysis, I developed a future-state recommendation:

  • Manage long-form articles through the standard authoring tools.

  • Preserve the article feature allowing filtering content by audience, configuration, or environment.

  • Decommission the stand-alone, custom article tool.

  • Provide a migration path, training, and best practices for existing article users.

Stakeholder alignment

I used the research and requirements analysis to build the business case for changing direction, then partnered with product management and engineering to align on a simpler future state.

I secured alignment to move article functionality into the standard authoring ecosystem rather than continue investing in a separate solution. The analysis also prompted a separate effort to address publishing performance, resulting in significantly faster publishing.

Results

The result wasn't a specification for a better standalone tool; it was evidence that Oracle didn't need the standalone tool at all.

  • Changed product direction — I secured alignment on a future-state strategy to move article functionality into the standard authoring ecosystem rather than continue investing in a separate solution. This preserved the capabilities writers needed while eliminating the need to develop and maintain another specialized tool.

  • Simplified architecture and workflows — The proposed future state eliminated much of the publication-management overhead created by the existing architecture and supported common use cases it couldn't accommodate, including versioned products and content reuse.

  • Improved publishing performance — The analysis also separated publishing performance from the architecture problem, prompting a parallel effort to improve publishing speed that resulted in significantly faster publishing.

Projected business impact

Based on user research and workflow analysis, the simplified future state was projected to:

  • Reduce authoring and publication-management time by ~50%.

  • Reduce onboarding time by ~60%.

  • Reduce development and maintenance costs by ~10%.