Designing With a Restraint Budget
A greyscale visual system with semantic color reserved strictly for status. One constraint that did more for coherence than any palette.
Blog
Thoughts on UX design, product development, design systems, and building things that work.
A greyscale visual system with semantic color reserved strictly for status. One constraint that did more for coherence than any palette.
The real test of a design system is not launch day. It is whether the work keeps running after you leave. That is a goal you design toward, not a lucky outcome.
It took five attempts to get dark mode right on my own portfolio. Here is what each failure taught me about base colors, elevation, and why the ground matters more than the surfaces.
Regulatory requirements and hardware limitations are not obstacles to work around. Read them correctly and they tell you exactly what the product has to do.
I am good at the work and still find interviews hard. The answer was not to wait for confidence. It was to build a practice system that made the performance part smaller.
Hardware latency you can't remove is still a design material. The craft move is converting a wait into something that reads as feedback.
Ban blur, gradients, and opacity from a design system and something unexpected happens: the decisions get harder, and the results get more honest.
When two user groups share one system, a feature does not carry one meaning. Designing for both requires holding two opposed readings of the same screen at once.
Every application is a small research project. Here is what changes when you treat it that way.
When a team deadlocks on an interaction model, arguing harder just hardens positions. Build both options and let the evidence end the debate before it becomes a conflict.
A senior product designer role and a design-engineer role may both fit you. They are not the same reader.
The instinct to lay a solid foundation before drawing a single screen is backwards. Building the system alongside the screens is what makes both finish on time.
Walking a panel through your process is a list. Framing the same work around a decision is a narrative. The difference is where interviewers look for judgment.
Feature count debates miss the point. When your users are vulnerable, every added setting is a new failure mode, and cutting scope becomes a form of harm reduction.
When your AI assistant agrees with everything you say, including the things you get wrong, you have a compliance problem. Here is how I fixed it with hooks, rules, and adversarial agents.
When your interface lives on two devices, the user can only look at one. Sound, haptics, and invisible latency absorption become your real design tools.
I have ADHD. Most learning tools ignore that. So I built one that doesn't.
Node graphs demo beautifully with 5 nodes. At 15 they become unreadable. The problem is topology, not tooling.
The right prototyping tool depends on the question you're trying to answer, not the phase you're in. Sometimes paper beats Figma and code beats both.
Most workshops produce sticky notes and good vibes. A few produce one insight that reframes everything. The difference is the setup, not the activities.
Want to know when new posts go live?
Follow on LinkedIn