solve simpler problems first
Large problems can often be difficult to solve and may seem to require complex solutions.
The first step to creating a simple solution is starting with a simpler problem.
parts of problems
One way to simplify a problem is to solve a part of the problem before attempting to solve the entire problem. Often the experience gained with solving a portion of the problem will illuminate other aspects of the problem and make them easier to solve.
Look for a problem to solve in a specific real world domain, rather than a broad set of domains. When generic examples are given, ask for specific examples.
Prefer addressing an immediate problem over a (often simply hypothetically perceived) longer term problem.
the 80 percent
Look at solving perhaps the 80% of instances of real world (see related principle: humans-first) uses of that specific problem rather than trying to solve 100% of such use-cases.
It's very hard to solve a hard problem directly in its entirety, that is by trying to jump to designing (and/or building) a 100% solution to a hard problem.
It is much easier to solve the "easy" or "common" 80% of a problem, and once that's been solved and implemented, you iterate (using the filter of the real world) and figure out what the next 80% is that needs (per real world needs, not hypothetical needs) solving. See start as simple as possible for more on iteration.
Note also that the 80% of Best Practices for Examples Pages refers to content being published (i.e. human content publishing behavior), not to syntax or explicit schema, e.g. class names, other formats etc. Which formats and names to consider re-using for microformats property names etc. is another part of the The microformats process and is described a bit in Naming Principles.