Designing a proposal experience that helps faculty move through complex institutional requirements without needing to understand the machinery behind them.
Case study thesis: Creating or changing a course looked like a form-filling problem. In reality, it was two connected design problems: administrators had to configure reusable approval processes, while faculty—who might rarely use the product—had to navigate long, complex proposals successfully.
The problem
Managing course proposals was a headache on both sides of the experience.
Before a faculty member could submit anything, an administrator first had to create a reusable approval process: a large form paired with a workflow that determined who needed to participate, when they were pulled into the process, and what happened next.
Then faculty had to actually complete those proposals—often through very long forms, despite being users who might only enter the product occasionally.
That created a difficult design tension: the system needed to support institutional complexity without making every user experience feel complex.
01 — Two very different users
The experience had to work for people with fundamentally different relationships to the product.
Administrators | Faculty |
Configure reusable forms and approval processes | Create or modify a course through an existing process |
Need flexibility, control, conditions, routing, and governance | Need clarity, guidance, progress, and confidence |
Frequent power users | Often infrequent users with little reason to learn the system |
Design challenge: Give administrators the flexibility to model a complex institutional process without passing that complexity on to faculty.
02 — Making complexity configurable
Administrators needed significant flexibility, but flexibility didn't have to mean starting from scratch.
We structured setup as a guided process: first define what kind of approval process is being created, then configure the information it needs to collect, and finally define how that request moves through the institution.
For course proposals, the system could provide the underlying course data automatically. Admins then focused on what was unique to their institution—adding information everyone needed to provide, revealing additional questions only when relevant, and connecting the form to an approval workflow.
The goal was to make complexity configurable rather than repetitive.
Start with intent: define the approval process and let the system establish the appropriate base structure.
Build on existing course data with always-shown and conditional sections instead of recreating an enormous form from scratch.
Configure automated and manual review steps, conditional routing, and validation while keeping the overall process visible.
03 — Designing for the occasional user
Faculty presented a very different design problem. Many would only create a proposal occasionally, which meant we couldn't rely on familiarity with the product—or with the approval process itself.
Instead of exposing the structure administrators had configured, we translated it into a guided task. The experience tells faculty what to do now, what comes next, and what information is required based on the proposal they're creating.
For a course revision, that meant selecting the appropriate process, identifying the course being changed, completing the relevant sections of the form, and reviewing everything before submission.
The complexity still exists. The user just doesn't have to carry it.
Start with the user's intent rather than asking them to understand the underlying workflow.
For a revision, guide the user directly to the course that becomes the basis of the proposal.
Break a potentially long proposal into understandable sections while keeping progress and context visible.
Give the user a final summary and readiness check before the proposal enters the approval workflow.
04 — One system, two experiences
The administrative and faculty experiences were intentionally different views of the same system.
Administrators needed to think in terms of reusable forms, conditions, participants, and routing. Faculty needed to think in terms of a task: What am I proposing, what information do I need to provide, and what do I do next?
The configuration work done by an administrator determined what faculty saw, but the faculty experience didn't expose the machinery behind it.
Admins configure the complexity. Faculty experience the guidance.
05 — The result
The final experience connected a flexible administrative system with a guided proposal flow.
Administrators could define reusable processes that reflected how their institution actually worked. Faculty could enter those processes without needing to learn the logic underneath them, while reviewers and administrators could see proposals, status, and where each request sat in the process.
Once submitted, proposals return to a shared workspace where users can see status, current step, department, and items requiring action.
Complex enough to model the institution. Simple enough to use without becoming an expert in the software.
Portfolio takeaway
This project pushed the design in two directions at once: building powerful tools for the people configuring the system while protecting occasional users from the complexity underneath it.