The best approach I've found to estimation based on hourly rate is to always give ranges, even for the smallest tasks, and to not be afraid of giving very wide ranges when appropriate (which is frequently). The low end of the range should be your actual best guess estimate, what you would allot if you didn't use a range. The high end is a worst case scenario that should reflect the complexity of the task and the potential for unforeseen obstacles. "2-8" hours is a perfectly valid range for a task.
This serves a few purposes.
1.) It trains the client to think about the project in a way that is actually consistent with the process of building software.
2.) It lets the client psychologically attach themselves to the low end, the best case scenario, which can be helpful for getting the estimate approved, but doesn't give them grounds to feel that you missed the estimate when reality sets in and things take longer.
3.) It lets developers create estimates much faster, because they don't have to pin themselves to a single (likely to be over-optimistic) number.
This serves a few purposes.
1.) It trains the client to think about the project in a way that is actually consistent with the process of building software.
2.) It lets the client psychologically attach themselves to the low end, the best case scenario, which can be helpful for getting the estimate approved, but doesn't give them grounds to feel that you missed the estimate when reality sets in and things take longer.
3.) It lets developers create estimates much faster, because they don't have to pin themselves to a single (likely to be over-optimistic) number.