When you're doing it 'right', at some point early in the modeling process you check to see whether an LTI assumption will be valid and over what sorts of operating ranges. Then you decide whether you can blithely treat the system as linear, if you can decorate the controller with a few easy nonlinearities (like anti-windup in the integrator) and _otherwise_ treat the system as linear, or if you _really_ have to delve into the nonlinear control bag-o-tricks to make things work.
Sometimes (often, when you're dealing with an unfamiliar system or really trying to wring performance out of it) you have to do some design, remeasure, redesign cycles before you get it right*. This can take the form of tweaking if you're close to your goal, but too much undirected tweaking can lead you off into the pucker brush of control design land, where the only path to success lies in getting airlifted back to your starting place and redoing the process _correctly_.
My day job often involves coming in at the point where people realize that they're off in the pucker brush and don't _know_ how to do the design right. Often I can't get their system whipped entirely into shape, because often the problem is that the plant or processor is somehow deficient to the task at hand**, but I have _always_ been able to get significantly improved performance.
- It's like peeling an onion -- you peel off a layer of the problem and cry as you do it. Then you notice that the problem is still too big, so you peel off another layer and cry. You repeat as necessary until you have enough money saved up to start a basket-weaving supply house, or until the problem is solved, whichever comes first.