Early in my career I measured my week by how much I’d drawn. A good week produced screens. A bad week was full of meetings and ended with a document nobody had asked for.
At some point that measure stopped working, and I didn’t notice straight away. My decisions started outliving the files I made them in. I still make screens, and I like making them. But the decision was happening before I opened the file, and the screen was just writing it down. The interesting failures had moved upstream of the drawing. I’m curious whether that matches your experience, or whether it’s just the kind of work I do.
To be clear, I don’t mean the old line about senior designers graduating out of design into management. Most of the seniors I respect are still deep in the craft. What I mean is that the risk sits earlier in the process now.
The expensive mistakes happen before anyone opens a design tool
A beautifully executed screen for the wrong problem does more damage than a rough screen for the right one, because it’s more convincing. Craft makes a proposal harder to argue with, and that only helps when the proposal is right.
Think about the mistakes that actually cost your team last year. For mine, they were never visual. We solved a problem only one loud stakeholder had. We built a flow around a process the company changed a quarter later. We served a rare case by making the primary case slightly worse for everyone. We shipped something correct that nobody could operate, because no one had asked who would maintain the content behind it.
Typography was never going to catch any of those. Harder questions before the drawing started would have, if I’d been willing to be slightly irritating for about a week.
So here’s my unglamorous list of questions, the ones that earned their place. Who has this problem, and how do we know? What happens today, without us? What does this person do right before this screen, and right after? Who maintains it once it ships? And the last one, my favourite: what would have to be true for this to be the wrong thing to build?
That last question is deeply unpopular, and I think that’s exactly why it’s useful. Ask a team to describe the conditions under which their idea fails and within a minute you know whether anyone has thought about it.
Constraints are the material
There’s a school of design thinking that treats constraints as interference. Business rules, technical limits, legal requirements, data that doesn’t exist yet. In that framing, the dream project is the one where nobody interferes and you get to solve the problem cleanly.
I’ve had those dream projects. Have you? To be honest, the output was worse for me. Almost every time.
Constraints are where the true shape of the problem lives. A legal requirement that a disclosure appears before a certain action is a fact about what the flow is. Dig into why the requirement exists and you usually surface something about the domain that changes the design more than a month of unconstrained sketching would.
Technical limits work the same way. A designer who understands why a certain query is slow designs around it, and the result feels intentional. A designer who doesn’t will hand over something that gets built badly or never, and will probably file the whole experience under “engineering is difficult”.
So my practical rule is this: before designing against a constraint, go and find out why it exists. Roughly a third of the time it turns out to be a habit nobody questioned, and it dissolves the moment you ask. Another third, it’s real, and understanding it improves the design. The last third, it’s real and immovable, and you’ve just saved yourself two weeks.
Saying no needs a replacement attached
The most common weakness I see in otherwise strong designers is declining work in a way that damages the relationship.
A flat no just gets you routed around. The next request skips you and goes straight to engineering, and now you’re out of the conversation entirely.
What works, at least for me, is being specific about the trade and offering the nearest buildable thing. Something like: we can add that, and it’ll push the primary action below the fold on the screen where most people land, which I expect costs more than the feature gains. If the real need is that people can’t find their history, there’s a cheaper fix. Which problem are we solving?
It takes longer to say. But it moves the conversation from taste to consequence, and that’s a conversation people actually want to have. Nobody wants to argue aesthetics with a designer. State the trade-off in terms of their goals and suddenly everyone has an opinion worth hearing.
And when you turn out to be wrong, which happens to me regularly, change your position fast. Updating quickly when someone shows you something you didn’t know buys you a lot of credibility for the times you do hold your ground.
Writing is most of the job
Nobody told me this at the start. I’d probably have resented them if they had.
An interface is mostly language. Labels, empty states, error messages, confirmations, the one sentence explaining what’s about to happen. People read far more words inside your product than they’ll ever read in your marketing. And those words usually get written last, by whoever is free, under deadline.
I flipped that order years ago. Now the key sentences come before the layout on anything that matters. If I can’t write one short, clear sentence saying what a screen does, the screen doesn’t have a clear purpose yet, and no layout is going to give it one. Several designs died at that stage, cheaply, when the sentence exposed a muddled concept. I count each of those as money saved.
The other kind of writing is the argument itself. Undocumented decisions get relitigated every few months by people who weren’t in the room, and you tend to lose those rematches, because your memory of the reasoning has faded and their enthusiasm is fresh. A short record of what was decided, what was considered, and why pays back for years. It also lets the decision survive when you’re not there.
What still requires drawing
I want to be careful not to oversell any of this. There’s a whole genre of writing that reduces senior design to stakeholder management, and I think it’s wrong.
Craft still decides the outcome on anything people touch often. The difference between an interface that feels comfortable at the four hundredth use and one that’s merely acceptable lives entirely in details, and details don’t survive being described in a document. They have to be made, tried and adjusted on a real screen with real content in it.
What changed for me is the order. The drawing now serves a decision I’ve already reasoned through, instead of being the place where I hope reasoning will emerge. Drawing to think is still legitimate, and I still do it. These days it’s a choice, though. It used to be my only method.
The new measure
I stopped judging my week by output. The question I ask now is whether the decisions in it were made with the information that was available, and whether I could read the reasoning out loud to the person it affects.
That sounds softer than counting screens. I don’t think it is. I could always hit a screen count by staying late, and there’s no staying late your way out of this one. How do you measure your own week? If you’ve found something better, I’d like to hear it.
