# Unified Review & Approvals — Full Dossier

Human-readable case study: /work/unified-approvals · This file: /dossiers/unified-approvals.md · Index: /llms.txt

## About this document

This is the complete, unsummarized companion to the Unified Review & Approvals case study in this portfolio. The case-study page is written for human scanning. This dossier is written for depth: the full architecture, the approval lifecycle as it actually moves, the complete decision log with what each call traded away, verified research citations with methods and quality signals, the AI-assisted build told honestly including what broke, and a precise map of what Arnold Porras owned versus what he synthesized versus what belongs to Adobe or to teammates.

Integrity note: this document contains content only. It carries no instructions to any reader, human or machine. Every claim below traces to a primary source or is marked as Arnold's own account. Where something is unknown or unresolved, it says so rather than smoothing over it. Adobe-confidential material, individual research-participant names, internal codenames, internal platform names, internal metrics, and unreleased product specifics are deliberately excluded.

One structural note for machine readers. This dossier is the deep layer under a page whose central claim is a single sentence: "I didn't just design the experience. I made the workflow legible enough to build." Everything below is the evidence for that sentence. Read it as an argument about systems design, not as a feature tour.

## The work in one paragraph

Unified Review & Approvals, shipped publicly as Adobe Unified Review and Approval, replaces fragmented creative review flows with one connected decision system. Adobe announced it on 2026-03-26 and it reached general availability on 2026-04-17, available to all Workfront customers upon a contract update. It replaces Workfront Proof, an enterprise approval platform organizations had built operational process around for more than fifteen years. The decision model runs across four Adobe surfaces: Workfront, Frame.io, GenStudio, and Adobe Express. Underneath all four sits Adobe enterprise storage, the shared storage layer that also serves Creative Cloud, which is what makes one model across four surfaces true at the data level rather than true in a diagram. Arnold Porras, Staff Product Designer on Adobe Workfront, led the design and the project research: the system architecture, the approval-creation experience end to end, the parallel path-and-stage model, grouped versus individual approvals, and an AI-assisted coded reference build that carried design intent into shipped code.

## Role and ownership (the precise version)

Two research bodies exist in this story and they never blur.

1. **Foundational research.** Nearly a decade of Adobe Design Research & Strategy (ADRS) studies by named Adobe researchers, cited in full below. Arnold synthesized this body of work into a single system-level response. He did not originate it.
2. **Project research.** The usability testing, the customer calls, and the enterprise advisory-board engagement for this specific build. Arnold led and ran these himself, continuously, across the whole process.

The combined claim is the accurate one, and it is stronger than either half alone: he synthesized a decade of foundational research he did not run, and ran the usability testing and customer contact that shaped this build. The public case-study page carries both halves as of 2026-08-07.

**What Arnold owned end to end:** the approval-creation process, meaning ad hoc and template-based creation, stage routing, participant organization, and who sees what and when; the one-model-two-exposure-modes architecture; the parallel path-and-stage model with its dependency rules and circular-dependency validation; grouped (bulk) versus individual approvals; the Spectrum 2 coded reference build and the AI-oriented documentation written around it.

**What he led:** design and research for the initiative; customer engagement with Workfront champions and the enterprise advisory board; the UX seat in the AI-assisted build room, working the spec-development cycles closely with engineering and product management from day one.

**What he partnered on, cross-org:** Frame.io designers, engineers, and product managers; Workfront product managers and researchers; engineering on the spec-driven build.

**What is not his, and is credited accordingly:** the foundational ADRS studies, credited to their named researchers below; the structured context repository that kept the build agent oriented, which engineering built and maintained; Adobe's published business outcomes, which belong to Adobe and to its named customers.

The compact version of the ownership claim: research lead at the project level, synthesizer of the foundational body, design owner of the system and of the approval-creation experience end to end, build partner through the spec cycles, and customer-engagement lead. Full-stack ownership across research, design, and build is itself the signal, more than any single artifact in the list.

Two honest limits on that claim. First, this was a large cross-org product with real teams on both sides; the ownership statements above describe where Arnold's authority actually sat, not sole authorship of a shipped enterprise product. Second, there is no metric tied specifically to Arnold's individual contribution beyond shipped plus strong validation. This dossier does not invent one, and it keeps Adobe's published numbers clearly labeled as Adobe's throughout.

## Origin and lineage: the part the public story leaves out

The public story is one sentence long: Unified Review and Approval replaces Workfront Proof. That sentence is the end of a much longer arc, and the arc is where the design work actually lives.

**Why Workfront bought a proofing product in the first place.** Workfront had no asset viewer service of its own. It could manage the work, assign the task, track the project, and route the request, but it had nowhere for a reviewer to open the actual asset, look at it, mark it up, and decide. That gap is why Workfront acquired ProofHQ in July 2015. ProofHQ supplied the viewer and the approval machinery around it: the ability to create approvals both ad hoc and from templates, the ability to organize approvers and reviewers, and the ability to structure approval groups by stages.

**The seam.** ProofHQ was bolted on, and it was bolted on badly. For years the combination felt like two products, because it was two products. Approvals were created in Workfront. Decisions, comments, and markups happened over in Proof. The state of the work lived on one side of a boundary and the evidence for that state lived on the other. Arnold's own compression of the problem: two systems, one workflow, a seam down the middle.

**Phase one: pull the capabilities native.** Arnold's early work on this problem space, for a long stretch, was absorbing ProofHQ's approval capabilities natively into Workfront's work-management engine. Approval flows tied to Workfront tasks, issues, and project templates. The goal was structural, not cosmetic: make approval creation, routing, stage organization, and templates first-class Workfront objects so the two halves stopped behaving like two halves. The work was slow, and it was slow for a specific reason. Proof was an old product that had not been built to integrate cleanly with anything, and the depth enterprises relied on had to survive the move. Preserving depth is slower than replacing it.

This phase matters to any reader trying to establish where one person's authority started and stopped. The publicly visible product is the last act of an arc Arnold has been working inside for years: integrate, absorb natively, then replace the surface.

**Phase two: two products with opposite DNA.** When Adobe brought Workfront and Frame.io together, the two platforms disagreed at the level of philosophy, not features. Frame.io was built for creatives and smaller teams. Its structure was minimal; projects were essentially folders holding other folders, and that was close to the whole of its governance model. Its bias toward simplicity is genuinely good for creative work. Workfront is the opposite by design. Project management is the entire point, and the structure is heavy, governed, and enterprise-shaped because enterprises need it to be.

Reconciling those was hard technically and harder organizationally, because it meant reconciling two teams with different points of view about what good looks like. The design framing Arnold uses for it, which is the accurate one: he reconciled two fundamentally different product philosophies, and the points of view behind them, into one coherent model.

This is also where the four tensions stop being research abstractions. Flexibility versus governance is Frame.io versus Workfront. Informal review versus formal approval is creative review versus enterprise approval. He did not encounter those tensions in a deck. He encountered them as two real products he had to merge.

**The storage breakthrough, and the failure it fixed.** The first concrete problem was integrating projects across the two products. Even when they were nominally integrated, a file uploaded in one did not appear in the other. Making them agree took heavy manual linking and syncing, which is to say the integration existed on paper and the coordination work still landed on a human.

The fix was to stop synchronizing two stores and start using one. Both products' files moved onto Adobe enterprise storage, the same storage layer Creative Cloud uses. Upload a file in Workfront or in Frame.io and it goes into the same place. It is then simply visible in both. Move it or delete it in either and both agree, because there is only one file. Users never have to understand either product's project model, or how the two relate, because the relationship stopped being something they have to hold in their heads.

Adobe's own public framing of this is the sharpest available: assets live in one place, and it is "the difference between systems built around assets versus assets duplicated across systems."

## Timeline and status

- ProofHQ acquired by Workfront in July 2015. Adobe acquired Workfront in 2020 and Frame.io in 2021. Frame.io is a separate acquisition and a separate product; it is not a renamed ProofHQ. It replaced Proof as the viewing and decision surface.
- Arnold's phase one, absorbing Proof's capabilities natively into Workfront, ran for years before the public story starts.
- Phase two reconciled Workfront and Frame.io into one approval system on shared storage.
- Adobe announced Unified Review and Approval on 2026-03-26, in a bylined post by Jason Barron, Group Product Manager.
- General availability followed on 2026-04-17. Adobe's Experience League community announcement states it plainly: "This integration is available now for all Workfront customers upon a contract update." The case-study page states this as shipped April 2026, which is the GA month.

Both dates are true and they are not the same event. March 26 is the announcement. April 17 is general availability, with the contract-update qualifier that a precise reader will want.

Status: shipped and evolving. Parallel approvals, grouped approvals, the path-and-stage model, and the template structures described below are released. One precision note carried from Adobe's own documentation: Experience League records that integrations supporting the Frame.io viewer experience were in development for Adobe Express and GenStudio for Performance Marketing, while Adobe's Workfront product page describes proofing capability inside both. Adobe's marketing page and Adobe's documentation are not fully reconciled with each other on how complete two of the four surfaces are. This dossier states the disagreement rather than picking the flattering side.

On the fifteen-year span: enterprises had built process on the Proof platform for more than fifteen years, which includes its years before the 2015 acquisition. The span is Arnold's estimate of enterprise reliance rather than a figure published anywhere, and it is stated here as an estimate.

## The problem

In 2018, Adobe researchers sat with an enterprise design team to watch creative work move through review. Designers exported files, converted them to PDFs, sent them to project managers, and the project managers gathered feedback somewhere else and typed decisions back into Workfront by hand.

Seven years later, different companies, the same loop. Individual tools had improved at their own piece of the job. Nobody had fixed what happened between them.

The tell was not the loop. The tell was what people built on the side. In that 2018 study, not one designer noticed or understood the workflow's milestone controls when asked about them directly. The same designers were manually screenshotting every deliverable they shipped, saving them as PDFs, and maintaining personal tracking systems so they could prove what got decided and when.

That is not a training problem. A shadow system is what a team builds when the real system cannot be trusted to hold the record. The need was real. The product's expression of it failed. So teams built accountability outside the product, which is the definition of a trust-architecture failure rather than a workflow one.

**Sourcing note, stated rather than buried.** The 2018 study, credited to Wallace in Arnold's narrative, and a second 2018 Cloud Collaboration Files study referenced in the same narrative, both sit outside this dossier's verified citation backbone. That backbone runs 2021 to 2026 and is listed in full below. The 2018 material is carried here as Arnold's own account, accurate as he tells it and not independently verified against a primary document. It matters because it is the early end of the "nearly a decade" framing and the anchor of the generational-failure claim. Readers weighing the evidence should weigh it as testimony, not as a cited study. The customer name from that 2018 site is deliberately withheld; the finding is unflattering to that customer's tooling and naming them adds nothing.

The export-to-PDF loop itself, though, is verified at both ends of the arc. The 2025 enterprise creative-workflow study records the same behavior in the same words from participants who had never met the 2018 team: if the new flow feels confusing, they revert to exporting a PDF. Two independent observations, seven years apart, of one failure.

## The constraint: match the moat before improving it

This was not a greenfield redesign. It replaced a system enterprises had run on for more than fifteen years, and nobody had to love that system for the replacement to be dangerous. They trusted its depth, and the depth was specific:

- Sequential and parallel workflow routing
- Decision-completion modes: all approvers, any approver, or specific approvers
- Role-based participation, with six distinct in-stage review roles
- Private review groups and workflow locks
- Guest reviewers
- Detailed audit trails across every decision
- Template-driven workflows

Those were not features in the marketing sense. They were the foundation of enterprise trust. Compliance processes referenced them. Approval templates governed large-scale operations. Audit trails were how accountability got proven to somebody outside the team.

Rip that out and you do not ship a better product. You break the customer. So the order of operations was the whole constraint: match the depth first, exactly, and only then fix what had been broken for years. Preserve the moat, then fix it.

The cost of that order was speed. The native integration was slow precisely because the depth had to survive rather than be discarded, and a clean-slate redesign would have been faster in every quarter that mattered to a roadmap. It was refused, deliberately.

**An honest attribution note.** Whether the moat constraint originated with Arnold or was handed to him as a given is not settled in the underlying material. What is documented is that he designed inside it, argued for its ordering, and carried the capability list forward into the shipped architecture. This dossier does not claim authorship of the constraint itself.

## The four tensions

The published research surfaced these repeatedly across a decade. Arnold also lived them directly, as two real products he had to merge.

1. **Creative control versus operational visibility.** Designers needed control over unfinished work. Operations needed visibility into whether anything was moving. Both are legitimate. Neither can simply win.
2. **Informal review versus formal approval.** Creative teams work iteratively, fast, and undocumented on purpose, because documentation slows the loop and the loop is the work. Enterprise governance requires the opposite: structure, documentation, and a record that survives the people who made it.
3. **Flexibility versus governance.** Templates had to be powerful enough for compliance and light enough that people would actually use them. This one bit hardest, because the same feature had to deliver both at once rather than trading between them.
4. **Tool fragmentation versus system continuity.** Customers had stitched together their own systems out of whatever worked. The replacement had to remove the stitching without breaking what the stitching was holding together.

Same attribution note as above: whether Arnold named these four or inherited them from the research is not settled in the underlying material. At a systems level the framing is the contribution, so the question is worth flagging rather than quietly resolving in his favor. What is documented is that he negotiated all four in a real integration between two products with opposite defaults.

## The three insights

**Visibility is sovereign.** Creatives are flexible about where files live and absolute about who sees unfinished work. In the June 2025 enterprise study, all seven participants raised serious concern about work-in-progress visibility to non-designers, and said they would work outside the system if work in progress is not protected. The stakes were clearest on video: a rough cut shown too early changes how stakeholders respond for the rest of the project. The issue was never storage. It was control. In Unified Approvals, visibility became an intentional workflow decision rather than a default system behavior. The compressed principle: flexible on storage, sovereign on visibility.

**Approval is not one workflow.** Formal approver counts in the research ran from 1 to 22 stakeholders, spanning legal, compliance, executive, marketing, and regional groups, and in practice were never just one; the floor was typically a client plus a creative director. The genuinely single-approver case is the informal, lightweight review, which is a different mode rather than the small end of the same one. That distinction is the insight. The informal and formal split documented in 2021, a three-tier concept model in 2022, and the 2025 studies independently converge on the same shape across different researchers and different years. The system answers with progressive complexity: one model, scaled exposure.

**Templates as authority architecture.** Proof supported six in-stage review roles, three decision-completion models, sequential and parallel routing, private review groups, workflow locks, guest reviewers, and detailed audit trails, and enterprises had built process on all of it. A template is not a convenience feature in that world. It is how a brand stays consistent across hundreds of people who never meet, and how compliance gets enforced without a human standing at every gate. The 2025 brand-validation synthesis says the same thing from the other end: locked templates are how brand is governed today, not a legacy pattern waiting to be modernized away. Templates carried that authority forward while becoming usable beyond administrators.

## The architecture

### Engine versus surface

The approval engine lives in Workfront. Approvals are created, routed, structured, and tracked there, and a decision is a work-state event: it changes the state of the work, not just the state of a comment thread.

The viewing and decision surface is where the asset makes sense to look at. Frame.io is the primary one: stakeholders see the asset, comment, mark up, and register decisions, which sync back to the engine. Frame.io is a separate Adobe acquisition from 2021 that replaced Proof in that role; it is not a renamed ProofHQ, and describing it that way in a public document would be a false claim to anyone who knows the history.

The one-line version, which is sharper than either product's public framing: Frame.io shows the asset and captures the markup; Workfront runs the approval. Frame.io's public description says it takes over as the review surface, which is true for viewing and incomplete for everything else. The engine is Workfront.

### Four surfaces, one storage layer, and what happens after the decision

The decision model expresses itself across four Adobe surfaces, each carrying a different user context:

| Surface | Role in the system | Why the context differs |
|---|---|---|
| Workfront | Structured governance and the approval engine | Project managers, marketing operations, and regulated industries depend on it for auditable approval structure |
| Frame.io | Frame-accurate review | Video and motion, tied to timecodes and version stacks, with high stakes about what gets seen and when |
| GenStudio | AI content at scale | Approval has to keep pace with generated variants without losing accountability for any of them |
| Adobe Express | Lightweight approval | A decision that should feel like a few taps, not a workflow configuration |

One underlying decision model. Four surfaces of expression.

**Creative Cloud is not a fifth surface.** It is the shared storage layer these surfaces sit on. Adobe's own public copy places it exactly there: assets are "built on Adobe enterprise storage, a common storage layer that connects Workfront, Frame.io, and Creative Cloud." Adobe's product page describes review and approval capability inside Workfront, Frame.io, GenStudio, and Express, and describes Creative Cloud only in that shared-storage sentence. The design work behind this system treated it the same way throughout: four surfaces, one shared store. Calling storage a review surface would inflate the scope claim and weaken a true one, so this dossier does not.

**The flow does not stop at the decision.** Adobe's Experience League documentation describes the unified flow continuing past approval: approved assets transfer to Adobe Experience Manager for final storage and distribution. Adobe's own lifecycle diagram runs plan work, add assets, kick off review, comment, decide, and send to AEM, with the whole sequence sitting on enterprise storage that stays in sync. That last leg matters to the systems argument, because it is what makes an approval a real gate. The decision is not the end of the record. It is the thing that releases the asset into distribution.

### The storage keystone

Both products' files live on Adobe enterprise storage. Upload a file in Workfront or Frame.io and it is the same file in both. Move or delete it in either and both agree.

This is the architectural keystone, not a plumbing detail, for three reasons.

First, it makes one model across multiple surfaces true at the data level instead of true in a diagram. Without a shared store, "one model" is two models plus a sync job, and sync jobs fail in ways that land on users as coordination work.

Second, it removes the export-download shuffle entirely rather than easing it. There is nothing left to shuffle. The loop documented in 2018 and again in 2025 does not get faster; it stops having anything to do.

Third, it operationalizes the strongest research principle in the whole evidence base. Users are flexible about storage and sovereign about visibility, so the design hides the storage layer completely and puts all the intention into who sees what and when. The thing users do not care about became invisible. The thing they care about became the designed surface.

### One model, two exposure modes

There is one data model. The difference between Basic and Advanced approvals is only how much workflow structure the interface exposes.

**Basic** hides paths and stages entirely. Add participants, add an optional message, confirm the documents, send. It is designed to feel like "send this for approval," not "configure a workflow." Under the hood it is still one path with one stage. Basic templates are single-stage with no paths, which is what keeps the mode coherent rather than merely simplified: the model is not being cheated, it is being under-exposed on purpose.

**Advanced** exposes multiple paths, multiple stages per path, sequential or parallel stage progression, dependency rules, and template-based workflows built manually or started from a visual template library.

This is the design expression of "approval is not one workflow." The same model serves a lightweight Express review and a 22-stakeholder Workfront workflow, and neither one is a degraded version of the other.

### The data model

An approval contains one or more paths. Each path contains one or more stages. Each stage contains participants, who are approvers or reviewers. The approval references a set of documents.

Two constraints do real work here:

- **Documents are project-level resources.** An approval references a subset of the documents on a project. Approval scope is therefore a selection problem, not an ownership problem, which is what makes the bulk-versus-individual choice below meaningful rather than cosmetic.
- **A document belongs to only one approval at a time.** This is what keeps a decision unambiguous. Two open approvals on the same asset would mean two live answers to the same question, and the record would have no way to say which one governs.

### Paths, stages, and dependencies

**Paths run in parallel.** Different teams review the same documents through their own track, independently and at the same time. A Creative path and a Legal path proceed simultaneously on the same assets, each with its own stages and its own timeline.

**Stages within a path run in sequence or in parallel.** Inside a path, stages can chain, each starting when the prior one completes, or run at once, depending on how the flow is configured.

**Paths and stages can depend on each other to start or to finish.** This is the powerful part and the dangerous part. Dependencies let a workflow express real organizational sequencing, and they also let a user build a deadlock: Path 1 waiting on Path 5 to start while Path 5 waits on Path 1, or two stages each waiting on the other to finish. Arnold designed validation rules, surfaced in the setup interface, that prevent circular dependencies from being created at all. The design position underneath that: a system that lets you build a deadlock and then explains the deadlock afterward has already failed. Block it at authoring time.

The accurate one-liner for the whole model: parallel paths, stages that run in sequence or in parallel, and dependency rules that block circular dependencies.

**Why stages exist at all** is a visibility argument, not a sequencing one. Stages stage who sees what and when, and they prevent cross-contamination of comments and decisions across groups. Not everyone needs to see every group's feedback. Legal reading creative's rough critique changes what legal says. This is where Proof's private and locked stages carry forward, and where "visibility is sovereign" becomes a structural property of the model rather than a permission checkbox bolted on later.

### Grouped versus individual approvals

When multiple documents are selected, the user chooses the execution model.

**Bulk:** all documents move through one approval instance and participants review them together. The group takes a name, which becomes the approval title.

**Individual:** each document gets its own approval instance, reusing the same workflow definition. A Creative to Brand to Legal flow applied independently to each file.

This is the direct design answer to high-volume enterprise teams running tens of concurrent approvals at once, and for the heaviest teams the working figure is 50 to 60 at a time. The primary research document supports the conservative phrasing, so that is what this dossier leads with, with the sharper number noted rather than dropped.

The choice matters because the two models produce different records. Bulk produces one decision about a set. Individual produces a decision per asset. A team that picks the wrong one discovers it later, at audit time, which is the worst possible time.

### Templates and the two entry points

Approval templates package predefined workflows, meaning paths, stages, and participants, for reuse. In Basic they appear as a simple dropdown and are single-stage with no paths. In Advanced, workflows are built manually or started from advanced templates in a visual library.

Approval creation has exactly two entry points: **ad hoc**, building from scratch, and **template-based**, starting from a predefined structure. Both were inherited conceptually from ProofHQ and brought native into Workfront. That single fact ties the whole arc together. The origin story, the moat argument, and the shipped architecture are the same story: the capabilities enterprises trusted were not reimagined, they were carried across and then made usable.

What changed is who can wield them. Template power moved out of the administrator's hands and toward the team, without thinning the depth enterprise customers had built process on.

### The decision model

Two binding decisions at launch: **Approve** and **Needs Work**. Reviewers comment; approvers make the binding decision; decisions sync across Workfront and Frame.io.

Some enterprise customers wanted custom decision types. The launch call was to limit the set for clarity and consistency across both surfaces, and to build the model so more can be absorbed later without breaking it. That tradeoff is D1 in the decision log below.

## How the work moves

The data model describes what exists. This describes what happens, which is the part a reader needs to simulate the system rather than take its structure on faith. Five steps, each with a persona who owns it, and one engine underneath all of them.

| Step | Owner | What happens, and where |
|---|---|---|
| Request | Petra, project manager | Assets, reviewers, due date, template. The approval is created in Workfront. |
| My Approvals | Rayna, reviewer and approver | Her queue in Workfront Home, filtered to her, pending only. |
| Review | Rayna | The Frame.io viewer for a single asset, or a campaign view for a group. |
| Decide | Rayna, or whoever holds approver role in that stage | Approved or Needs Work. The decision syncs back to the engine. |
| Track | Petra | Stage, path, blockers, readiness. |

Beneath all five sits the engine: Workfront, holding paths, stages, participants, decisions, and status. Every step connects down into it, because the engine powers every surface. That is the difference between a system and a set of integrations. The surfaces are where people are; the state lives in one place.

**The loop.** A Needs Work decision returns to Request by way of Desi, the designer, who applies the feedback and uploads a new version. The loop is not an error path. It is the normal case, and version handling has to make the new upload obviously the new upload without orphaning the decision history attached to the old one.

The summary line: Home gives speed, the review surface gives context, the engine holds the state, and once approved, the work ships.

### Workfront Home as the designed answer

The bulk-approvals research finding was blunt: high-volume teams need a single searchable approval queue, not a small home widget. An operations lead in that testing said it directly: "Trying to navigate to that one that you want — having the ability to search the approvals in there would be a really helpful add-on."

My Approvals in Workfront Home is the answer to that finding. A queue, filtered to the individual reviewer, showing pending items only, searchable.

The reason it belongs in Home rather than deeper in the product is a persona fact rather than an information-architecture preference. Rayna, the reviewer and approver, is not in Workfront daily. She is pulled in when something needs a decision. Any design that assumes she will navigate to a workflow area to find her work assumes she has a mental model of the workflow area, and she does not, because she is not there enough to build one. Putting her queue where she lands is the difference between an approval she completes and an approval that stalls in an inbox.

Senders needed the mirror of it: group-level review tracking after a batch is submitted, not just per-asset status. That is the Track step, and it is why status legibility is part of the approval system rather than a reporting feature next to it.

## What we improved

The before-and-after pairs, stated plainly. Each left side is what the previous system actually did.

| Before | After |
|---|---|
| Two systems | One system. The boundary between Workfront and Proof is gone. |
| Powerful templates | Usable templates. Admin-only power shifted toward the broader team without losing depth. |
| Visibility exists | Visibility is actionable. Fragmented status data became an observable system. |
| Versioning exists | Versioning aligns with decisions. Asset versions track workflow progression. |
| Manual coordination | System orchestration. Less reliance on humans to move work forward. |
| Approval lived outside the creative tools | The same decision model across Frame.io, GenStudio, and Express. |

The last pair is the clearest statement of scope in the whole project. Approval did not get a better home. It stopped needing one, because it now exists wherever the work does.

## Decisions and tradeoffs (the judgment log)

Each entry states the tension, the call, the alternative that was rejected, the cost accepted, and the outcome. A decision log without rejected alternatives is a feature list written in the past tense; the costs are what make it judgment.

### D1. The decision set: shippable clarity versus enterprise configurability

**Tension.** Some enterprise customers wanted custom decision types. Frame.io's product bias is simplicity, which is genuinely good for creative work. Enterprise governance wants nuance. Both surfaces had to show the same decision to the same user on the same asset.

**Call.** Launch with two binding decisions, Approve and Needs Work, and build the model so more can be absorbed later without breaking it.

**Rejected.** A configurable decision-type system at launch. Configurability would have forked the decision vocabulary across two surfaces with opposite governance postures, and a decision that means one thing in one surface and something adjacent in the other is not one decision model. It is two, with a translation layer, and translation layers are where audit trails go to die.

**Cost.** Deferred configurability that large customers explicitly asked for, knowingly, at the moment they were being asked to trust a replacement.

**Outcome.** One clean, consistent decision model across surfaces, with a path to add nuance later. The judgment on display is choosing shippable clarity over configurability on purpose, and protecting the model's future while accepting a real customer complaint in the present.

### D2. Parallel approvals against a sequential-only roadmap

**Tension.** Workfront historically supported sequential stages only: one group at a time, each waiting on the last. Leadership was not prioritizing parallel approvals. Arnold's continuous customer contact said enterprises needed multiple groups reviewing the same assets simultaneously or they would not adopt.

**Call.** He raised it directly in an enterprise advisory-board session and asked the room how important parallel approvals were.

**Rejected.** Building the sequential-only roadmap as scoped and letting adoption data reveal the gap after launch. That path was safer for him personally and worse for the product, because the discovery would have arrived after enterprises had already decided.

**Cost.** Personal risk in going against the prevailing leadership view, and spending his own credibility on a contested bet in a room where being wrong is expensive.

**Outcome.** More than half the board said it was critical and that they would not adopt without it. Parallel approvals went on the roadmap. Arnold designed the path-and-stage structure, and it was built and released.

**The detail that carries the whole story:** the result was not a surprise to Arnold. He had been hearing it in the field for months. It was a surprise to Workfront leadership. That asymmetry is the actual evidence. It is not that he guessed right; it is that his customer contact was ahead of the roadmap, and the board simply confirmed in one room what he already knew from many. The full arc: heard the need, championed it past a roadmap assumption, validated it live, designed it, and led the build.

Advisory-board validation is reported in aggregate by design. Member companies are public Adobe partners and may be named as the caliber of partner this work involved, but private session stances are never attributed to a named member. Advisory boards run on candor because the room is private, and publishing a member's position would trade the mechanism for the anecdote.

### D3. Reconciling two product philosophies

**Tension.** Frame.io flexibility versus Workfront governance, and two organizations with different points of view about which one is the virtue.

**Call.** One underlying model with two exposure modes, unified underneath by shared enterprise storage so a file is the same file across both surfaces.

**Rejected.** Two models with a synchronization contract between them, which is what most integrations of two acquired products actually are. It would have shipped sooner and would have re-created the exact seam this project existed to remove.

**Cost.** Neither pure simplicity nor pure governance. A more complex model that has to serve both, plus the long organizational effort of cross-org reconciliation.

**Outcome.** A low-governance viewer surface can serve a high-governance approval engine as one system. One model, four surfaces, made real at the data level rather than asserted in a diagram. The design-framed statement of the work, which is also the honest one: he reconciled two fundamentally different product philosophies, and the points of view behind them, into one coherent model.

### D4. Preserve the moat, then fix it

**Tension.** Proof's depth was disliked as an interface and trusted as a foundation. Modernize without breaking that trust.

**Call.** Carry the capabilities natively into Workfront first, preserving depth, then move the surface.

**Rejected.** A clean-slate redesign. It was the faster path, the more attractive portfolio story, and the one that breaks compliance processes built on capabilities the redesign decided were legacy.

**Cost.** Speed. The native integration was slow precisely because depth was preserved rather than discarded, and slow is expensive when the competitive story wants a launch.

**Outcome.** Modernization without breaking enterprise trust. The judgment is holding two truths at once, preserve and fix, and refusing to trade enterprise trust for a clean-slate redesign.

### D5. The in-room build ruling

**Tension.** During the AI-assisted build, the agent needed a model-level answer fast: are approval templates a Basic feature or an Advanced feature? It could not proceed without one, and a wrong answer would be built correctly and quickly.

**Call.** Arnold ruled live, in his own words: "Are approval templates a Basic thing or an Advanced thing? Neither. Templates are workflow structures. Basic and Advanced are UI exposure levels over the same model."

**Rejected.** The easier-to-build framing, templates as a mode-specific feature. It would have compiled, passed review, and quietly split the data model into two.

**Cost.** A harder implementation in the moment.

**Outcome.** The data model stayed coherent under build pressure and held from concept to shipped code. This is the smallest decision in the log and one of the most consequential, because it is the one that proves the model survived contact with an agent building fast.

### D6. The AI-build judgment calls

**Tension.** Move fast with an AI agent, or keep quality and the right design system. In practice you find out which one you chose after the fact.

**Calls and lessons.** Told to reuse existing repository components, the agent took the path of least resistance and pulled components built on an older design system. Version one was messy until it was caught. The missing instruction that mattered was specific: build new components on the current design system, do not inherit old ones from the repository. Separately, automated checks passed while the experience was not ready, with missing edge cases, absent reset behavior, and unhandled disabled states.

**Cost.** A messy first version, and the comfort of trusting green tests.

**Outcome.** Reusable guardrail principles: explicit component instructions, design intent in shared AI context, and guardrails written alongside every spec. The strongest formulation of the principle is the actionable one, and it is the half most people drop: what must not be built is as important as what should, because the agent fills silence on its own.

### D7. The vision scope call

**Tension.** Solve the Workfront-plus-Frame.io inconsistency narrowly, or address the ecosystem-wide one.

**Call.** Co-drive a UX-led point of view that scaled the problem to a composable, AI-first approval layer across Adobe surfaces. That work is Project Tempo, described below.

**Rejected.** The bounded version, which was defensible, deliverable, and would have left the same inconsistency intact three products over.

**Cost.** A bounded, easier story traded for an ambitious cross-org one that does not have a ship date attached to it.

**Outcome.** A cross-product vision and the governance argument that closes this case study. The judgment is setting direction beyond his own product and framing approvals as a governance layer rather than a workflow feature.

## The AI-assisted build (field report, May 2026)

Source: Arnold's internal peer talk, "AI raises the cost of ambiguity: notes from one week of spec-driven, AI-assisted development," 2026-05-26. The feature built that week was Parallel Approvals, the capability he had championed through the advisory board. It is released.

His role in it: design owner and build partner, working the spec-development cycles closely with engineering and product management, in the room from day one.

### The mental model

Treat the AI agent like a new team member with zero product knowledge. Smart and fast, and ignorant of history, conventions, hidden decisions, and what "done" means here. In Arnold's words: "When humans are confused, they ask follow-up questions slowly. When agents are confused, they generate confident wrongness quickly."

That asymmetry is the entire thesis. A confused human costs you a meeting. A confused agent costs you a codebase that looks finished.

### The product problem built that week

Enterprise approvals often need multiple groups working in parallel, and the system mostly handled linear chains. The build moved toward one approval holding multiple independent parallel paths, with Brand, Legal, and Content reviewing simultaneously, each with its own stages and timeline. Simple approvals stay simple.

### The process: three phases, three feedback loops

**Define,** led by UX and product. Customer calls and discovery, then UX design plus a coded proof of concept, then the product requirements document and the critical user journeys. A product review gates the requirements document before any build starts.

**Specify and build,** engineering plus AI. Journeys and technical spec land in the repository, tech-lead sign-off is required, the agent builds from the spec with a structured context repository keeping it oriented between sessions, and then engineering, product, and UX validate in a loop that repeats until the merge request passes.

**Ship.** The team reviews the full build in staging, feedback is addressed, the staging preview auto-promotes on approval, and release notes go to customers.

By the end of the week: a demoable lifecycle, meaning create a template, apply it to an approval, run multiple parallel paths, and make a decision. Plus an artifact stack: journeys, technical approach, implementation specs, generated merge requests, and audit findings.

The pace claim, which is the reason anyone cares about this process: "When the process works, work that would take multiple sprints can move in days." And the counterfactual that makes it non-trivial: async handoff would have stretched that week into a month.

**Critical user journeys were the organizing unit, deliberately.** Not tasks. Tasks are construction; journeys anchor to what users actually need to do. That is a methodological position, not a documentation preference, and it is what kept a fast build pointed at outcomes rather than tickets.

### The proof of concept as source of truth

There was no Figma file.

Three fidelity tiers do different jobs. Mocks show the surface. Prototypes show behavior. A proof of concept shows structure. The agent needed all three, and the POC carried the most weight, because structure is the thing an agent cannot infer from a picture.

Three things made the POC work:

1. **Spectrum 2 components throughout,** so the agent had a real design-system vocabulary to match instead of freestyle interface invention.
2. **Documentation written specifically for the AI:** context, interaction rules, and edge cases, written so an agent could read the signals rather than a human reading the intent.
3. **Structure mirroring the production model,** meaning behavior and state organized the way the real application is organized, not just visual fidelity.

The takeaway, stated precisely because the sloppy version of it is a different and worse claim: this is explicitly not "designers should code." It is that for complex behavior, an intentional POC carries more design intent than any mock or rough prototype.

### Three sources of truth, visible at once

The agent is only as good as what it can see simultaneously:

- The POC, which is coded design intent.
- The requirements document, which is product intent.
- The repository state, which is the architecture new components have to fit into.

Holding all three in view between sessions was the job of a structured context repository that engineering built and maintained. The agent read it at the start of every session. It carried daily work logs, active project state, decisions and their rationale, and open questions, and engineers manually synced version-control history, chat, and meeting context into it.

That repository was engineering's work, not Arnold's, and this dossier does not credit it to him. His observation about it is his, and it is the sharpest thing in the field report:

If engineering maintains that much structured context for the codebase, where does design intent live? Right now, mostly nowhere. That is a gap worth closing.

The mechanics matter to that observation. It is not a rhetorical complaint about designers being undervalued. It is a specific structural asymmetry: one discipline has built durable, machine-readable memory of its decisions, and the discipline whose entire output is decisions about intent has not.

### Decisions had to happen in the room

The agent asked questions all week, and they were product-model questions rather than interface details. Beyond the templates ruling in D5, the live questions that week included: can path names be edited, what happens when a user deletes a path, and where should decision buttons appear. Every one of those has a right answer that depends on the model, and every one of them would have been answered by someone if a designer had not been there.

Front end, back end, product, and design were in the room from day one. Open design questions resolved in hours instead of days. Arnold's name for that effect: "That's the multiplier."

The Principal-level significance is a warning, not a boast. If model-level questions get deferred to product and engineering because the AI is building fast, UX loses control of the model. Not through a decision anyone announces. Through absence.

### What broke, honestly

- **Reusing repository components backfired.** Told to reuse existing components to avoid reinventing, the agent pulled ones built on an older design system. Version one was messy. It was caught and fixed.
- **The POC signals were strong and the build instructions were not.** One missing instruction mattered disproportionately: build new components on the current design system, do not inherit old ones. That level of specificity is the work now.
- **Automated checks passed while the experience was not ready.** Missing edge cases, reset behavior, disabled states, and no manual walkthrough. In Arnold's words: "Automation can't catch what only a human eye notices." Green tests are not UX readiness.

### What to keep, and the closing thesis

Keep: the POC as design source; critical user journeys as the organizing unit; a cross-functional team from day one; a shared structured context for the build.

Strengthen: sharper journeys before building starts; design intent living in the same structured context as engineering context; explicit component instructions that say exactly what to build new and what not to reuse; and guardrails alongside every spec, because what must not be built is as important as what should.

Collaboration concentrated at the bookends, define and review, while one engineer plus an agent handled the middle well. The visual layer gets cheaper. The behavior, trust, decision, and edge-case layers get more valuable. UX's role becomes making the spec clear enough to build from, and validating that what got built matches the intended experience. Both are design work.

"The craft isn't disappearing. It's moving." And: "AI raises the cost of ambiguity. Our job is to lower it."

## The reference build artifacts

The coded reference build was not a demo. It was the thing engineering built against. Six artifacts came out of it:

1. **End-to-end approval setup flow.** An AI-assisted React proof of concept in Adobe Spectrum 2 simulating the full approval setup experience.
2. **Document selection.** Choosing which assets belong in the approval, making visibility and scope explicit before review begins.
3. **Staged routing and participants.** Configuring stages and participants so lightweight reviews and structured enterprise workflows run on the same underlying model.
4. **Template-driven workflows.** Reusable approval templates that turn repeated review patterns into operational infrastructure.
5. **AI-ready implementation context.** Documentation translating the UX model into workflow rules, edge cases, component behavior, and implementation guidance that AI coding tools and engineers could act on directly.
6. **Storybook-ready components.** Component-level demos separating reusable approval behavior from one-off prototype screens, so the reusable parts could be evaluated as components rather than as screens.

The sixth is the least visible and the most telling. Separating reusable behavior from prototype scaffolding is the difference between a prototype that impresses and a prototype an engineering team can actually consume.

## Research method and evidence quality

The citations below carry methods and findings so a reader can weigh the evidence rather than take it. This section carries the quality signals that make weighing possible.

**Phase disclosure.** The June 2025 enterprise creative-workflow study is the most-cited source in this dossier, carrying the 7-of-7 work-in-progress finding and the 1-to-22 approver range. It is Phase 1 of 3. That is a real limitation and it is stated here rather than omitted: the strongest single evidence in this case study is the first third of a research program, not a completed one.

**Method detail that changes how a finding reads.** The February 2025 GenStudio usability study ran 75-minute sessions comparing a live flow against a prototype. The comparative design is what makes "explicit checkbox setup was understood immediately by all participants" a usability finding rather than a moderator's impression. Sample sizes throughout are small and qualitative, in the 2-to-10 participant range typical of enterprise usability work, with two exceptions that are meta-syntheses across dozens of prior studies.

**Exclusions were rule-governed, not ad hoc.** Three categories of material were removed from this evidence base by rule:

- Research on an unreleased product was excluded entirely, including its methodology and timeline, not just its findings.
- Study titles carrying internal codenames or pre-release labels were sanitized. The researcher and the finding stay; the codename goes.
- One internal strategy document marked confidential was excluded as a citation and used only as background context.

Naming the categories is a stronger integrity signal than asserting that nothing confidential appears, because it tells a reader what kind of thing is missing.

**What each study supports.** The map below is the join between evidence and design that a portfolio usually asks the reader to make on their own.

| Part of the work | Studies that support it |
|---|---|
| The problem | Assets Across Adobe 2021; Lauber 2021; Integrations 2023; Coco June 2025; Coco December 2025 |
| Design principles | Coco June 2025 for sovereign visibility; Coco September 2025 for objective versus subjective; Integrations 2023 for remove-steps |
| Segmentation | Coco September 2025 three-axis model; Lauber 2021; Assets Across Adobe 2021 |
| The moat and parity | Lauber 2021 on formal depth; Bulk Approvals 2026 on compliance template enforcement |
| Improvements | Integrations 2023; GenStudio 2025; Lauber 2021; Bulk Approvals 2026 |
| Governance and the forward view | Objective versus subjective, plus sovereign visibility read as a delegated-authority pattern |

**Two studies carried as Arnold's account.** The 2018 study of an enterprise design team, credited to Wallace in his narrative, and a 2018 Cloud Collaboration Files study, are both outside the verified backbone, which runs 2021 to 2026. They are marked as his account wherever they appear. They matter because they anchor the early end of the "nearly a decade" arc, and a reader should know that end of the arc rests on testimony while the rest rests on documents.

**Nine citations.** The list below has nine entries and the case-study page says nine. Three of the nine are not ADRS studies in the strict sense: entry 3 is a cross-functional vision document rather than a research study and is cited as lineage only; entry 2 was run under a cross-cloud content-collaboration initiative rather than by ADRS; entry 9 is Workfront usability testing with no individual researcher named in the source. Those distinctions are stated rather than flattened into a round number.

## Research foundation (verified citations)

All citations below were verified against the primary documents on 2026-06-26. Research relating to unreleased products is excluded entirely, as are internal codenames and product-health metrics.

1. **DeLuca, L. and Gu, M. (September 2021). Assets Across Adobe: Full Report. Adobe Design Research & Strategy.** Method: qualitative, enterprise roles across multiple large organizations, four role types covering operations, creatives, marketers, and technical marketers. Findings: no single tool wins asset management, because roles use assets differently; when the system fails, people build "safe spaces" outside it in local folders, email, and chat, which creates silos and hidden work; all roles perform repetitive manual curation before handoff; the asset chain breaks at four points, which are finding, curating and handoff, collaborating and feedback, and viewing and project managing. This study introduced two frames the rest of the synthesis runs on: the asset chain, and safe space versus silo.
2. **Lauber, E. (November to December 2021). Informal and Formal Approval Workflows in Workfront Proof. Adobe, Content Collaboration Across Clouds initiative.** Method: qualitative interviews with 10 enterprise Workfront Proof customers, spanning admins, work and project managers, and individual contributors. Findings: two distinct workflow types confirmed; informal peer and initial review happens outside Workfront in design tools, email, and meetings; formal approval routes through groups like Marketing, Creative, and Legal, and no two formal processes were the same; legal and compliance teams often work in separate systems, forcing manual download and re-upload; every customer wanted better proof metrics, specifically time per stage, version counts, and comment counts, which is a product requirement rather than a mood; Proof and Workfront felt like two systems.
3. **Internal unified review-and-approval concept work (2022).** A cross-functional vision and design concept document, not a research study, and not Arnold's authored work. The internal precursor to Unified Approvals. It framed a three-tier user model of peer review, coordinator, and formal review, and referenced the Creative Stakeholder Relationship Model of partner, influencer, and controller. Cited here as lineage only. The project codename is deliberately omitted.
4. **Lauber, E. (May 2023). Workfront + Creative Cloud Integrations Discovery. Adobe.** Method: qualitative discovery, 10 interviews across operations and creative roles at enterprises of varied size and industry. Findings: the integrations saw very low adoption and the cause was not missing features; creatives rejected them because they did not cut steps or add clear value over the browser; integrations supported only task-level work while many customers operate at project level; operations had no usage visibility, so adoption depended on a champion; creatives are one of the largest user groups yet score low on experience, which is a segmentation fact with real force. Key line: more features did not drive adoption, removing steps does. Internal adoption and spend metrics from this study are deliberately excluded.
5. **Mehta, T. (February 2025). GenStudio + Workfront Integration: Streamlining Approvals for Modern Marketers. Adobe Design Research & Strategy.** Method: usability testing, 6 marketing-operations participants, 75-minute sessions, live flow compared against a prototype. Findings: icon-based approver setup confused users while an explicit checkbox setup was understood immediately by all participants; due dates hidden in settings were a pain, and users expected them in the primary flow with both date and time; template findability was a top problem and search solved it for all participants; three to five approvers were typically sufficient, with flexibility to add stages for larger campaigns; custom request messages and real-time status raised confidence; cross-tool switching was a top friction.
6. **Coco, L. (June 2025). What's in it for Creative Pros? Enterprise creative-workflow study on the Workfront and Frame.io integration. Adobe Design Research & Strategy.** Method: qualitative, 7 enterprise creative professionals at companies of 5,000 or more employees. Phase 1 of 3. Findings: 7 of 7 raised serious concern about work-in-progress visibility to non-designers and said they will work outside the system if work in progress is not protected; formal approver counts ranged from 1 to 22 and were never just 1, with a floor of at minimum a client plus a creative director; informal review is fast and undocumented by design while formal review is documented for legal protection; real-time co-editing is uncommon for these designers, with solo file work and handoffs the norm; if the new flow feels confusing, they revert to exporting a PDF. Principle anchor: flexible on storage, sovereign on visibility.
7. **Coco, L. (September 2025). ADRS Research Rollup: Brand Checking and Validation. Adobe Design Research & Strategy.** Method: meta-synthesis of 33 prior research efforts from 2020 to 2024, enterprise through small and mid-sized business. Findings: validation mode depends on context and no single mode fits; three-axis segmentation by company size, campaign type as macro and permanent versus agile and ephemeral, and ownership as in-house versus agency, so the same brand runs different validation regimes; objective brand rules covering logo, color, font, and spacing are tool-checkable while subjective ones covering tone and new channels need human judgment; locked templates are how brand is governed today, not a legacy pattern; AI validation should flag subjective questions rather than guess at them.
8. **Coco, L. (December 2025). Rollup: Content Supply Chain and Brand Work. Adobe Design Research & Strategy.** Method: synthesis briefing across content-supply-chain and brand research. Findings: review and approval recurs at many handoff points across the content supply chain, not at one gate; asset durability, meaning durable, semi-permanent, or ephemeral, drives how much creative involvement and templating each asset needs; brand is infused across all phases rather than checked at one.
9. **Bulk Approvals Usability Testing (January 2026). Workfront.** Method: two moderated enterprise usability sessions with enterprise teams and implementation partners. No individual researcher is named in the source. Findings: high-volume teams running tens of concurrent approvals need a single searchable approval queue, not a small home widget; regulated teams need forced approval-template enforcement, because ad hoc approvals are a compliance blocker rather than a preference; senders need group-level review tracking after a batch is submitted, not just per-asset status; the core bulk flow and a carousel review experience tested well without instruction. Participant and partner-firm names, the named regulated customer, numeric usability scores, and release timing from this study are deliberately excluded.

## Cross-study synthesis

These are Arnold's syntheses, resting on the citations above.

**Approval is not one workflow, triangulated.** The informal and formal split documented in 2021, the peer, coordinator, and formal concept model from 2022, and the 2025 studies independently reach the same shape across different researchers and different years. The longitudinal agreement is itself evidence. One study finding a pattern is a finding. Three finding it across five years without coordinating is a property of the domain.

**The export-to-PDF loop is generational.** The same coordination loop was observed in 2018 and again in 2025. Not a regression. A failure that survived a full product generation because nothing in that generation addressed its cause.

**Shadow systems are a trust-architecture failure, not a workflow one.** When a system does not make state legible, people build accountability outside it, using screenshots, PDFs, and local folders. The behavior is rational. Fixing the workflow does not fix it. Making the record trustworthy does.

**Visibility is sovereign, storage is flexible.** The strongest principle line in the whole evidence base, and a delegated-authority pattern: control over exposure is the thing users will not concede, and it is the thing a system has to hand back to them explicitly.

**Templates are authority architecture.** Operational infrastructure for governing brand and compliance at scale, not legacy baggage.

**Objective versus subjective.** Tools verify the objective; humans judge the subjective. This is the bridge to agent-era approvals: automate the objective checks and escalate ambiguity to a human, rather than asking a model to guess at taste and calling the guess governance.

## Verified customer quotes

Each quote was verified word for word against the primary document on 2026-06-26. Punctuation inside quotes is reproduced exactly, which is why em dashes appear inside them and nowhere else in this dossier. Attribution follows the source's own rule: role plus researcher, never an individual's name, and never a company attached to a quote. Mapping a role to a specific employer would be inference presented as fact, and this dossier does not do that.

**On work-in-progress visibility:** "That would be bad. Like, really bad. I don't want anyone seeing my stuff until I've cleaned it up. It's not ready—it's not the story I want to tell yet." A graphic designer (Coco, June 2025).

**On reverting when the system confuses:** "Adobe is REALLY going to have to make the workflow seem straight-forward and clear. I know for our designers, if they hit any sort of confusion or trouble spots, they're going to ignore the new system, export a PDF and upload it into WF." A design technologist (Coco, June 2025).

**On unification:** "[The impact of this would be] less time spent on process and more time spent on designing—which is what we do. If everything is under one spot, we won't ever have to create a PDF." A senior art director (Coco, June 2025).

**On scale:** "Trying to navigate to that one that you want — having the ability to search the approvals in there would be a really helpful add-on." An operations lead (Bulk Approvals Usability Testing, 2026).

**On compliance:** "The only question I have around it is do you have the ability to restrict people at all from doing non-templated approvals." An enterprise implementation consultant (Bulk Approvals Usability Testing, 2026).

The last one is worth reading twice. An implementation consultant asking whether the system can prevent non-templated approvals is asking for a restriction on their own users, which is what it sounds like when governance is a requirement rather than a preference.

## Personas and jobs to be done

This case study maps to Workfront's canonical persona and jobs-to-be-done framework rather than to invented personas. Six of the canonical thirteen are relevant, confirmed as the relevant subset rather than selected for convenience. Using six of thirteen is the difference between selection and invention, and the four that are excluded are excluded because the approval act does not belong to them.

### Desi, designer

Creates the work. Owns the work-in-progress visibility concern. The informal-review actor.

Wants: feedback consolidated in one place; to know whether a reviewer has actually seen the work; version history tied to decisions.

Frustrations: conflicting feedback with no clear decision-maker; chasing stakeholders; review cycles dragging because approvers do not know the deadline.

Jobs: 4.1.4 request feedback and collaborate with peers; 4.2.1 send and manage reviews; 4.2.2 view and respond to reviews; 4.3.3 mark task complete; 4.1.3 add content to project.

Research tie: the 7-of-7 work-in-progress finding, and the revert-to-PDF risk if the flow confuses. The deadline frustration is exactly what the GenStudio due-date finding addresses, which is why due dates moved into the primary request flow with both date and time rather than staying in settings.

### Rayna, reviewer and approver

Gives feedback and makes decisions. Not in Workfront daily; pulled in when something needs a decision.

Wants: to review without learning a new tool; enough context to decide; one place to see everything waiting on her; mobile approvals.

Frustrations: requests arriving without context; email and Workfront comments falling out of sync; high notification volume with low signal; never being sure whether her feedback was addressed.

Jobs: 4.2.2 view and respond to reviews; 4.2.5 understand review decisions; 4.3.2 review task.

Research tie: the 1-to-22 formal approver range, and the concurrent-approvals queue finding. Her "not in Workfront daily" fact is the reason My Approvals lives in Home. Her "never sure if feedback was addressed" frustration is the reason the Needs Work loop has to close visibly rather than silently.

### Petra, project manager

Owns the project plan from kickoff to delivery. The connective tissue between strategy and execution. Owns templates and status.

Wants: templates she can trust; status visibility without chasing the team; milestone risk surfaced early.

Frustrations: stale status because the team does not update it; scope changes arriving informally; reporting that eats time she does not have.

Jobs: 3.1.2 create repeatable workflow; 3.5.2 ensure statuses are up to date; 3.5.4 understand project status.

Research tie: templates as authority, and status legibility versus shadow systems. Her stale-status frustration is the shadow-systems problem seen from the coordination side: if the system does not hold the state, someone has to ask people for it.

### Olivia, operations lead

Designs the systems other people work inside: templates, workflows, automations, taxonomies.

Wants: to build and enforce consistent templates and workflows; automation that cuts handoffs; to roll out changes without breaking in-flight work.

Frustrations: teams create workarounds that undermine the system; no way to see which workflows are actually used.

Jobs: 0.1.3 configure permissions; 0.2.1 customize software; 0.2.4 define taxonomies; 0.3.3 set automations; 1.1.4 system health check.

Research tie: templates as operational infrastructure; the moat capabilities; the bulk-approvals finding that regulated teams need forced template enforcement. Her workarounds frustration is the shadow-systems insight from the operations side, and it is the reason enforcement is a feature rather than a policy memo.

### Sally, system enabler and administrator

Manages access and configuration at scale. Governance and audit.

Wants: admin controls that scale; a clear audit trail of who changed what and when; to test configuration before rollout; group-level permissions.

Frustrations: overly granular permissions; learning about breakages from end users; configuration that lives in her head rather than in the system.

Jobs: 0.1.3 configure permissions; 0.1.4 add user groups; 0.2.7 manage global settings; 1.1.1 manage users; 1.1.2 adjust permissions; 1.1.4 system health check.

Research tie: auditability and private and locked stages as enterprise trust. Her last frustration is the same trust-architecture failure as the designer's shadow spreadsheet, one altitude up: when the system will not hold the knowledge, a person does, and then the knowledge leaves when they do.

### Miriam, marketing director

Manages programs, not tasks. Wants portfolio visibility and early risk warning.

Wants: a portfolio view with status, owner, and health at a glance; early warning before a miss; reliable data for leadership conversations.

Frustrations: inconsistent status across project managers; finding out about problems from people rather than from the system; manual reporting.

Jobs: 2.1.5 plan approvals; 2.2.6 campaign approvals; 2.3.6 content and request approvals; 2.2.7 monitor campaigns; 3.5.7 generate status reports; 4.4.1 surface work performance insights.

Research tie: monitoring by exception, and the objective versus subjective frame. She is the reason approval status has to be an observable property of the system rather than a report someone assembles.

### The beat map

| Story beat | Jobs | Owners |
|---|---|---|
| Fragmented review and shadow systems | 4.1.4, 4.2.1, 4.2.2 | Desi, Rayna |
| Approval is not one workflow | 4.2.3, 2.1.5, 2.2.6, 2.3.6 | Desi, Rayna, Miriam |
| Visibility is sovereign | 4.1.4, 3.5.2, 3.5.4 | Desi, Petra |
| Templates as authority | 3.1.2, 0.1.3, 1.1.2 | Petra, Olivia, Sally |
| Decisions and accountability | 4.2.4, 4.2.5, 4.3.3, 4.3.4 | Desi, Rayna |
| Brand alignment | 4.1.2 | Desi, Rayna |
| Leadership visibility | 4.4.1, 3.5.7, 2.2.7 | Miriam |

The brand-alignment row is the jobs-to-be-done hook for the AI-powered brand-standard checks that shipped in review. It connects the objective-versus-subjective research frame to a shipped capability through a canonical job rather than through an assertion.

### Discipline notes and source discrepancies

The 4.x review-and-approval jobs are canonically assigned to Desi and Rayna. Petra, Miriam, Olivia, and Sally connect to approvals through project, planning, and governance jobs, not through the approval act itself. Those assignments are respected here. Petra is not promoted to owner of the approval workflow just because she creates the request, and resisting that promotion is what keeps the persona model honest rather than convenient.

Two internal inconsistencies in the canonical framework were found and resolved rather than papered over. The permissions jobs 0.1.3 and 1.1.2 are attributed in one part of the framework to a system-admin persona named Alex, while the persona roster uses Sally for that role; this dossier uses Sally. The jobs files spell the marketing director "Mariam" while the roster spells her "Miriam"; this dossier uses Miriam. Both are noted because noticing and resolving contradictions in a canonical framework is worth more than the roster itself.

## Where the work stands, and whose numbers are whose

**Shipped.** Adobe Unified Review and Approval was announced on 2026-03-26 in a bylined post by Jason Barron, Group Product Manager, and became generally available on 2026-04-17, available to all Workfront customers upon a contract update. It continues to evolve through close customer partnership.

**Adobe's published business case, attributed to Adobe and not to Arnold.** "The problem isn't the tools themselves, it's the seams between them." Review and approval "sits right at the center of every content operation." And the bottleneck argument, which is the one that matters structurally: you can speed creation with AI and automate distribution, "but if the review and approval step is still a bottleneck, then the gains on either side are capped." Adobe also frames the market shift, that video is now the dominant format across channels while legacy review tools were built for static documents first and video second or not at all, and positions Unified Review and Approval as a foundational piece of its content supply chain vision.

**Adobe's reported customer outcomes are not reproduced here.** Adobe publishes customer outcome figures for Workfront in its own case studies, including named-customer numbers it attaches to the review-and-approval story. Those are Adobe's claims about Workfront broadly. They predate and are broader than Unified Review and Approval specifically, they are not results of this feature, and they are not Arnold's results, so this dossier points to Adobe's published case studies rather than repeating the figures. Princess Cruise Lines reports a successful remote workflow, qualitatively, with no single metric to quote. Early adopters span pharmaceutical, retail, financial services, and media.

**Shipped product capabilities, per Adobe's public pages.** Frame.io as the professional review surface embedded in Workfront; 40 or more file formats with native professional video including ProRes, H.265, and DNxHD, plus frame-accurate commenting and camera raw support; semantic search that auto-indexes assets for natural-language retrieval; dynamic and forensic watermarking; DRM with automatic asset deletion; content credentials for AI-generated content; AI-powered quality controls that alert creatives when assets are out of sync with brand standards; single-stage and multistage automated workflows with dependencies between stages; integrated proofing inside GenStudio for Performance Marketing and from remixed Adobe Express templates; and the shared enterprise storage layer connecting Workfront, Frame.io, and Creative Cloud.

On file size, Adobe's own copy disagrees with itself: the product page states project file uploads up to 5 TB, and the blog cites 500 GB in the unified-review context. The likely explanation is that 5 TB is the general Frame.io for Business maximum and 500 GB is what the blog cited for this specific context, but Adobe has not reconciled them publicly, so both are reported here with their sources rather than one being chosen silently.

**Arnold's honest outcome line.** The contribution is the architecture, the reference build, the parallel-approvals direction, and customer-grounded judgment. Impact data tied specifically to his contribution is still emerging. Nothing in this document claims Adobe's numbers as his, and the wall between the two is deliberate: blurring a company's published business case with an individual's contribution is the fastest way to lose a reader who is paying attention.

## Where it is heading: Project Tempo (vision, not shipped)

Everything in this section is vision and leadership work, socialized for about a year, and labeled as such. None of it is a committed Adobe roadmap or ship date.

**How it started.** While the Workfront and Frame.io integration was underway, leadership saw the inconsistency between the two products' review-and-approval experiences and asked for a UX-driven point of view on what a consistent experience should be. The UX team took the lead. It became apparent quickly that the inconsistency was not a two-product problem. It runs across Adobe's solution offering. The effort grew into Project Tempo: a composable, AI-first review-and-approval layer designed to be consistent across the Adobe ecosystem. One approval service behind any surface.

**Arnold's role, stated precisely.** He co-led a cross-product vision sprint as the Workfront design lead, one of the core drivers in a UX-led team effort. He produced the Day 3 end-to-end flow with its assumptions and modular components, the problem pre-read deck, and the higher-fidelity sketches and mocks for the executive readout, as the Workfront representative in the cross-product sprint. He did not run Project Tempo, and this dossier does not say he did; the record shows a team.

**The sprint's operating constraint.** Three days, cross-product, run deliberately without technology constraints. The instruction was to outline the ideal scenario regardless of what either product could do that day. That constraint is not a fantasy license. It is the only way to get a north star that multiple product teams can align to, because the moment current capability enters the room, the vision converges on whichever product is furthest along.

**What it produced.** Guiding principles, a capability list for the composable service, high-level user flows, an end-to-end flow with the modular components required, and a set of pillars to explore: versioning with requesting and approval, feedback with decision, and tracking with history. The work also included a Figma walkthrough of the point of view and a round of customer validation sessions.

**Guiding principles.** AI-first by design, meaning every feature assumes an intelligent architecture rather than bolting intelligence on afterward. Single source of truth, meaning approvals happen through one service regardless of the interface surface. Extensible and evolvable architecture, meaning modular services that can absorb new AI capabilities without a rewrite. Incremental adoption, meaning teams onboard piece by piece rather than through a big-bang migration.

**The persona bridge.** Tempo's abstracted personas map onto the canonical Workfront ones, which is the evidence that the vision was built on the same user model as the shipped product rather than freehand. Producers, who create content and care about accuracy, quality, and readiness for review, correspond to Desi. Operations, who coordinate workflow between producers, reviewers, and approvers and care about timelines, routing, and progress, correspond to Petra and Olivia. Reviewers and approvers, who assess accuracy, quality, brand, and compliance, with reviewers giving feedback and approvers deciding, correspond to Rayna.

**The vision statement.** Transform Adobe into the enterprise standard for approval and governance, where teams collaborate with confidence and approvals are as seamless and intelligent as creation itself.

**The market-position argument, which is Arnold's own point of view and the most strategic thing in this dossier.** Adobe already leads content production. The open opportunity is to lead content compliance and governance. Position Adobe as the trusted operating system for decision-making and accountability across the content supply chain: governance, traceability, and confidence regardless of where the work originates.

That is a designer articulating a market position rather than a feature set, and it is worth separating from the rest of this document for exactly that reason. The shipped product is the proof that the position is available. Approvals already function as the governance layer for execution in every enterprise that runs on them. Nobody has claimed the category.

**The governance coda.** Approvals become a governance layer, for humans now and for AI agents next. Automate the objective checks, meaning brand rules and compliance, and escalate the ambiguous and the subjective to a human. Where a human decides versus where an agent decides was an explicit pillar of this work, which is to say the question was treated as a design problem rather than as a policy problem to be solved later.

That is the same delegated-authority pattern Arnold develops in his Delegated Authority Framework research. The shipped Unified Approvals system is its first proof at scale: a system where something proposes, the structure routes, a decision gates what ships, and the record holds afterward. Swap the proposer from a human to an agent and the shape of the problem does not change. Only the stakes do.

## Open problems and unresolved questions

Kept visible on purpose, because a dossier that resolves every ambiguity in its author's favor is not a record, it is a brochure.

**The naming.** Adobe's public product name is Unified Review and Approval, singular and without an ampersand. This portfolio has used Unified Approvals on the case-study page and Unified Review & Approvals in this dossier's title. They refer to the same product. A reader who searches will find Adobe's name, which is the argument for converging on it, and the convergence has not happened yet.

**The 2018 anchor.** The early end of the "nearly a decade" arc rests on two studies carried as Arnold's account rather than verified against primary documents. Until those are located and checked, the decade framing is one verified end and one testimonial end.

**Attribution of the framing.** Whether Arnold named the four tensions or inherited them from the research, and whether the moat constraint was his call or handed to him, are not settled in the material behind this dossier. At a systems level the framing is the contribution, so these are not trivia. They are stated as open rather than resolved in the flattering direction.

**Where design intent lives.** The build story surfaces a real structural gap: engineering maintains durable, machine-readable context for the codebase, and design has no equivalent for intent. Arnold names the gap and does not yet have a general answer to it. His own practice is one working instance, not a solution the industry can adopt.

**How complete the four surfaces are.** Adobe's marketing page and Adobe's documentation do not fully agree about the state of the Frame.io viewer experience inside Express and GenStudio. This dossier reports both rather than picking one.

**Impact.** There is no metric tied specifically to Arnold's contribution beyond shipped plus strong validation. That may change as the product matures in the field. Until it does, the honest outcome is the architecture, the reference build, the direction change on parallel approvals, and the customer-grounded judgment behind all three.

## How this connects to the rest of Arnold's work

This case study is the first page of a trilogy and the shipped one. The other pages carry the same argument at different scales, and each owns a different half so they do not repeat each other.

**AI Collaborators** brings AI agents into Workfront as permissioned users who can be assigned work and held to it. Unified Approvals is the system those collaborators route their work through: the first shipped collaborator operates inside review workflows. This page owns the decision system. That page owns the product surface where agents become participants in it. See the AI Collaborators dossier at /dossiers/ai-collaborators.md.

**The Delegated Authority Framework** is the answer to the question the collaborator surface raises and cannot yet answer: what is an agent allowed to do right now, on whose authority, within what blast radius, and on whose record. Unified Approvals is the existence proof that approvals already function as a governance layer for execution. DAF asks what that layer becomes when the thing proposing is not a person. The objective-versus-subjective principle in this dossier, automate the checkable and escalate the ambiguous, is the same rule DAF formalizes as a gate. See /dossiers/daf.md.

**Workfront Blueprints** is where the pattern starts, in 2021. Package what works, govern it, then let people build on it instead of rebuilding it. Blueprints made implementation reusable; Unified Approvals made decisions reusable. The through-line is the same conviction: durable systems beat faster one-offs, and governance is what makes reuse safe at scale. See /dossiers/blueprints.md.

**Sancho**, Arnold's second brain, is the same governance shape at personal scale: a model proposes, a human governs, and a record keeps both honest. He operates daily inside the pattern this case study shipped and the DAF research formalizes. See /dossiers/sancho.md.

Read together: people, then agents, then the authority underneath both, with a reusable-infrastructure argument running under all of it. Same argument at four scales. This is the one that shipped.

## Confidentiality and provenance statement

This dossier deliberately excludes: individual research-participant names; company attributions on research quotes, because mapping a speaker's role to an employer would be inference rather than fact; internal product-health and adoption metrics; internal codenames, internal platform names, and internal tool names; unreleased product specifics, feature names, release phases, and timelines; confidential strategy documents; research on unreleased products, excluded entirely including its methodology and timeline; and the internal program names from the cross-product vision work.

Enterprise brand names appear only where they are public Adobe customers or where Adobe itself published the outcome. Advisory-board feedback is reported in aggregate only, and no private session stance is attributed to any member. The named individuals in this document are limited to the public bylined author of Adobe's announcement and the ADRS researchers credited for their own studies, which follows Arnold's own rule of crediting research to the people who did it.

The foundational research is credited to its named researchers. The structured context repository from the build story is credited to engineering. Adobe's business results are credited to Adobe. What remains, meaning the architecture, the synthesis, the decisions, the design leadership, and the vision, is Arnold's. That boundary is drawn deliberately: keeping other people's work clearly labeled is what keeps the rest unambiguously his.

**Provenance.** Compiled from Arnold's first-person interview capture (2026-06-29), his internal field-report deck (2026-05-26), the released approval architecture and flow specifications, nine research citations verified against their primary documents on 2026-06-26, Adobe's public blog and product pages verified on 2026-06-29, Adobe's Experience League documentation and its 2026-04-17 general-availability announcement, the canonical Workfront persona and jobs-to-be-done framework, and the Project Tempo vision materials. Quotes were verified word for word against their primary documents on 2026-06-26, with punctuation preserved exactly.

Pending: Arnold's line-by-line review of the underlying capture material, which is his own account structured into working documents rather than a ratified record, and verification of the two 2018 studies carried here as his account. This document will be revised as those close. Assembled 2026-07-30.