Once, long ago whilst still an undergraduate, I was asked to explain something over Sunday lunch - one of the most educational experiences I've ever had. The person asking the question was demonstrably not stupid - but had no background, the level of knowledge I assumed just wasn't there. I started to answer, got a blank look, changed down, still blank, changed down again, still blank... hmm... so I started the same way you start to build an application, with little blocks of explanation that you can build into something more substantial.
The key part of this lesson, for me, was (and is) just how much we assume (not just programmers, everyone) about other people's knowledge of our chosen speciality whereas in fact, even, you might reasonably assume that the majority of people know that 1 + 1 = 2 but after that it gets interesting.
So the first and most important thing to grasp is that people don't know and don't understand what you do - but they do understand what they do and when you're explaining stuff you therefore need to start simple and stay at an appropriate level for your audience.
In terms of specific techniques - I think that @Josh K has it pretty covered - and I'd emphasise that Analogies are an absolute winner.
One more thing - it may be, from time to time, acceptable to just write things off as "geek stuff" people don't always want full explanations of why and if you've previously demonstrated a willingness to explain and a capability to do so in an understandable manner then people will be inclined to trust you when you suggest that "complex technical reasons" apply or that ultimately you can achieve a particular result by "doing geek stuff" (or "programmer stuff" or whatever term works well in your environs).
Communicating technical things to a non technical audience (of one or more) is a skill, one that you can develop and one that you need.