As well as test-driven development (TDD), I also like README-driven development - a.k.a. documentation-driven development.
In short, you write the documentation first, followed by the code.
Like writing tests in TDD, it allows you to think about how your code will work, what functions and methods it will contain, how they’ll interact together and how you expect people to use your code.
This can also contain flowcharts, diagrams, example code snippets and anything else that would be useful.
If you like, you could have a colleague review it in a pull/merge request before progressing.
Once the README file is written and you’re happy with its contents, you can start coding.
Also, documentation is commonly missed or skipped in projects, so moving it forward in the development process ensures it will be done and, as it’s being written nearer to the writing of the code, it’s more likely to be correct instead of writing it all once the code has been written.