Replacing a decade of folders with one searchable layer for hundreds of schools

TLDR

Problem
The client stored documents across Box, SharePoint, email, and OneDrive with no shared metadata and folder conventions that differed by team. Finding a file meant asking the person who built the folder. As the platform expanded into new service modules, the problem would get worse.

What I did
Led UX and product design for a platform-native metadata layer: every file carries type, service, school, period, and owner. Designed the information architecture, two home experiences for two different audiences, a permission model built around roles rather than manual sharing, and a working prototype with eight live routes.

Result
Every contracted artifact delivered; two exceeded what the SOW asked for. The “lo-fi prototype” became a fully interactive coded app. Five stakeholders aligned on one direction across a three-week sprint.

Four systems, no shared way to find anything

Documents were split across four systems with no shared way to find anything. Schools got routed to whichever system the relevant team used, and Box’s waterfall permissions meant they often landed on a scattered list of folders at inconsistent depths with no clear top-level view. With the platform expanding into Service Center, Inspections, and Billing, each new module would add more documents to the same fragmented structure. The engagement was a three-week sprint to map the current state, prototype a metadata-driven repository, and give the client something concrete enough to build from.

“Documents management comes up in nearly every conversation about what we plan to do long term. We need this design even if we’re not necessarily ready to build immediately.”
— Platform Lead, April 2026

The design target was the EdTech specialist who had organized Box folders for ten years and expected the new system to be harder to use. Every design decision came back to one question: does this show you will find things faster here?

Discovery & Research: The interviews that built the taxonomy

Four moderated sessions over two weeks with five stakeholders, covering three primary personas: an EdTech specialist who lived in Box, an operations lead who worked in SharePoint, and an IT infrastructure lead who managed both. Each walked through how they actually store, find, and share documents today. Three problems came up in every session.

Finding a document meant finding a person

Staff routinely spent 5–30 minutes locating a file, and often weren’t sure which system held it in the first place. Box sends a notification when something is uploaded, but it carries no context about where the file actually landed. The specialist still has to navigate the folder tree themselves. Nothing was indexed across systems, because nothing shared any metadata.

“I can rarely find a document on my own. I always have to ask whoever owns it. Unless you’ve been here over a year, finding anything in the folder structure is impractical.”
— Operations Lead, discovery interview

No shared folder convention

Folders ran five to ten levels deep in both cases, with no consistent logic between them. Someone working across both divisions was navigating two completely different information architectures. For schools, it was worse: Box’s waterfall permissions meant they often saw a scattered set of folders shared at different depths, with no coherent top-level view.

Too many logins

Schools run on Google Workspace internally. Working with the client meant a separate Box account, SharePoint guest links, and email, each with its own credentials and expiry. Staff described onboarding and offboarding as a manual, error-prone process as a result. The request from schools was simple: log in once and see everything for my school.

I mapped document flows end-to-end for both service lines. The maps confirmed the structural cause: deep folder trees built independently by each team, with permission inheritance broken during a prior migration from Google Drive to SharePoint. They also showed something useful: the documents themselves are predictable in type and origin, which is exactly what a metadata model needs to work.

Where the taxonomy came from

The most useful moment in Week 1 came from a simple question I asked the operations lead: would her colleagues fill in metadata consistently if it required manual entry? Her answer was immediate: “They don’t do metadata at all.” Then she spent five minutes describing exactly what the tags needed to be, without any prompting:

“Almost every file needs a customer tag, a date tag, a functional tag, probably an owner tag, a school tag — even a process tag. If it’s payroll: ‘employee changes, this pay cycle.’ Same with accounting. Also bank. And supplier for AP, because we’ll need 1099s.”
— Operations Lead

That session produced the metadata field set (organization, service, document type, process, period, access scope) that became the backbone of the information architecture. It didn’t come from a workshop or a competitive audit. It came from listening to someone describe what they already knew they needed.

Strategy & Scope: Two paths, one deliberate choice

Before any design work, the engagement lead raised the foundational question: is the client in the document-management business long-term? Two paths were laid out as a real choice, not a recommendation in disguise:

The platform lead chose the platform-native path. The product stores files produced through the platform, applies metadata from the workflow context, and supports search and filtering without any folder navigation. Migrating the existing archives was explicitly a non-goal. Box freezes as a read-only archive. SharePoint stays as a bridge for the rare files that need live collaborative editing, with a reference kept in the repository so they still show up in search.

“The scope of the project should be based on customer experience — that is always our North Star. Define the experience first. Treat the system as a black box. Let that drive implementation.”
— Sridhar Karimanal, Point One Zero engagement lead, May 8 sync

One design question had to be answered before anything else: how should access work? Most documents should follow a role. When a Business Manager leaves and someone new takes the seat, their document access transfers automatically. Some documents should stay with a specific person regardless of role changes, like an attachment on a personal service request. Getting this right early meant it could inform the information architecture from the start rather than being retrofitted later.

Solution: One model, two front doors

The core idea: every file carries structured metadata the moment it enters the system, and search and filters do the retrieval. No folder path. No naming convention to remember. You find a document by what it is, not where it was filed.

What’s live vs. simulated in the prototype.
The full interface, permission logic, metadata model, and all interactions are real and running. The backend storage, authentication, file transmission, AI responses, and exports are simulated. This is a socialization prototype built to demonstrate the experience and validate the design direction, not a production build.

Go ahead and click in — every prototype on this page is fully interactive.

What a tagged document looks like

When a document is uploaded through a platform workflow, most of its metadata — fields like client, service, and process — fills in automatically from the context of the task that triggered it. The person uploading confirms the document type and sets who should have access. That’s typically two or three decisions, not a full form to fill out. Click any editable field below to change it, add or remove tags, or open the “Share & access” panel.

The repository — staff view

Staff get a dense, filterable table with fuzzy search across every document the platform has ever produced. Filters stack: narrow by service, then by document type, then by period, and get exactly the slice you need. Saved filter presets let people bookmark their recurring searches so the view is always there when they need it.

Two homes from one data model

Staff and school clients have fundamentally different needs when it comes to documents, so they get different home experiences built on the same underlying data. One shared interface would force compromises on both. Two separate products would mean duplicating the data and doubling the maintenance burden. One data model with two purpose-built surfaces was the right call.

Key surfaces in detail

Document detail and sharing

Every document has a detail page showing its full metadata, version history, and an activity log. From here, staff can share the document with specific people or roles without touching any admin settings. The sharing panel shows exactly who has access and why: by role, by individual, or by team.

Submission wizard

When a school submits a document as part of a workflow task, they go through a short wizard that already knows the context: which school, which service, which process. The school confirms the document type, uploads the file, and lands on the resulting document in the repository. If this is a resubmission after a return, the wizard shows the reviewer’s return reason at the top so the school knows exactly what to fix.

Access management

Admins can inspect any user and see exactly why they have access to a given document: is it because of their role, a direct share, a team they belong to, or their organization’s default scope? The same answer that powers the permission logic shows up directly in the interface, so what you read on screen reflects how the system actually works.

Trash and recovery

Deleted documents move to a trash bin with a 30-day recovery window before permanent deletion. Permanent deletion is a capability that admins can grant to specific staff without giving them full admin access, so the right people can clean up without opening up everything else.

Design Rationale: The decisions that shaped the product

Cutting features to make the demo land

The first version of the prototype had a five-stage document workflow, approval indicators, dedicated pages for each service module, and a separate filter just for modules. When I reviewed it with the platform lead, the feedback was clear: the demo had one job — show that you can find things faster here. The extra surfaces were distracting from that.

I removed the workflow layer entirely and collapsed document status to two states: active and final. The module pages came out, because workflow belongs inside the service modules that own it, not the document layer. The module filter came out, because the service filter already handled it. The prototype got simpler and the thesis became easier to see. The features that came out weren’t wrong. They just weren’t the right thing to lead with for a skeptical first audience.

How the permission model evolved

The initial idea from the platform lead at kickoff was the right one: access should follow the role, not the person. A school’s Business Manager should be able to see their organization’s documents because of the seat they hold, not because someone manually shared each document with them. When a new person takes that role, they inherit the access. When someone leaves, it goes with them.

The implementation took three iterations to get right.

Metadata instead of better folders

The alternative I considered seriously was improving the folder conventions rather than replacing them: enforce a shared structure, build better tooling around it, and train teams to use it. The reason I didn’t recommend it: it requires ongoing discipline from every person who creates a document. The moment one team builds a slightly different structure, the model breaks for anyone who crosses that boundary. With metadata, the structure is applied at the point of upload based on the workflow context, not by the person uploading. The mental-model shift for people used to folders is real, which is why saved filters exist.

Saved filters as a bridge for folder habits

People who are used to folders don’t primarily search. They navigate to a known place and scan. Saved filters give them a direct equivalent: a named, persistent view like “Charter School A, current-year compliance” that updates automatically as new matching documents arrive. It behaves like a folder from a mental-model perspective. It’s actually a saved search that runs against the metadata. This was the most concrete UX response to the adoption risk the research surfaced.

Designing the failure paths first

For a prototype built to change the minds of people who were already skeptical, a single confusing moment can undo everything. I mapped failure paths alongside happy paths and treated them with the same priority. The most urgent fix during the engagement was a case where an uploaded file briefly disappeared from the repository view. In a demo for people whose core concern is “will this system lose my documents,” that moment reads as confirmation of everything they feared. Making sure uploaded files stayed visible, required steps were surfaced clearly, and nothing happened silently was more important than adding any new feature.

Review & Feasibility: What got validated

The internal design review covered all five deliverables and the prototype with the full stakeholder group. Two filter refinements came out of it: Document Type now scopes to the active Service selection, and Service is the fixed primary filter dimension. The review also surfaced a permission gap — no mechanism yet to limit a school’s access to only their contracted services — logged as an open question with a workaround and a Phase 2 path. Direct testing with schools and folder-trained staff is the first step of the build phase.

Results: Every artifact delivered. Two exceeded the brief.

• Full deliverable package: product requirements document, solution architecture overview, role-document access matrix, internal design review findings, and a SOW coverage checklist, each linked and cross-referenced.
• Prototype exceeded the brief: the engagement asked for lo-fi clickable wireframes. What shipped was a working eight-route application with persistent state, four personas with in-app role switching, and 23 document types seeded across the model.
• Access matrix in code: rather than a diagram on paper, the role-access matrix was implemented as working logic in the prototype, so the engineering lead could review it directly rather than translating from a document.
• Five stakeholders, one direction: every deferred item is named in the PRD with a rationale and an owner, so there’s no ambiguity about what’s in scope and what’s not.
• Success metrics framed before build: time-to-find, submission completion rate, and reliance on colleagues to locate files are defined as targets. Not yet measured, but established so engineering decisions have something concrete to work against.

The longer vision: The document layer is the foundation

The platform lead’s stated goal was that every client interaction happens through the platform, and the platform integrates with whatever operational tools the internal team uses. The document layer is the first shared core capability that makes that work: a single place where every file from every service module lives, regardless of which team produced it or which system originated it.

“The long-term goal is that every single client interaction occurs through the platform. Our teams would almost never engage with it directly — they’d work out of HubSpot, out of Zendesk. But everything they do gets communicated back to the client through the platform.”
— Platform Lead, April 2026

HubSpot and Zendesk as the operational layer

The client’s teams will work from HubSpot for service operations and Zendesk for support. The platform is the client-facing surface, not an internal tool. For the document layer, this means that a document produced through a HubSpot workflow or attached to a Zendesk ticket should land in the repository automatically, with its metadata derived from the context of the request that created it. The school finds it in the platform. The file is findable without anyone manually transferring it.

Phase 2 — what’s deferred and why

Each item below was scoped out deliberately so the v1 could focus on proving the core concept. Every deferral is documented in the PRD with a rationale, a temporary workaround where needed, and a clear owner.