Designing Dell's Content Ecosystem

The strategic case was clear. One observed workflow made it concrete - and became the test case for the platform direction.

A DAM Ops manager flagged that assets were hard to organize and search. Using 5 Whys, I traced the root cause to the editing workflow itself.

The operator: Content Ops - responsible for updating assets on live pages.
The task: Change an image on a page. One of the most routine content actions possible.
The friction: The WYSIWYG tool didn't support asset editing. The operator couldn't make the change in the tool they were already working in.

Every iteration created a new DAM entry. The DAM wasn't disorganized because of poor governance - it was disorganized because the workflow forced version multiplication for every minor edit.

I asked the WYSIWYG Ops team to walk me through a live asset change. The loop was confirmed: WYSIWYG → Photoshop → DAM. Three tools, every time, for a single editing action.

Confirmed after-state: The newer WYSIWYG flow brought asset editing in-tool and handled versioning and metadata natively. Tools touched per task moved from 3 to 1.

The investigation revealed patterns that repeated across the ecosystem. I extracted 3 principles from those patterns and from the failures we had made. They became the leading principles for Content and were adopted across the entire COPS program.

1. Modularity and pluggability Build once, plug anywhere across COPS. The proof: WYSIWYG inline editing built in Content was later plugged directly into the Store experience in the Buyer & Seller case study.

2. Decisions closer to the final state Decision makers shouldn't need chains of intermediary Ops teams to act. One image selection shouldn't require Content Ops, Photoshop, a DAM team, and a workflow handoff.

3. Reduce tools per job The image editing loop was the clearest example - five tools for one task. The target: fewer tools, cleaner handoffs, less duplication.

I defined access control as a platform capability - not a copy of the current org chart.

In the current state, permissions were tied to how teams were organized today - meaning any future platform would inherit the same handoffs, gaps, and ownership confusion. I defined RBAC/ABAC based on workflow responsibilities and capability ownership, independent of org structure. The model was adopted across multiple COPS lanes.

Working from the current-state ecosystem map produced by the process engineer, I built the artifacts that moved the program from analysis to decision:

• Content Lane Vision - scope, problem framing, desired outcomes. Approved by E2E leads, aligned with COPS by Sr. Lead Principal UX Architect.

• Capability specs - requirements for DAM, CMS, and WYSIWYG at platform level.

• Tool triage and phased modernization - short-, mid-, and long-term direction across 12+ paths: consolidate, retire, reposition, replace.

• Cross-lane reuse demonstration - showed how content capabilities plug into other COPS lanes, making the business case for Principle 1 concrete.

When three CMS vendors entered proof-of-concept testing, the harder problem was that stakeholders were judging options through today's workflows - risking selecting the vendor that best fit the legacy ecosystem, not the future operating model.

I designed a 4-step evaluation system. The core shift: three Yes/No questions anchored to the future operating model, enterprise scale, and manual work or risk automatically translated into vendor-independent priority weights across 100+ capabilities. Roadmap promises couldn't receive enterprise-ready ratings. Heavy customization was capped at 3 of 5. Since 55 testers covered different capability groups, I used percentage satisfaction by group - not raw averages - to keep results comparable despite uneven coverage.

Output: a single traceable readout leadership could trust to make a high-stakes decision in 5 weeks.