High level design documents are normally produced by the development team and give an overall general overview of the technical, logical design of the system. This can include hardware schema, database design, file design, etc.
Low level design documents get into more detail and may specify database content, file specifications, and table layouts, with specific information in terms of content of those elements.
They are useful as an adjunct to functional specifications or user specifications. Design documents often contain information that specify file and table content; I've received documents that also specify field constraints, which are very useful for testing. In addition, some specify error conditions as well. My advice would be to read all documents, even if it doesn't seem pertinent at the time. I do not like to use design documents as the sole source of information for testing, as they do not contain any business/user related work flow. I may know from design documents that module XYZ is structured in a certain way, where it reads from and writes to, and the format of any transmissions, files, and stored data, but a module can adhere to detailed specs and still not do everything it needed to do in order to support the original desires of the end users. The best of all situations is to have both user-oriented documentation (such as functional specifications, business requirements, etc.) AND technical design documents.