Our goal for Silverlight 2 was to provide a control skinning model that is imminently usable for visual designers, providing an easy entry ramp, yet with sufficient power for sophisticated application skins. Our design goals did include:

1. Make sure that skin design can be a task for a visual designer. Avoid requiring skills visual designers are not likely to have. Reduce the learning curve for common skinning tasks
2. Create a model that can work with both Silverlight and desktop WPF 
3. Create a model that can be tooled easily and effectively
4. Allow for skinning of composite controls, i.e. control skins that contain other controls as parts (for example the up/down buttons in a slider)  
5. Make it possible to create interchangeable skins
6. Skinned controls should be portable to desktop WPF with reasonably little effort

We addressed these design goals as follows:

• The Silverlight model uses styles and control templates just like WPF.
• We added a clean and simple conceptual model that separates the visual aspects of a control skin from the behavioral aspects of the control. Visual states completely encapsulate the concept of the different looks a control can have, in a way that enables visual designers to simply focus on how the control needs to look in different states. 
• We added a well-defined, differentiated transition model. With VSM, transitions between visual states can be explicitly defined, either in a very simple general way, or as specific and detailed as required. Most importantly, the transition model, while it permits the definition of detailed manual transitions, also allows designers to simply specify transition timing, generating all other details automatically. This approach is fast, easy and flexible.
• The control code provides default hookup of events and properties to state changes. In the future, it will be possible to extend and override the default hookup provided by the control, but this ability is not available yet. The ability to extend and override visual states could be implemented on top of the existing system, so this is by no means a systemic issue with the model – we simply did not have the time to provide this capability in this round.
• Tooling. The June preview of Expression Blend provides explicit tooling for the VSM model. Controls provide a list of desired visual states to Blend, and Designers can simply pick a visual state from a list and then tweak visuals and transitions using the Blend artboard. No deep understanding of control events and properties is required.
• State groups allow complex controls to reduce the number of individual states that need to be exposed for editing
• As an added bonus, visual states are also available for user controls, not just for fully template-based controls. User controls are a great choice when interchangeable skins are not required. Making user controls with dynamic visuals that respond to control state is much easier with VSM and the consistency with styling of template-based controls significantly reduces learning effort and production cost.