Software design documents are a good way to kick off a project. They let you:
This is the template that I like to use for these docs. It helps you focus on the outcomes that you're trying to achieve while still vetting the outputs that you plan on shipping. It's good to put each one in Google Docs or some other tool that makes it easy for people to add comments and have threaded discussions.
A one or two sentence summary of the project or problem.
The why. What is the pain point that we need to solve? For our users, for ourselves, for our platform. Include metrics or other data when possible that can make a case for this problem being important.
One sign of a good problem statement is that it does not lock us into any one specific solution. This leaves room for product, design, and engineering to figure out the most efficient way to solve it (a process which we hope to capture, democratize, and improve with this document).
How do we know that the problem has been solved? A good goal statement focuses on outcomes ("what needs to improve and by how much"), not outputs ("what needs to be built"). Ideally include a baseline metric, trend, and a target, eg: "5% of users who visit our site on a mobile device end up placing an order, down from 10% last quarter. Our goal is to increase that number to 15% by the end of this quarter. This will raise our quarterly revenue by $X."
It should be possible to implement everything in the "functionality" section successfully and still not achieve the goal. That's ok! It means that we have a good outcome-focused goal statement and it tells us that we need to continue iterating on our solution. Worse is to assume that the goal has been achieved just because we shipped something.
The what. If we're building something new, what should it do? How does it address the problem statement? What are the acceptance criteria? This helps define the scope of the project. User stories can be good here, or just a bulleted list of features. Mockups, UI sketches, and UX diagrams too.
Is there something different we could build that would address the problem in a different way? Is there a way to address the problem without building anything and instead implementing some process / comm / other change?
How could this fail? What other projects or parts of the business might be impacted? What do we need to do more research on (or get input from other departments on) before moving forward? What assumptions are we making, and are we comfortable with those assumptions?
The how. High-level plans, trade offs, level of effort, third party tools or libraries that might be useful.
Ideas or functionality that might be good future enhancements but are explicitly not going to be a part of this iteration of the feature.