Lerping Issue

I've implemented the lerping method to smoothly transition the position of a transform from one position to another, to have that "decelerating" effect.

From my understanding, the way this is accomplished is by moving a certain percentage (the "t" parameter) of the distance between the two positions on every update, then updating the initial position (the "a" parameter) to the position moved to, and repeating. This way, on every update, the transform moves closer to its final position by a smaller amount, the "speed" of movement appears to be decreasing, and thus the smooth decelerating effect.

I have an object that calls a coroutine that carries out this transition up into my view. Immediately after the subroutine call, the script checks for input. If a there is user input, a 2nd function is called on every update to carry that same object downwards out of the scene at a certain speed.

Here's my problem: If the user inputs before the coroutine finishes executing, and enables the 2nd function, then the coroutine never finishes executing. This is because the coroutine is applying a upwards, positive speed and the 2nd function is applying a downwards, negative speed, so the object becomes stationary. This is not what I want.

Now, I could wait until the coroutine finishes before checking for user input, BUT, because of the method I'm using (described in the second paragraph), there's a point in time where the transform appears to have reached its destination, or is close enough for the user to have understood its use and attempted to interact with it, but is actually still lerping; still moving by some very small amount. At this point the user would probably want to interact with the game, but wouldn't be able to if the game is waiting for the subroutine to finish. This is the case even if I stop the lerping when the distance between the transform's position and the final position is a very tiny amount; the deceleration time isn't predictable in this way.

So, a potential solution I found is to use lerp based on a sine function, as this could provide that same decelerating effect. The problem with this is that a call to the sine function is more expensive than just using a fixed value for the t parameter of the lerp... I'm not sure how much more expensive, but it's definitely more predictable.

Is there any other solution to this? Is this method of lerping just not appropriate for these kinds of UI dependent transitions? Thank you!