I sent this information to one of the teams in response to a question and thought it might be interesting for the other teams.
If you are using the format on the slides in the design presentation rather
than one of the sample templates it kind-of breaks down like this:

System Models: A description and diagram of how you have desgined your
system to operate as a "black box" with the rest of the world. You have
context diagrams, High-level data models, interactions with the OS etc, You
might present some sequence diagrams or even a state diagram (depending on
the type of system you are building) that shows your design of the system as
a whole.

Conceptual Design: OK, now we take that system black box and open it up.
This section shows your architecture and discusses it. This should include
a high-level design description of the major modules and how they interact.
You might present class diagrams and sequence diagrams here also. The
difference is that your sequence diagrams do not show one box as the
System, but rather shows how the classes in your design cooperate. If you
are not using UML, this section would include data flow diagrams or other
devices to show how information flows through your application.

There be multiple conceptual diagrams that you present. One might be a
logical view of the system (this is probably the most common) that shows
groupings of major pieces of functionality. One might be a process view
that shows a snapshot of the processes and threads in execution at run-time.
One might be a module view that shows how code files are divided between
packages/modules in the system. One might be a physical view that shows
what parts of the system are executing on different physical devices in the
system. Some of your systems may need only one of these (almost always the
logical view). Others may need some or all of them.

Detailed Design: Now we are in the nitty-gritty. This is where you specify
exactly how the high-level parts are broken down. For instance in a Java
application the conceptual design might depict packages and higher-level
classes. This section would have diagrams for classes in each package (or
for C, functions in each file module) and detailed descriptions of key
algorithms used by classes. These descriptions are typically in
pseudo-code, but can be in plain english if it is understandable.

A key idea of design documents is capturing "rationale". That is: Why did
your team decide to things this way as opposed to another. If you decided
to use a pipe-and-filter archtitecture, why did you do that. This makes the
document very valuable to maintainers in the long term because they can
understand your thought processes. That is why on the other sample
templates I put off the web page there is extensive emphasis on rationale
and explaining decisions.

Think of the design document as guiding the understanding of the system
through 3 stages: First we design the interactions of the system with the
world, then we design the major modules of the system, finally we discuss
the guts of each of those modules.