Problem
A month-allocation interface was trying to answer several different questions at once.
The apparent problem concerned a calendar and the month to which income should belong. But “belongs to this month” was doing too much work: describing when money arrived, when it was expected, and which month’s budget it should support.
Changing the interface alone would leave those meanings collapsed. The domain model needed to distinguish them before the workflow could become clear.
Constraints
Planning convenience cannot change financial reality.
- Expected income must not create cash or ledger rows.
- Receipt date and budget-month support must remain independent.
- Actual income should supersede an estimate when appropriate, without double-counting.
- Planning and funding are related but distinct.
- Historical integrity must be preserved when a plan changes.
Analysis
Four concepts. Four different responsibilities.
Collapsed model
- A month implies both receipt and support
- An expectation risks behaving like cash
- A planning change risks rewriting history
Separated model
- Transaction date records when it happened
- Actual and expected income stay distinct
- Budget-month support expresses planning intent
Transaction date anchors an event in time. Actual income represents money received. Expected income represents an estimate. Budget-month support answers which month’s plan the money is intended to support. Funding then asks whether actual money is available to back the plan.
System Model
Reality, expectation, planning intent, and funding are separate layers.
- 01Reality
- What happenedActual income + transaction date
- 02Expectation
- What may happenAn estimate, never cash
- 03Planning intent
- Which month it supportsIndependent of receipt date
- 04Funding
- What backs the planActual money available
Related concepts ≠ interchangeable concepts
- Reality
- What happened? Record actual income with its transaction date.
- Expectation
- What do I think will happen? Keep the estimate separate from cash and the Ledger.
- Planning intent
- Which month’s plan should this support? Make that choice independent of receipt date.
- Funding
- What actual money backs the plan? An expectation alone cannot supply it.
Solution
Define the behavior before deciding how the interface should express it.
The redesign centers on explicit relationships between the concepts. Expected income informs planning without creating financial records. A real receipt establishes actual income. Where appropriate, the actual amount supersedes its estimate instead of being added to it. Budget-month support can express intent without rewriting the receipt date.
- An expectation is added
- The plan can consider it. Cash and ledger rows do not change.
- Actual income arrives
- Use the actual amount and supersede the relevant estimate when appropriate. Do not count both.
- Budget-month support changes
- Change the planning relationship. Preserve the original transaction date and historical record.
Validation
Make the requirements testable at the boundaries.
The model’s acceptance criteria define the required behavior at four boundaries: cash creation, reconciliation with an estimate, month support, and historical integrity.
- Expected income exists; no money has arrived
- No new cash and no ledger row exist because of the expectation.
- A receipt fulfills an expectation
- The actual amount supersedes the applicable estimate without double-counting.
- Receipt month differs from support month
- The model preserves both facts independently.
- A planning choice is revised
- Historical income remains intact, and funding is still based on actual money.
Outcome
A clearer model makes the next design decision less ambiguous.
The analysis reframed a calendar UX issue as a domain-modeling problem. The resulting model gives requirements, interface decisions, and validation a shared vocabulary: what happened, what is expected, which plan the money supports, and what actually funds that plan.