Deciding if/which Design Pattern
To decide on a design pattern means achieving a balance between flexibility and pragmatism. The Golden Hammer pattern is something to avoid. A Golden Hammer pattern is a tool you may really love (bacause it is gold), but may not be the best tool for the job. You need to find the right tool, and it doesn't need to be golden.
Consider the big picture
Your choice needs to address the practical use cases for a business object; and it needs to balance that with timing, immediate results and sensibility of design. Your code needs to be readable, comprehendable, and address the business use cases. The balance comes in deciding just how much flexibility you should build in up front. The answer is simply that you need to get the job done on time, under budget, and deliver the business value.
Avoiding the Golden Hammer
Consider your design choices up front, and evaluate them each on their own merits. You can spend a little time prototyping out solutions, but you should start by addressing the top level goals. Break up the functionality into steps, and design the high level code first. This allows you to incrementally test how your chosen pattern fits your business case.
Don't Force Things
As you move down through each level of API, evaluate the way the pattern fits. As soon as it stops fitting, then stop using that pattern. You may need to just implement an MVP at that point, because you've spent valuable time evaluating the wrong solution. However, when you succeed, continue.
Keep the Ball Rolling
If you continue to find that the pattern you've chosen fits the bill, continue applying it and implementing the details. Clean up code that has been afftected by your changes, and write unit test and functional coverage of the new code. Make sure old tests still function, don't change externally facing APIs, and get the code functioning as a whole.
If there is anything that can help you to avoid the golden hammer, it is other peoples opinions. As an example, I once used a hammer to put in a new window sill. I started working with someone new, and he thought it was not the right tool. The only way to properly line up and make a window sill snug is to use a nail gun! Other people have the experiences to draw on, that may change the way you think about the problem, the solution, and the way to address the business concerns.
Stand up For What You Believe
You should stand up for what you believe. State your opinions clearly and without emotion. Make a case for your approach to satisfying the business and engineering use cases. The more you take seriously what you believe, the more other people will. The more you take their beliefs seriously the more clearly you will know whether your solution satisfies all the considerations. It's really important to see the big picture here. Software is for people to use, change, and re-use. Other people need to believe in what you create. You need to believe in what you create.
Exchange Ideals for Data and Sweat
You will never know whether your chosen design is right until it goes into use. As you make more choices and see more code go into use, you'll learn the situations where some patterns apply and others don't. Don't let the fact that you've never used a pattern disuade you from believing it's right. Let the data do the persuasion, and be prepared to fix your mistakes.