FairLend is a human-centered lending dashboard. It redesigns the one moment that matters most: when a loan officer decides to accept or challenge a biased AI recommendation. The whole interface is built for accountability instead of speed.
Lending models are trained on historical data that carries decades of documented discrimination: redlining, and the systematic exclusion of Black and marginalized communities from capital. The model doesn't learn to be fair. It learns to repeat what's in its training data. Inputs like zip code and debt-to-income correlate with race through that same history, so the model can produce discriminatory outcomes without ever naming a protected characteristic. That mechanism has a name: proxy discrimination.
There's a second problem stacked on top of it: automation bias. People tend to defer to an algorithm without stopping to question it, and they're less likely to see an algorithmic decision as biased than they would an identical human one. So the interface layer, the one place a person could actually catch a biased outcome, is usually where it slips through instead. That's a real, and mostly unaddressed, institutional risk.
How can a dashboard use cognitive forcing functions to help loan officers truly evaluate an algorithmic recommendation, and lean less on AI outputs that may be biased?
My first hypothesis was that transparency would fix this. Show officers why the AI recommended what it did, I figured, and they'd evaluate it more carefully. A 20-source literature review told me the opposite: explainable AI doesn't reduce overreliance, and it can make it worse. A convincing explanation gives someone more reason to go along with the AI, not more reason to push back.
So I dropped it and rebuilt the project around cognitive forcing functions: design that makes you stop and think before you act. Following the evidence meant throwing out my most intuitive idea. To me, that's the difference between decorating a conclusion and actually solving a problem.
Each step puts one specific, research-backed intervention to work. The officer can't skip ahead, and that's the whole point: the enforced order is what makes the forcing functions do their job.
The officer records their own preliminary read, in writing, before anything from the AI appears. This tackles anchoring: when the AI verdict comes first, people drift toward it instead of forming their own view. Committing to a position first gives them a real reference point to measure against.
Now the score appears, inside a zone system that frames it as something to weigh rather than obey. The officer then writes out where they agree with the AI and where they don't. Putting it into words takes more real thought than simply reading it does.
The system raises two possible bias flags: zip code as a stand-in for racial composition, and debt-to-income as a possible stand-in for the gender wage gap. The officer has to acknowledge both before moving on. The flags don't change the score; they change what the officer understands about what drove it. That's informed accountability.
The officer makes the call and writes out the full reasoning behind it. That creates a permanent compliance record: their independent read, their response to the AI, the bias flags they acknowledged, and the final rationale. Standard dashboards capture none of this.
These are design intent, not results I'm claiming. I designed the usability study but didn't have time to run it this semester.
What I delivered is a fully interactive prototype where every design decision traces back to a specific finding in the research. It reframes AI overreliance: not an unsolvable data problem, but an interface-design problem you can actually address. The delayed reveal handles anchoring; prompted reflection handles the limits of passive explanation; the friction gate handles proxy discrimination; the accountability record closes the compliance gap. Nothing in the design is there just to look good.
What I'd do differently: plan the timeline to protect a full usability study. The dashboard is strong in theory, but I haven't validated it with real users yet. Testing it with actual lending professionals is the clear next step, and I wrote the study methodology so it can be picked up and run as-is.