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.
No comments:
Post a Comment