What I'm Actually Thinking While Designing

Most designers are thinking about layout and spacing while they work. I'm thinking about whether this scales to 100,000 users or breaks at 1,000.

That button everyone wants in the top right? I'm calculating support tickets. How many people will click it by accident. Whether we can even handle the load if it works too well. If this becomes the main path, does our infrastructure support it. Does our team.

I killed a feature last month that looked perfect. Would've crushed on Behance. But it required custom logic for every new customer. Didn't scale. Would've made us a services company pretending to be a product company. Nobody on the team saw it. They just saw me saying no to good work.

Here's what I'm actually thinking while designing:

Users aren't who you think they are. That persona doc is fiction. Real users are on their phone with 8% battery in an Uber trying to do one thing before the ride ends. They're not reading your carefully crafted microcopy. They're skimming for the button that looks clickable.

I'm designing for the user who doesn't read. Doesn't care about our clever information architecture. Won't watch the tutorial. Just wants to be done.

Growth means different things break. This flow works great for 10 users a day. What about 10,000? That manual approval step? Bottleneck. That personalized onboarding? Doesn't scale. That hand-holding we do in support? Can't hire fast enough.

I'm not designing for today. I'm designing for the system that needs to work when I'm not here to fix it. When support is overwhelmed. When engineering is shipping other features. When we can't manually handle edge cases anymore.

Impact isn't the same as usage. Everyone wants to build features people use. I want to build features that change behavior. That modal with 90% engagement? People are clicking through it, not reading it. That dashboard everyone opens? They're looking at one number and ignoring the rest.

Usage is a vanity metric. Impact is whether people do something different after using your product. Most designers confuse the two. Build interfaces optimized for screenshots instead of outcomes.

I'm thinking: does this actually move the metric that matters. Not "do people click it" but "does clicking it change anything." If we shipped this tomorrow and nobody used it, would we be worse off? If the answer is no, why are we building it.

Scalability isn't technical. Engineers worry about servers. I'm worried about decisions. Every custom option is a decision someone has to make. Every setting is cognitive load. Every branch in the flow is support debt.

That "give users control" feature? Sounds nice. Means every customer configures it differently. Means we can't optimize the experience. Means support is answering the same question a thousand different ways.

I'm designing systems that make decisions for users, not systems that ask users to decide. Opinionated products scale. Flexible products collapse under their own weight.

Value is what they'd pay for, not what they say they want. Users ask for features all day. Most of them are wrong. Not lying. Just bad at predicting what they'd actually use. They want customization until they have to customize. Want flexibility until they need to make choices. Want power features until they realize the simple thing worked fine.

I'm thinking about what problem we're actually solving. What job they hired us to do. Strip away what they asked for and ask why they asked. Usually the answer is simpler than the request.

Had a client demand a full admin dashboard. Spent three weeks on it. They used it twice. What they actually needed was one metric in an email every Monday. Took an hour to build. They're still using it two years later. That's value.

The best design decision is often not designing at all. Every screen I add is surface area to maintain. Every feature is a promise to support it. Every interaction is a chance to confuse someone.

I spend half my time talking teams out of building things. The feature that'll "only take a day" takes two weeks when you factor in testing, edge cases, documentation, support. And now it's ours forever.

I'm thinking: what's the lightest version of this that still works. Can we solve this with copy instead of code. Can we solve it with an email instead of a feature. Can we solve it by doing nothing and seeing if anyone actually complains.

Most problems go away if you wait a week. Most feature requests are just one loud customer. Most complexity is us trying to solve problems users learned to work around months ago.

The design other people see is the output. What I'm thinking about is the system behind it. Whether it compounds or collapses. Whether we're building leverage or burying ourselves in maintenance. Whether this makes the next thing easier or harder.

I'm not designing screens. I'm designing constraints that force the right behavior. Making it easier to do the right thing than the wrong thing. Building systems that work when nobody's watching.

That's what I'm thinking about. Not where the button goes.

Let's Work

Want to build something together? Get in touch at hi@0xdragoon.xyz