Documentation
Process Flow Diagrams, Mind Maps, Specs and Redlines
Personas
A persona helps us get into the mind of the user and we use them all the time as designers. 
Why use them?
Personas help build empathy documenting a customer's feelings, decision making process, and their motivation for doing what they do.  A persona helps communicate and form a common understanding of our customer company wide and helps a designer focus on the needs of the user.

I often spend a lot of time educating the team on the importance of personas because without them, we haven't validated that our customers are who we think they are.  Adoption of personas from the top down is also important because if the company doesn't see the value, no one will.  Last but not least, personas need to be used and they need to be kept current.  Customers change over time and by doing a review at least once a year, errors are caught and value is preserved.

Mind maps and Process flow diagrams (PFDs)
I usually always start with a mind map.  I like to get all the ideas out of my head because if they stay in there for too long, they never escape.  From that, we can logically group ideas into functional areas and we can then start looking at those groups as part of a process.
Mind maps rock!
When I'm leading design thinking brainstorming sessions, I always tell people to write down everything that comes to mind no matter how outlandish the idea is.  Mind maps are perfect for these exercises because it's a quick free form way to document stuff you'll forget quickly.

Once a mind map is done, it's easy to organize them into buckets to help identify similar ideas.  What I find is that larger groups of similar ideas tend to be great starting points for further discussion. 
PFDs
When it comes to producing well written documentation, I try to work closely with the product owners to help fine tune process flows for their feature.

Process flow diagrams give a lot of insight into how different parts of the application interact with one another and also help identify dependencies you might otherwise miss.  

Developers also find these quite useful because it helps them identify and design the logic behind the feature.

These diagrams are also useful for showing very high level flow of the feature or they can be very detailed down to the back end interactions.
It's all in the details
Being able to know how much detail to put into a a mockup or specs is critical to getting stuff done.  When the team has a component library, there's no real need to go with full fidelity mockups to describe a new dialog or what the UI would look like with a new dropdown.

Other times, it's important to go into quite a bit of detail.  For example, the component work I've done include detailed interaction specs along with pixel perfect redlines.
Redlines
Redlines are must haves when delivering new UI to a developer or when creating a style guide and component library.  I wont be going into design systems here but if you'd like to see more detail in how I define the system or how I go about ensuring accessibility, send me a note!
Redlines are red!
Well, they don't really have to be but it makes more sense when they are! 

Depending on the team I'm working with and the expertise of the developers, I can go full on pixel perfect or I can go napkin drawing detail.

It all really depends on the team.  Here's an example of a component that I spec'ed for a remote team.  Generally, if we are going to be sending specs out to a remote team in another country, I spec the crap out of it leaving zero room for error.  

"If you don't have time to do it right, when will you have time to do it over?"
     -- John Wooden