When I was speaking at the Wisconsin SharePoint Users Group last week, someone asked me: "How do you know when to choose SharePoint Designer or Visual Studio for a particular change to a site?" I explained that I had a sort of "Hippocratic Oath" for SharePoint customization. In essence, it involves not making changes any more complicated than they need to be in order to achieve the design objectives. The ever popular "KISS" principle - Keep It Super Simple. (Yeah, I know, there's another breakdown for this acronym, but I think this is a little nicer.)
So, here it is:
The SharePoint Customization Hippocratic Oath.
First, Do No Harm
Use the Product: Don't customize where SharePoint already does what you need.
Do it with Style: Don't build a Master Page when a CSS theme will suffice.
Take the Data View: Don't build a binary web part when a Data View or Content Editor can do the job just as easily.
Master It: When you do need to make major changes to the layout of your pages, customize the Master, but don't throw the baby out with the bath water.
Feature it at Staples: Don't build a Site Definition when you can achieve your goals with Features and Feature Stapling.
The Definition of Success: If you must use a Site Definition, understand the ramifications.
Now, I'll talk about each of the points in a little more detail.
First, Do No Harm
If it isn't broken, don't fix it. Consider why you want to make the change. Are you trying provide a function your users are asking for? Do you need to meet some corporate guideline for branding on this site? If so, fine. Go on to the next step. Or are you just trying to change something "to be different" or "because you can"? Just don't do it! SharePoint works pretty darned well, right out of the box. Which brings us to the next principle:
Use the Product
As noted in my article, Your (Share)Point of View, SharePoint has a lot capability and flexibility. Before you go building new functionality, make sure SharePoint doesn't already have a feature that performs that task. You can add logos to pages, change colors with several existing Themes, build custom menus, re-arrange components, manage content, and all sorts of other things right from the Web-based User Interface. Don't re-invent the wheel. Use what's there.
Do it with "Style"
Ok, the existing themes can leave something to be desired, especially if your marketing department is insisting that the top banner be "Pantone 321". Now it's time to open SharePoint Designer. You're still not hacking pages apart, or worrying about chasing "Ghosts". You want to take advantage of SPD's CSS editing capabilities. You can do a lot with CSS. Not just colors, but fonts, sizes, background graphics, and lots more. Although the default Master pages used by SharePoint make using CSS for positioning a bit problematic, you even still have some flexibility there.
The big thing is, unlike Master page customizations, anything you do with a theme's CSS can apply to every page in your site - even those in the troublesome _layouts folder. Even if you do ultimately need to go to the next level with a Master page, by starting with a CSS Theme, you can make fewer Master changes, and thus minimize the visual shock your users would experience when those _layouts pages come to the surface.
Take the Data (Point of) View
Get to know the SharePoint XSLT Data View Web Part. When it comes to easy, powerful, customization, the Data View is the cream of the crop. Graphical menus? Yep. Mash-ups with external data sources? You got it! The Data View in SharePoint Designer can save you hours of coding when it comes to in-page functionality. (Oh, and the Content Editor Web Part is no slouch, either!)
"Master" It
When it comes time to totally change the look of SharePoint, the only way to go is to build a new Master Page. Once more, the tool of choice is SharePoint Designer. If you're doing a public facing web site, you can start from scratch, and drop in your SharePoint functionality only as you need it. But if you are doing an Intranet portal, you should keep as much of the "stock" SharePoint as you can. Again, start with the theme CSS, and then start working on your Master page. You might find you don't need to change nearly as much as you initially thought. There are a lot of standard SharePoint components used in the default Master page. Learn about them, and don't throw them away when you build your own Master pages.
"Feature" It at "Staples"
When you finally reach the point where you just can't implement the functionality you need through Themes, the Data View, or custom Master Pages, only then do you need to reach for Visual Studio. But even here, there is a hierarchy of needs. You don't need to come out of the gate with the "big guns" - a new Site Definition. In fact, that should be pretty close to your last resort. Instead, go for creating Features. Features can be added to sites as needed. You can even force their deployment through Stapling them to existing Site Definitions. Features can be activated, deactivated, and even upgraded, on existing sites.
The (Site) Definition of Success
None of this is to say that Site Definitions are obsolete, or should never be used. You just need to be aware that this is a very fundamental construct. Once you build a site from a site definition, you cannot change it to a different definition later. You can still tweak it with additional features, but you can't change the "kind" of site it is. It will not be a "SharePoint Team Site", easily and transparently upgrade-able. It will be an "Acme Group SIte", or whatever you have called it, and you need to plan for its entire life-cycle (Much like adopting a puppy). There may be extra steps in the upgrade process, for example (though, at this time, we don't know what those steps might be). You may have trouble getting support if the person who created the Site Definition moves on to greener pastures. This may be worth it for your environment, but it is something you need to take into account.