Designing for consequence
Why I’m Writing This
I want to share a core principle that shapes how I think about design, systems, and product decisions — especially the ones that don’t always feel obvious in the moment.
This isn’t a rule and it’s not a mandate. It’s just context.
I hope that this helps explain why I sometimes push on certain details or ask questions that might not seem critically important or worth collaborating on.
The Principle
Design for consequence, not just appearance.
At a glance, design is about how things look and feel.
At scale, design is about what decisions cause.
Scalability serves as a compass for anyone attempting to create a system that creates product coherence, avoids debt while it evolves to meet new user needs, and increases our velocity. It reminds me to think beyond the surface and toward the downstream effects of what we ship.
Basically, don’t be this guy.
What I Mean by “Consequence”
By consequence, I don’t mean failure or blame.
I mean outcomes over time.
What happens when this pattern is reused 100 times?
What burden does this place on engineers six months from now?
What assumptions are we locking into the system?
What tradeoffs are we making invisible?
Every design decision creates momentum.
Some momentum compounds into clarity and speed.
Some compounds into friction and debt.
Designing for consequence means caring about which direction we’re pushing.
Why This Shows Up in My Work
You may notice that I often:
Obsess about alignment between design and code
Stress the importance of the feedback loop between a product designer and FE engineer
Ask how a component scales, not just how it looks
Push for constraints instead of flexibility
Get uneasy with one-off exceptions
Frequently re-iterate that the design system is never truly done
That’s not because I’m allergic to creativity or speed or critique or finishing this damn thing.
“It’s not because I’m allergic to creativity or speed or critique or finishing this damn thing.”
It’s because I’ve seen what happens when good intentions quietly turn into brittle systems — and how hard it is to unwind those decisions later.
This principle is about protecting future velocity, not slowing us down today.
Design, Engineering, and Reality
I don’t see design and engineering as opposing forces.
I see them as partners negotiating with reality.
Design expresses intent.
Engineering reveals constraints.
Systems tell us what’s sustainable.
When constraints surface, that’s not failure — that’s information.
Designing for consequence means listening when the system talks back and adjusting intent accordingly.
That’s how products mature instead of fracturing.
What This Is Not
This principle is not:
Perfectionism
Over-design
Avoiding risk
Winning debates
Making things rigid for the sake of control
It is:
Being intentional
Making tradeoffs explicit
Reducing hidden complexity
Designing things we’re proud to maintain
Leaving the system better than we found it
Why I’m Sharing This Now
As our products, teams, and systems grow, the cost of small decisions increases.
I want us to have a shared language for why some decisions matter more than they appear — and why it’s sometimes worth pausing to get them right.
If you ever wonder where I’m coming from in a discussion, this principle is probably nearby.
Please, always ask for further discussion. I need questions to understand what needs clarification. I can talk about this for hours. Keep asking questions until we both understand.
In One Sentence
Designing for consequence means caring not just about what we ship, but about what that decision creates over time.
If this resonates, great.
If you disagree, I’d love to talk about it.
Either way, this is how I see things now — and I wanted to be explicit about that.
If you’re an engineer reading this, this is an invitation to tell me constraints, help me identify similar, duplicitous patterns throughout the application, and to share important technical information or requirements that I’m not privy to like you are.
A design system is an engineering resource at the end of the day.
