Bonus points if this tool requires developers to make a branch cut of your codebase and go through a pull review process -- this will ensure that even typo fixes take 30+ minutes of developer time.
Make sure that they don't make clear what is currently implemented vs what is still in progress. Developers should never go back and update their design docs as the implementation plan changes throughout the project. You can do especially well here by ensuring you link to slightly different design docs dicsussing the same project from different places.
Business reasons for certain architecture decisions should never be discussed in the same place as those architectures are discussed. You'll also want to make sure that you never write down reasons for design decisions, leave that to future developers to find out the hard way just like you had to.
Bonus points if you leave the old documentation around somewhere. Additional bonus points if you directly migrate all the old content but leave the URLs pointing at the old resource so that your docs are full of dead links. To really capture this category, mark all older documentation as "deprecated" but don't link to the updated version.
Force people to know exactly what the weird internal name of your project is if they want to find the docs. You should also make it impossible to find what project solves a specific problem by searching, this will make people acquire tribal knowledge.
Sadly, all of these are based on patterns that I've seen. Documentation is hard to get right. It doesn’t drive business metrics (at least internal documentation) and it doesn’t usually get people promoted. But I think that if you make it easy to write and easy to read, engineers will write pretty decent docs. If only because they’re sick of answering dumb questions in Slack.