It will be interesting to see how SharePoint Designer (SPD) 2010 fits into our development work flow.
For SharePoint 2007, we had basically avoided SPD 2007 like the plague. It didn’t fit into our Visual Studio development work flow. Almost everything you did from a client-side development perspective was not easily reproducible across sites as the artifacts were basically all unghosted/customized. The actual SharePoint functionality was limited just seemed to be tacked on top of the FrontPage. The HTML editing around customizing master pages and page layouts was slow, buggy and heavy handed as it would arbitrarily change our code.
The interface has been completely overhauled in SPD 2010. Instead of the HTML editing centric interface in SPD 2007, we now have an interface that instead focuses on exposing various SharePoint capabilities to users with less technical expertise. It’s still not something you would deploy to all your users. It really is for your SharePoint power user or site administrator to manage their sites and lists.
SharePoint 2010 sites now have settings to determine what SPD is allowed to do or not do. There are settings to enable SharePoint Designer, enable detaching pages from their site definition, enable customizing master pages and layout pages, and enable managing of the web site URL structure.
The other big thing about SPD 2010 is the ability for it to now create reusable work flows. You can create a work flow and then package it up as a WSP and import it into Visual Studio 2010 for further development. You can also design your work flow in Visio 2010 which is quite interesting.
Check out the SharePoint Designer Team Blog for detailed info on all the new SPD 2010 features.