You’re a designer. A direction gets set in a meeting. You build exactly that. Not roughly, but the precise thing that was discussed. This feels responsible. It often isn’t.
You can’t fully think through a design in a room. The details that make or break it only surface when you’re actually in them. That direction was a starting point, not a finished answer. It rarely gets treated that way. Think of it as designing on rails the team laid.
When a PM hands you a sketch, the instinct is to judge it. Good or bad? Build it or push back? That’s the wrong question. The right one is: what problem is this trying to solve? They gave you a solution. You need to find what’s underneath it. That’s where you come in. You’ve spent thousands of hours thinking about how people move through interfaces. They spent those hours on something else. You should see something different than they do. That’s the whole point of working in a team with different skills.
One reason designers stay on the rail is safety. There’s something deeper, though. Most designers do notice problems and raise them. A sentence of doubt almost never changes direction. What changes direction is showing up with something better. Something the team can look at and immediately understand. That takes real work, and a kind of trust that builds slowly.
There’s also something subtler at play: accountability. If someone else had the idea and you executed it, the outcome is theirs. You’re off the hook. That sounds small, but the trade is that you stop shaping the product and start executing other people’s decisions. You’re not designing anymore.
What makes this hard to see is that it doesn’t look like a problem. The output matches what was discussed. Meeting notes and the design file line up. Everything looks correct. It’s just less than it could have been. The team never sees the version that wasn’t made, so there’s nothing to compare against.
Designers who earn real autonomy don’t just push back. Pushing back with half-formed alternatives can be worse than staying on the rail. The team has to evaluate something incomplete on top of everything else, and most won’t bother. The designers who go off-rail well show up with alternatives that already account for the goals, the constraints, the edge cases. If it’s clearly a better answer, people get on board. Not because they were persuaded, but because they can see it. Each time that happens, the next one gets a little easier. Trust builds.
Going off-rail isn’t going against your team. It means taking what they said seriously enough to keep going. Deeply understanding whatever you’re working on. Finding the why behind the ask. Mapping the full picture from your point of view. Coming back with what was discussed and what you think works better. That’s the job of a designer.