One option is the format recommended in Alistair Cockburn's Writing Effective Use Cases:
2a- User wants to do another thing:
2a1- The user does another thing
2a2- The system responds in some way, returns to step 3
Step 2a occurs after step 2 and before step 3. If the UC ends at step 2a2 then simply replace 'returns to step 3' with 'Use Case ends' or similar.
When you are introducing someone new to your programming environment they need to understand the business problems as opposed to the technical. For the feature set under consideration, you need to identify the expected success paths and minimize the failure space before handing off to them. By this I mean clearly documenting how a particular piece of functionality is expected to behave and also what should happen when something is done incorrectly (e.g. bad data such as a string when a number's expected, clicking submit multiple times on a web-app, etc...). It's identifying and documenting how to deal with the failures that really take the most effort.
Then assuming a human facing piece of functionality, lead with user interface designs (e.g. wireframes) and written use cases. If this functionality is meant to exist in, or integrate with, another system UML diagrams are useful to show that interaction. At this point, are you hiring a glorified typist or someone who can think? If the former, then really get into the weeds and UML out the class hierarchy.
This is a somewhat deep question, so I am hesitant to give a short answer. It is a good idea to read a few good books that describe different approaches, such as The Inmates Are Running the Asylum, which describes scenario-based function design. Another approach is to use high-level use-cases, as described in Writing Effective Use Cases.