The product was an anatomy software application that presented detailed medical illustrations. There were three primary data bases underlying the product, based on the three types of medical illustrations:
- Layered view (skin on/off, muscles on/off, just the bone, just the veins, etc.)
- Cut -away (as in take a knife and slice it in half)
- Pin-view (as in pull back bits and pieces as if on a dissection table and label the components)
The user interface was designed around, you guessed it, the three views:
- Pick a view.
- Pick a body part.
Well, it didn't take long for the usability test to show the flaw with that. The user work flow was pick a body part and look at the different views. Classic mistake, user interface was designed to reflect the data structure, not the information needs of the use. Easy fix. (UI fixes usually are.)
Fast forward to today and I see where we can easily make the same mistake regarding information and media on Web sites. Blogs here, professional publications here, academic publications here, forums here, podcasts here.
But users typically do not come into a problem defined around media, as in "I want to see a podcast," "I want to read a blog," or "I wonder what academic research says." They define problems in terms of "I want to know..."
For example, if I want to learn a song, I have to go to YouTube to hear it sung, another Web site to get chords and lyrics, and then often another Web site to get music or tablature. But if my problem is "I want to play Sweet Baby James, wouldn't it be neat to have one place that offered a video of James Taylor singing it, along with links to lyrics, chords and tabs right there? And Google isn't the answer; I'm lazy and want a vetted aggregation. (In other words, I don't want 19 different sets of chords, I want at most two: The ones James Taylor actually uses and maybe a simplied version ala a "fake it" book.
I'm hoping we avoid this misstep with our STC Body of Knowledge and all of the other media we are contemplating. I don't want to go one place for academic articles, another for practitioner insight, and yet another for the social media. Once I say "I want to know about usability," I want the UI to aggregate all the STC assets and present them to me.
I know. SMOCM (pronounced "Smoke 'em"--simple matter of content management)
3 comments:
I just have to say that I like the acronym SMOCM for its ambiguous pronunciation: Smoke'em can mean "You'd better be stoned to try this" or it can be a prediction of what it will do to your servers.
At the STC Atlanta Summit in May, I volunteered to help add to the STC Body of Knowledge. Since then I have been looking at it intermittently, and at my copies of Intercom and Technical Communication, and at the Materials from this year's and previous conferences.
I have been trying to comprehend how we can link the BOK sections to all the still useful, but disparate information that has been published or presented by/at STC over even the last 5 years. In the BOK context, Content Management is no longer a "Simple Matter". Until someone can put together a logical content strategy, it is the smoking crater that is keeping the BOK from being built.
I assure you, Margaret, my use of "simple" was laced with irony.
Post a Comment