Design patterns are a tool. They provide a way of thinking about your proposed development, a design to build your solution, and a method of explaining your solution to others.
They are patterns - that is, the things that they describe turn up so often that they are recognizable. You are almost certainly using some design patterns already, whether you realize it or not.
Learning about design patterns is definately a great idea for both of these reasons. When designing a solution to a problem, you will probably spot places where a design pattern will fit, and suddenly that whole section of the problem is solved. Likewise, in the real world, it is much easier to mention which design pattern is used, rather than trying to describe the individual parts of the solution (no matter whether you are the developer trying to explain your solution to other developers, or whether you are trying to understand somebody else's design). Or, as Kathy, Bert, Eric and Beth said it much better than I can:
[qb]From Head First Design Patterns "local diner" example: Alice (to cook): I need a Cream cheese with jelly on white bread, a chocolate soda with vanilla ice cream, a grilled cheese sandwich with bacon, a tuna ﬁsh salad on toast, a banana split with ice cream & sliced bananas and a coffee with a cream and two sugars, ... oh, and put a hamburger on the grill!
Flo (to cook): Give me a C.J. White, a black & white, a Jack Benny, a radio, a house boat, a coffee regular and burn one!
Commentary: What’s the difference between these two orders? Not a thing! They’re both the same order, except Alice is using twice the number of words and trying the patience of a grumpy short order cook.
What’s Flo got that Alice doesn’t? A shared vocabulary with the short order cook. Not only is it easier to communicate with the cook, but it gives the cook less to remember because he’s got all the diner patterns in his head.
Design Patterns give you a shared vocabulary with other developers. Once you’ve got the vocabulary you can more easily communicate with other developers and inspire those who don’t know patterns to start learning them. It also elevates your thinking about architectures by letting you think at the pattern level, not the nitty gritty object level.
So what we end up with is a situation where, if you know the patterns, as you design your solution you will probably think "ahh, pattern 'x' will fit well here. Or "hey, this sounds like I've just used pattern 'y'. And you can document it as such if you like.
But your question "should I use a design pattern" - is thinking about this the wrong way. You will almost certainly use one or more design patterns in your solution whether you realize it or not. Plus it leads to the question "which design pattern should I use", which is like asking if you should use a 12mm drill when building a house - you might use the 12mm drill, but you should not try to design the house just so you can use it.