A good article on why to wireframe for your project

Good read from Thomas on visitmix.

http://www.visitmix.com/Opinions/Should-We-Kill-Wireframing#200905140354378

For Rich Internet and desktop applications, rectangles, buttons, textboxes, and breadcrumbs simply don't do it for wireframes. They serve to ground the logic flow of an experience, but for this low-degree of effort, it's not reasonable to assume that your client will understand or even what you've come up with here. There is truly a balance between visually sound and agile prototyping. To make a bold statement on a unique UX for a particular scenario will win over a client's trust in your abilities. Still, we can't expect that every scenario will have that special user experience or we'd all be broke, right? We need to wireframe what is absolutely going to be a pain point for the client. Sketch quickly, prototype the design collaboratively, and best of all, if the client is unable to accept how an interaction will take place or how that flow of information will take place, lean on an animator to stitch together a few keyframes to illustrate the pitch. Make it quick and dirty, but most importantly, pitch the right UX metaphor for the interaction. Sell the wireframes on the key moments, not by designing a black/white web site. No matter how cool Sketchflow and other tools sound, there's no substitute for back of the napkin, whiteboarding. Still, if you pitch a wireframe, you better be sure the client knows if it's been blessed from engineering or not.

Good talent can actually be had

IdentityMine is truly on the cusp of greatness. Some of the finest visual and creative designers I've had the pleasure to work with are noodling forward on concepts and ideas that are both very interesting with good business sense behind them. I love my job.

When to sell the design concept and the UI?

Software often gets into a rut in two key areas focused around the UX layer - this is entirely true across .Net 3 and its subset Silverlight that utilize the power of xaml. First, an interface designer shouldn't be caught up on the nuances of window chrome, positioning of elements, or refinements to gradients, flashiness, or hotness when first designing visuals for the project. Ideally, the resource is able to stay well clear of refined comps and focus purely on color palettes through mood boards and simple mockups that combine logical layout with some loose styles. Of course, this requires a decent set of wireframes that should be constructed by the Information Architect type resource along with Use Cases if needed. Building Use Cases may not be required if you're facelifting an app. Along these lines, the wireframes should by no means impose look/feel, composition, or layout since this can often lead to the removal of creativity for the Interface Designer - if this does happen, it can lead to poor design. The Information Architect and the Interface Designer should be locked at the hips at this point, each making recommendations on the business sense and creativity/innovation of the visuals.

Mockups should be very loose - I think of Kathy Sierra's older article on "How 'done' something looks should match how 'done' something is" as a great reference at this point. I particularly love the Napkin look & feel - it just feels so relevant to me. You can't sell the entire screen at once, and it certainly shouldn't be expected to rise from the ether. Several concepts could be presented this way each of which has its own good and bad. I guess I'd say distilling the design down slowly is much more efficient and innovative and will prove the power of this notion with clients. Since the goal is not to stray too far from the approved concepts and interim milestones are met. And just because you have a wireframe doesn't mean that budget should not be available to combine visuals with business value and innovation. I think this is too often forgotten, since a highly polished comp lends folks to believe that you're "nearly done", right?

Another critical point that is an entirely huge topic is that of technical feasibility of a said design - in WPF, Silverlight, assuming you're going for a pure xaml UX layer, you've got to assure that the designer either works inside of Expression Designer, or is mated to a technical engineer or Integrator type resource that can validate a designed UI can be realized inside of xaml...

In summary, selling the concepts of the app's interface should only happen through quick and dirty mockups that take the wireframes to the next level. Once approved, iconography and a fleshed out interface should lead to some early comps that don't go too deep in visual beauty. Experimenting with the animation side of things for the chosen interface should happen in small, self contained little motion tests to prove or disprove the visual concepts. This can get very expensive if not managed tightly though. Only those concepts that are chosen should lead into solutions that get plugged into the UX layer. In the case of using xaml, you should make the determination at kickoff on the UX integration strategy to be used.

Under promise and over deliver seems so obvious here, but it's a double edge sword - are we selling the power of the platform through stunning visuals or are we trying to test the waters and get buy in on the design direction, or are we trying to refine the interface...know where you are in the process and have a workflow that makes sense for your team. As a PM, you have to stick to it, and keep iterations to a minimum to stay whole. It feels like I could go on forever on this topic...another time.