No, no – just that, normally, the "UI’ isn’t really part of “game control” (because it comes from a game controller, or keyboard/mouse axes.)
If your rowing mechanic is similar to something like a golf swing mechanic in a typical golf game, then it makes sense that the UI is involved in generating the rowing input.
There are two ways of implementing this. One is that the UI widget is the “driver” of the mechanic, does the timing and threshold detection, and forwards its information to the player controller. (You typically want the UI to have a property of which player controller it affects, and hook that up when you create the UI widget and adds it to the player screen.)
The other is to have the “phase” and “speed” and “trigger” bits to actually be animated inside the player controller, and have the UI simply be a mostly reactive display-er of the state of that input state machine.
There’s not a huge difference between these two options, so either way can probably work fine. Personally, I find that the more reactive and display-only I make my UI, and the less state and decision making is in the UI, the fewer bugs and design challenges I run into, but that’s likely more of a personal style thing than a hard-and-fast rule.