Most good answers in UX start the same way. It depends.
Not because the person answering doesn’t know what they’re doing.
Not because they’re trying to dodge responsibility.
But because context matters more than rules.
This blog exists because I’m tired of pretending the work is clean.
A lot of design and technology writing lives in a world where requirements arrive fully formed, timelines are reasonable, stakeholders agree, and best practices magically settle debates.
That is not the world most of us work in.
Real work happens with partial information.
Under constraints.
With tradeoffs you don’t get to ignore.
You make decisions anyway.
It Depends is where I write about that reality.
Sometimes it will be UX. Sometimes it will be engineering, systems, leadership, process, or the small details that quietly make products better or worse. The common thread is simple: I care about building things that actually work for people when the conditions are real.
I’m not interested in universal frameworks or silver bullets. I’m interested in why a decision was made, what it cost, and what it unlocked. I care about what survives contact with users, deadlines, and legacy systems.
Good design is not how something looks in a presentation.
It’s how it behaves when things go wrong.
Good systems don’t eliminate complexity.
They make it easier to navigate.
If you build products, work with designers and developers, or spend time thinking about how tools shape behavior, you’ll probably recognize the patterns here. There are very few absolutes in this work, and pretending otherwise usually causes more harm than clarity.
So when the honest answer is uncomfortable, situational, or inconvenient, I’m going to say it anyway.
Because more often than not, the truth is the same.
It depends.