Early in my career I measured my week by how much I had drawn. A good week produced screens. A bad week was full of meetings and produced a document nobody asked for.
That measure quietly stopped working once my decisions started outliving the files I made them in. I still make screens. I like making screens. But at some point the decision started happening before I opened the file, and the screen just wrote it down. All the interesting failures moved upstream of the drawing.
To be clear, I do not mean the old line about senior designers graduating out of design into management. Most seniors I respect are still deep in the craft. The risk just 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 is more convincing. Craft makes a proposal harder to argue with, which is great right up until the proposal is wrong.
Think about the mistakes that actually cost your team last year. For mine, they were never visual. Solving a problem only one loud stakeholder had. Building a flow around a process the company changed a quarter later. Serving a rare case by making the primary case slightly worse for everyone. Shipping something correct that nobody could operate, because no one asked who would maintain the content behind it.
Typography was never going to catch any of these. Harder questions before the drawing started would have, if I had been willing to be slightly irritating for about a week.
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, which is exactly its value. Ask a team to describe the conditions under which their idea fails and you find out within a minute whether anyone has thought about it.
Constraints are the material
There is a school of design thinking that treats constraints as interference. Business rules, technical limits, legal requirements, data that does not exist yet. In that framing, the dream project is the one where nobody interferes and you solve the problem cleanly.
I have had those dream projects. The output was worse. 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 does not will hand over something that gets built badly or never, and will file the experience under “engineering is difficult”.
So my practical rule: before designing against a constraint, go 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 is real, and understanding it improves the design. The last third, it is real and immovable, and you 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 are out of the conversation entirely.
What works is being specific about the trade and offering the nearest buildable thing. Something like: we can add that, and it will 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 cannot find their history, there is a cheaper fix. Which problem are we solving?
It takes longer to say, but it moves the conversation from taste to consequence. Nobody wants to argue aesthetics with a designer, but 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 did not know buys enormous credibility for the times you hold your ground.
Writing is most of the job
Nobody told me this at the start. I would have resented them if they had.
An interface is mostly language. Labels, empty states, error messages, confirmations, the one sentence explaining what is about to happen. Users read far more words inside your product than they will 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 cannot write one short clear sentence saying what a screen does, the screen has no clear purpose yet, and no layout will 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 were not in the room, and you 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 your absence.
What still requires drawing
I want to be careful not to oversell any of this. There is a whole genre of writing that reduces senior design to stakeholder management, and it is 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 is merely acceptable lives entirely in details, and details do not survive being described in a document. They have to be made, tried, and adjusted on a real screen with real content in it.
The change is in the order. The drawing now serves a decision I have already reasoned through, instead of being the place I hope reasoning will emerge. Drawing to think is still legitimate, and I still do it. These days it is a choice, though. It used to be my only method.
The new measure
I stopped judging my week by output. The question 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. It is not. I could always hit a screen count by staying late, and there is no staying late your way out of this one.
