The data is THE story; it should be front and center. Stories are often muddied by information-starved graphics. Aesthetically beautiful diagrams can suffer from low data-to-ink ratios (lots of paint, little useful data). Don’t pollute the data with eye candy: aim for clear, clean displays. One bite, big flavor.

Other concepts: information density, 80% of screen real estate should be dedicated to data; 20% to interface, and let data sing (listening to data can be more story-rich than using your eyeballs).

Don't make me input the same data twice, three times, or every time I hit a common data entry service.

Graphic design and grid construction are key visual design concepts for interface designers. Grid hierarchies and basic information layouts (similar in book, mag, and newspaper design) will be described and diagrammed. InfoViz enthusiasts, scientists, and engineers often don't know basic graphic design and layout practices. By instituting a few straightforward grids and thinking about how to align and design data (beautiful evidence), data visualization will become an even more powerful storytelling technique.

Gutter, column, margin, captions =

Use one grid and stick to it

When in doubt, bang left

Bend it like Beckham: once mastered, break the grid for elements that need a different treatment

Typography is the red-headed stepchild of interface design: forgotten, abused, but always visible. It’s the visual hierarchy for words. It’s the interface design for text. Good typography practice is critical for readability and scanning.

6 and 1 rule (use < 5 type treatments of only 1 type face), speak the user’s language (use vocabulary the service target audience is accustomed to, don’t evoke new language patterns unless absolutely necessary), require less reading and use more visual guides (because people don’t read, they skim to the good parts), and use better words and less of them (grab a copy of The Elements of Style and edit text like a crazy person down to every word).

Other concepts: use consistent symbolic vocabulary and the gutter is for bullets and quotes.

Color is one of the easiest tools for designers to use. It is also one of the most difficult tools to actually use well. In most cases, rather than being the hero, color should be a careful accent that helps what really matters - the information, the interaction, the user experience - accomplish its intended goals directly and elegantly. This typical requires color restraint.

Use color sparingly

The document should be center stage, not the paint

Talk, listen, watch, buddy-up

Feedback email to dev team: get continual feedback

• Get continual feedback: instant feedback via email to the development team = service requirement
• The engineering and design team needs to hear the feedback.... and engage with people using their service. Even 1 step removal from the feedback (like having marketing handle it) hurts. Part of the immediacy is lost. The emotion is lost. Don’t let someone else handle bugs and user experience problems. Hear it first hand (in the language of the customer) and without your marketing/QA spin control+verbage. Make the dev team feel the users EMOTIONAL response.
• Always have a contact email or form easily available. Don’t make me hunt around in 10s of screens and finger clicks and force me down a ‘select this problem’ path only to get another FAQ.

• Free food works

• Free lunch draws out the crabbiest of engineers and users. Use the free lunch card to lubricate the feedback lips.

• Let them bitch and find their pain points

  Organize sessions with users. Not just everyday users, but lead users... people who abuse your service, want to create their own tools (developers who use your API and dev their own tools), advanced users, experts in the field (who may not even use your app).

  Grow an early adopters group immediately. Before coding a single line, have a handful of people who maybe domain experts (like a geologist if you’re building an identify-this-rock service) work with your team... to make you smarter on their work and processes... and to get them involved in the development and evolution of their service. Manage their expectations from the food to managing the meeting to emailers to the service performance and interface design.

Global symbolic vocabulary, using iconography and symbols that speak "naturally"

Great interfaces disappear and have low cognitive overhead and over time become invisible (a la the iPhone photo app). People should be engaging directly with the content, manipulating photos and sorting piles of content without thinking about or seeing an interface ("where the damn edit button?!").

The photo browser for the iPad/iPhone is just so perfect to explain what this concept covers. You could read all the competing design books, and many others, but I don't think that any of them would have inspired that UI. They would all talk about how to manage what's expected, not achieve the unexpected. "A photo browser without any scroll bars? No previous and next buttons? No "jump to photo" pulldown? No buttons zoom in and out? No button to switch between portrait and landscape? No label on screen that says "Photo 14 of 27"? No button to jump to the first/last photo? Incredible. Breaks every rule in interface books.

Manipulate the data, not the interface

Over time as you use a service or product, the interface melts into the background. You don’t notice it anymore.

Elegance can crush practicality, beauty can be worth more than utility

Design first for the repeat user, then novice, and then finally for the infrequent, inexperienced user. When you first sat in the driver’s seat of your family car, your 16-year old brain freaked out. Reading the dashboard takes enormous cognitive load... during the first 10 neighborhood drives. After 1, 2, 10 or 50 years of driving, hundreds of decisions per second are made within a blink of an eye.

Imagine the dashboard printed with explicit directions for each function, light, and warning. The dash would be washed away by on-screen help and descriptions and the actual dials and driver metrics would be completely obfuscated.

You want experienced users to:

• become jedis by using your service
• tell their friends about it
• demand other services to hook into it
• make their work products better
• make users happy (by being efficient)
• purchase upgrades, future products = loyalty

The shortcuts, multitouch, physical engagement with screens and device....

Mobile computing technologies promise to revolutionize the relationship that people have with their health. Immediate access to, sharing of, and aggregation and analysis of data will put the power of our well being quite literally into the palms of our hand. However we face the same risks that have plagued personal computing: the technology has moved faster than people's ability to design successfully for it, in the process threatens to produce a generation of applications that are ineffectual and slow adoption of mobile health platforms.

The HIMSS Mobile Design Workgroup is crafting a common sense set of mobile design best practices, specifically tailored for the health market. These exemplars of effective mobile design will serve as an open blueprint that arms engineers, visionaries and designers around the world to craft highly usable and desirable health applications for the various, evolving mobile platforms. In addition, the design patterns will be showcased in a mobile health prototype called hLog (currently on the iPhone platform). This will be used to illustrate, in practical and applied terms, just how these best practices translate into truly remarkable mobile health services.

• SlideShare with voiceover of the Mohib presentation on 4.Feb.10 covering Let data scream and What interface?
• HIMSS EHR Usability site with three WebEx-based tenet lessons: Let Data Scream, Type Less + Less Type, and What Interface? - presented in June and July 2010.
• Our most recent draft as of 1.Mar.11 (20MB PDF) or hack and make the presentation better starting with the PowerPoint document (14MB).

To keep pace with the evolution of this young discipline, a companion wiki will allow citizens of planet earth can add to and edit the design tenets (hosted and launched by HIMSS on May.10).