Differences between revisions 10 and 11
Revision 10 as of 2011-05-07 16:42:42
Size: 3008
Editor: shoobe01
Comment:
Revision 11 as of 2011-05-07 19:13:03
Size: 3127
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 22: Line 22:



== User-Centric Execution ==
...successfully building those designs, by leveraging patterns and heuristics...

This page is a stub. It's just something to get notes down, and is not final in any way.

...see the bottom. I have a presentation halfway done on this exactly...

How using the patterns can lead to better design by re-use consistency. If you pick a pattern, don't just pick it for the screen you are working on, but add to your documentation as a component that anyone can use on any part of the project. Communicate this to development. Then, only one of them is built, and used over and over. Consistent UX, as well as savings on development, QA, etc.

I think perhaps a bit about resolution-independent design, and otherwise class-based design. Can take any design, assign to a few size classes, input classes, etc. and generate from that.

And this needs to be in here somewhere, but here or another chapter or... something else:

Using these, and following patterns exclusively will result in what I am calling the heuristic solution. Which is fine, and will pass all the checkmarks and get decent test results, but is not going to be differentiable. Which might be fine for some applications, or some parts of an OS or app, but is not so useful for interfaces that must delight, or entice users to revisit. Simply using more gestures, for example, is not automatically delightful. You have to understand the product holistically, and think tangentially about the multiple ways to approach the solution. Note also that these patterns are generally not very prescriptive. Not that they don't require certain behaviors, and prohibit others, but read closer: There are options, and not objects to be implemented but principles upon which your object has to be designed. There's lots of room create something all new, and then divine the underlying truths of the design so pattern level principles can be applied to assure it still meets basic needs and is usable.

ALSO: maybe we should explicitly talk about design at this time. Like, a discussion of NUI being easily taken a step too far. -- If so, riff off this article http://globalmoxie.com/blog/evolution-of-touchscreen-discoverability.shtml And especially this paragraph which is a nice guideline -- added after my gripes :) "I don't mean to suggest that we throw out all of our familiar buttons entirely. Light switches shall remain necessary, after all, and so shall buttons, especially where it's necessary to trigger abstract actions ("share via Twitter," for example). But it's important to recognize those devices for what they are: necessary hacks for moments when direct interaction isn't possible. Touchscreen interfaces allow that direct interaction in many more contexts. As new solutions arise, we should be open to putting our time-tested workarounds aside. When designing an interaction for touch, always ask: do I really need another button or control for this?"

User-Centric Execution

...successfully building those designs, by leveraging patterns and heuristics...

Successfully Designing with Patterns and Heuristics (last edited 2013-04-08 20:02:22 by shoobe01)