That's the approach you should take to communicating with UML: legible over pretty, and standard over creative. Put in as much effort and as much customization as needed to get your point across; put in no effort on unnecessary prettification, and customize only when the standard notation fails to communicate efficiently. If you're drawing diagrams by hand, make the lines and shapes as straight and regular as you can, but don't break out the ruler and compass and protractor. (Fine-ruled graph paper helps a lot, though.) If you're drawing diagrams with a UML tool, stick to the easier features of the tool, and only use more esoteric features when necessary.

There's a place for pretty, just as there's a place for formal, ritualized speech. In fact, the places are the same: any occasion of ceremony, of transition. You can and should apply extra polish to diagrams that are to be presented in large, ceremonial settings (sign-off meetings, executive presentations, etc.), because it demonstrates attention to detail that will give participants confidence. No, strike that, they won't notice the detail; rather, if you don't apply the polish, they will notice the unpolished details, and their confidence will be shaken.

But in your day-to-day work, you should do exactly what I do in my day-to-day work: I get the diagram to the point where I think it makes sense; and then I hand it to someone else and ask if it actually does.

Maybe Even Ugly?

In case you haven't noticed by now, I see the primary value of UML in its role as a communication tool. But in Agile Modeling, Scott Ambler describes another value of UML. He talks of "modeling to communicate" vs. "modeling to understand". The latter is another perspective on the Outline Effect that I describe in my UML classes: a way of understanding a problem by building a model of the problem, or even of understanding existing code by building a model of it. This is certainly a valuable use for UML; but when you're modeling to understand, you may go even farther in the direction of legible vs. pretty. In fact, you may very well produce some pretty ugly diagrams.

Don't let this worry you, and don't let it slow you down. When you're trying to understand something, "cleaning up" diagrams will only distract you. If you can read it, it's good enough. Move on. Keep the momentum going. Making sense of a new problem domain is hard work. Making sense of existing code is even harder. Comprehension is hard, and neatness isn't always necessary for it. You can always clean up later, when your brain goes into idle and you're just going through the motions. I've spent many hours rearranging diagrams to make them more legible, while simultaneously listening to the TV or even taking part in a conversation. I don't want to imply that legibility is easy; but it doesn't take the same sort of intense concentration that's required for comprehension.