Dealing with complexity: the Opus Project

Scoping, strategy, and stakeholder alignment on a system that grew bigger than anyone expected

A long task flow diagram showing the faculty review process.

The challenge

The assignment looked simple: replace a paper-based faculty review system with a digital one, without changing any existing processes or policies. The requirements fit on a single page. But as any experienced UX practitioner knows, what fits on a page rarely captures what hides beneath it.

As we dug deeper, a kind of design quantum physics took over. The system changed every time we looked at it. Each layer revealed another beneath it. What started as a simple charge became a complex workflow spanning multiple user groups, committee structures, and institutional policies. We started behind the starting line. There was far more behind the curtain than anyone, including our sponsors realized.

To surface the full scope of the problem, we mapped the entire faculty review workflow as a task flow. We accounted for every role, every handoff, and every decision point. The resulting diagram was enormously long, but that was information in iteself.

When we showed stakeholders this diagram, they understood the complexity immediately in a way that pages of documentation hadn't been able to. Humans are storytelling, visual animals. Seeing the full scope of what they'd been asking us to build made the conversation about tradeoffs much easier to have.

With budget and timeline fixed, we had to make deliberate decisions about what to build and what to defer. For example, a voting system and automatic committee builder were desirable, but showing sponsors the time and engineering cost of those features led everyone to the same conclusion: a simpler, phased approach would serve users better in the short term. A simple Departmental voting tally saved hundreds of hours of coding a voting system.

From this… a complicated task flow

To this… a very simple voting tally.

What I learned

  1. Observation changes the system. The act of mapping requirements in detail revealed complexity that no one knew existed. Budget for discovery — it always pays off.

  2. Show, don't tell. A task flow diagram communicated the problem more effectively than weeks of written requirements. Diagrams earn alignment faster than documents.

  3. Scope cuts are design decisions. Knowing what to cut is as important as knowing what to build. Protect your users from complexity by absorbing it yourself.

This project shaped how I think about every complex initiative I've led since. The instinct to simplify is right. But you have to earn simplicity by first understanding the full scope of the problem.

Previous
Previous

Building an identity system for a university-wide WordPress rollout

Next
Next

Turn Intention Into Action