At Arco’s Evaluation team, my main objective was to help build from scratch the system used to plan, create, review and publish assessment questions for high school exams. Arco’s assessment-item production relied on a fragmented workflow across internal teams, freelancers, spreadsheets and legacy tools, making a single item take up to 45 days to reach publication.
The Problem
Assessment items moved through multiple necessary editorial stages but coordination happened across more than five different tools and platforms. This made ownership, revision history and progress difficult to track.
One connected lifecycle.
We built a new management system, connecting content, workflow, ownership, feedback, history and publication in one lifecycle.
The experience introduced features like configurable production stages, traceable revision history, contextual feedback, role-based permissions and a direct path from editorial production to the school’s question bank.
Mapping a complex system
When a student reads a question in a test, there is a complex operation behind that action involving several actors, processes and editorial decisions.
Every year, the Evaluations Content team defines exam requirements and themes, while external freelancers handle much of the writing, editing, and review.
Creating each question involves multiple specialists, stages, and responsibilities, requiring coordination across deadlines, files, revisions, approvals, and publication. Over time, the system supporting this process became a bottleneck, making it difficult to track progress and identify issues early. As a result, questions could take approximately 45 days to complete, and errors were sometimes only discovered after publication.
Understanding the core object
My initial exploration focused on defining the question as a product object: what information it should contain, what stage every collaborator needed to work on, what could change throughout its lifecycle, what needed to remain traceable, how legacy items would be incorporated, and how access should vary across roles.
The discovery combined conversations with editorial users and stakeholders with product data and analysis of the existing workflow.
These findings became the foundation for the product architecture and helped us move beyond reproducing the existing spreadsheets inside a new interface.
Findings
01 · Status wasn’t enough
Knowing that an item was ‘in review’ did not necessarily tell someone what was happening, who owned the next step or what was blocking progress.
02 · Feedback lived across the workflow
Creation and review were highly interdependent. When feedback and revisions were difficult to follow, teams spent additional effort reconstructing context.
03 · Each role needed a different level of information
An elaborator needed to know what required action. A reviewer needed context to evaluate an item. A manager needed to understand the health of the entire pipeline.
Connecting the entire production
During our process, we realized that the rigor of the editorial workflow was necessary to ensure content quality. The opportunity wasn’t to simplify the process itself, but to make that complexity easier to manage by moving coordination, traceability, and handoffs into the product.
The new experience brought previously fragmented parts of production into the lifecycle of the question itself, reducing dependence on parallel controls and creating greater visibility into status, ownership, revisions, and publication.
01Making the workflow visible
Editorial coordinators needed to manage a rigorous production pipeline, while individual users needed clarity about what required their attention.
02Traceable production
Revision loops made it difficult to reconstruct what happened and why. Record transitions, responsibilities, and review context as part of the item's history.
03Showing each collaborator only what they needed
Show each role the complexity it actually needs.
Coordinators, authors, reviewers, and registration roles required different information and actions. Use role- and stage-based permissions instead of exposing the entire operational model to every user.
04End-to-end experience
Previously, completing the editorial process still created another operational handoff.
Approved questions had to be manually transferred into a separate legacy platform before becoming available in the question bank. By bringing registration into the same lifecycle, we removed that discontinuity.
We also introduced a student-view preview so editorial teams could verify the final experience before publication.
Designing beyond the feature
Beyond the workflow and product architecture, the project also required new interaction patterns to support dense editorial tasks without adding unnecessary cognitive load.
I designed several components specifically for the assessment workflow, including a hierarchical checkbox tree for selecting question themes, reusable question-alternative components, and a contextual commenting pattern for editorial feedback.
As these patterns matured, some were generalized and contributed back to Iris, Arco’s design system, extending their value beyond the product and enabling reuse across other teams and experiences.
Learnings
Complex workflows don’t always need fewer steps.
The many editorial stages existed to protect content quality. The opportunity was to reduce the coordination effort surrounding the process and not necessarily remove the control.
A management system is more than centralized data.
Simply replicating the previous process editors did in sheets wouldn’t solve the workflow. Users could also use this central space to understand state, responsibility, history logs and next action from the same object.
Permissions are a design problem
In operational tools, clarity depends as much on what users don’t see as what they do.
The permission model became a way to reduce clutter and complexity without removing the underlying sophistication of the system.