Apologies -- I'm going to say "I" a lot because I can only speak from my experience. Take "I" as a qualifier rather than the opposite.
Whenever I'm on a team that's really having trouble getting our arms around a problem, I draw sequence diagrams (http://websequencediagrams.com ROCK -- is it OK to mention them?). That defines the service interactions or the class interactions.
Coincidentally, the service interactions will define directly the API calls to implement, if I'm showing interactions between services. Or methods to implement if it shows interactions between classes.
(A lot of the data requirements also come out of that, but I have to admit that for brevity's sake I'm pretty good about capturing methods but not so good at the parameters.)
10 years ago, I used a UML modelling tool that would generate Java from the class diagram, so I would, in fact, generate a UML diagram up front. Well, at least at the same time I was writing the classes.
Since then, I very rarely do any UML diagrams besides sequence diagrams. Sometimes a straightforward entity-relationship diagram is useful if, again, the model is getting confusing.
EDIT: Actually, I draw state diagrams a lot. So state diagrams and sequence diagrams can be really helpful. I used to draw UML activity diagrams, too, but the sequence diagrams just kind of won out. Still, that defines the high-water mark. No else on the team is doing that level of diagramming.
It can be helpful to go the other way: run a tool that generates a class diagram from the classes. Whenever I do that, I always find modelling errors to fix. But that's just me. ;)
EDIT EDIT: BTW whipping out a nice sequence diagram in an interview can have big wow value. Even with non-technical interviewers. Just sayin'