Keep it simple
It is very easy to overcomplicate things, whether in life or work it is always best to stand back and take some time to think about the problem, understand what needs to be solved. Now you could methodically go through through every possible solution, weigh up the pros and cons and then decide what to do, that’s fine, that works. But I think it is easy to miss things, an edge case or a related problem.
The best thing to do is literally walk away from it, if you have the luxury of time then use that time to talk to others, research. Or even better, pick up a guitar, draw a pretty picture; do something else.
I read recently that the sub conscious is more active than you might think. It is almost completely responsibly for problem solving. Sounds strange but how many times have you got stuck with something then after an hour perhaps a day figured it out, even if you’ve spent the time doing something completely different.
Here is a good talk on Hammock Driven Development which reiterates that giving time to solving a problem works.
Once you understand a problem then it is best to strongly define that solution, try to imagine it, write it down or draw it if possible, talk to others about it. The solution should be terse and simple. It should not define a product or feature, it should explain how Given X is true, When Y is doing that Then Z should do this.
I use the Given, When, Then terminology at work to define the goal of the solution in development. Our QA team also use it to define test plans to affirm that the solution does indeed enable the intended goal.
In the UX domain there is this concept of Goal Driven Design.
“Given user A is a new user When user A first hits the web app Then user A should be encouraged to invite other people.”
The above goal defines a business objective to increase virality, and represents a small chunk of a user story. There could be many solutions to this, a bright pink invite button which leads to an invite form, perhaps the first screen they hit asks them to connect with facebook and/or gmail. Whatever the solution is, it should achieve the set goal as simply as possible, if this is the main goal then this should become the primary part of the design, everything else should become secondary or better, non-existent.
Break problems into smaller chunks and define end goals to develop better, simpler solutions.