Hi Jonathan,
Perhaps you could start by reviewing any existing documents and see if some categories suggest themselves. Try out a couple of categorisations on paper and see how the documents fit. Don't spend too much time trying to get it perfect on Day 1 - it can evolve as you build out the collection. Ask the analysts at a quiet time to share their favourites - post-it notes, PDFs, pages pinned to partitions, hand-written checklists in notebooks, bookmarked URLs... and see if some natural structure emerges.
One of the functions associated with a category is the ability to grant read and write access to groups or to roles. So for example you might have a high-level category of 'End-user' documents that you make visible to end-users, as opposed to 'Analyst' documents that are used within the service desk team. And then the sub-categories would follow. The sub-categories might also be really broad - e.g. FAQs, How-To documents, Getting Started documents... Or they could be really specific - e.g. Multi-function printer problems, Network issues, HR application issues, What to do when error 'X' is reported, Daily housekeeping... And those categories hopefully will suggest themselves as you look through any existing documents.
To my mind, the fewer categories the better (otherwise you may get bogged down in arguments about what belongs where) - but you can also flag a document as belonging to more than one category.
A consistent, reviewed and regularly updated keyword list is important regardless of your categories, to make your documents retrievable.
Process and ownership are vital. Who is responsible for creating, testing, reviewing, publishing, maintaining and ultimately retiring KDs? They need to be managed through a lifecycle like any other product and someone needs to be tasked with managing them in order to get some value out of the whole exercise.
Hope that helps!
Regards,
James