A few notes:

* much what applies to software design with Smalltalk applies to Lisp.
  There is some Smalltalk literature (from Kent Beck and others).

* Lisp in general and even Common Lisp is applicable to
  a wide range of software systems. These may have very
  different development styles.

* Often you see a prototype-based approach: build
  a working prototype and refine it in tight cycles
  while discussing the results with the customer.
  Sometimes the customer may even be present when
  changes to the code are made.

  Btw., a little-known but cool story comes from
  the Smalltalk world: when Steve Jobs of Apple
  visited PARC to learn about their projects in
  personal computers and guis, they showed him some
  stuff. But not the more interesting things. Like
  the Smalltalk system. He somehow got to know
  that there was more to see and at a second visit
  they showed him Smalltalk. There was demo of
  scrolling text in some window. Jobs thought
  that the scrolling should not be line by line
  by smoother. The guy doing the demo (maybe that
  was Larry Tesler) went into the source code browser,
  looked up the method, changed the method and, 'boom',
  there was smooth scrolling.

* There is a mismatch with UML and CLOS. UML seems not to
  be used widely.

* There was a book Lisp Style and Design. Hard to get. No
  longer available.

* Other books which give hints and explain things
  are 'Practical Common Lisp' (Seibel) and 'Paradigms of
  Artificial Intelligence Programming' (Norvig).
  Both are very good books and are highly recommended.

* Another widely use approach some people call
  nowadays is programming with 'domain specific languages'.
  In Lisp this is easy, because it can be integrated
  into the language and the development environment and
  one can reuse all kinds of Lisp infrastructure.
  But most of the DSLs people now write about are
  just syntactic sugar. In Lisp one did more.
  There are several programming books which show
  you how to develop embedded languages in Lisp.
  The basic idea is that for expressing knowledge
  about a problem you need a language for that.
  The language implementation needs to provide
  the right services. These languages might need
  a different paradigm (rules, objects, constraints,
  message passing, blackboards, agents, ...).
  So you embed a system for that in Lisp and then
  you can express the problem domain much easier.

  One of those books is: 'Artificial Intelligence Programming'
  http://www.amazon.com/Artificial-Intelligence-Programming-Eugene-Char...

  This affects architecture. In Java/J2EE you would build
  complex object/class architectures with lots of XML
  files to describe things. In Lisp you can describe
  much more directly and it is much easier to use/build
  architectures that don't fit in some 'standard model'.

* Late binding is one principle. You delay many decisions
  to runtime. One effect to this is that you
  can ship an application to a customer and later
  you only send patches. No need to give him a new
  version of his/her application every time.
  The customer might even load these patches while
  the application is still running.
  You can imagine that the whole cycle of getting bug
  reports and shipping improvements to the customer
  can be much shorter.

* Another idea to look out for is that you design software
  in Lisp so that the amount of work needed to
  change the software depends on the size of the change
  and not on the size of the software.
  This is one of the core principles of incremental
  software development.

* Another stream of ideas came out of the work on
  'Open Implementation'. Things like Aspect-oriented
  Programming are coming from there.
  http://www2.parc.com/csl/groups/sda/publications/

* Here is a more philosophical description
  of an operating system written in Lisp:

  http://lispm.dyndns.org/genera-concepts/genera.html

  It should give you some ideas about the design principles.