Computers, Medicine, Usability, viewed from the ED
If you're new here, you might like to look through this introduction to the site first.
Are you interested in how computers can reduce medical error?
Did you know that many early medical computer systems increased medical error? (Some current ones, too.)
From your own experience with your own computer at home, do you think that some computers and programs crash on a regular basis? Do you think that most software is hard to use, rude, and frustrating to work with? Based on experience, what you’ve heard, or simple extrapolation, do you suspect that medical computer systems are even worse?
Did you know that the best place to test medical computer systems is the ED, because people working in the ED don’t have the time to deal with bad computer systems, and are intolerant of BS? (If it works in the ED, you can make it work anywhere else in the hospital.)
Do you want to learn more about how to make medical computer systems usable, so as to prevent medical error?
If the answer to any of these questions is “yes,” then read through the Medical Computing series. Although looked at from my viewpoint in the ED, it all applies to medical computer systems wherever they are used, in a hospital, in a clinic or in an office.
If you need a backgrounder on Healthcare IT concepts and terminology, see Healthcare IT in a Nutshell.
There’s also a series of “word” essays that focus on particular and generally more advanced medical computer issues.
To keep up with new postings, you might want to subscribe to my RSS feed.
One final note: Once explained, most of the suggestions on this site seem simple and obvious. But as one is creating a program, or even as one is using a program with a high level of frustration, they are still not obvious until pointed out.
I hope you find the site informative and, perhaps, a bit mind-expandingly entertaining.
Keith Conover, M.D., FACEP
A wireframe document for a person profile view
A common technique for prototyping computer screens is to use wireframes. A recent article in UXmatters discusses wireframes, and asks whether wireframe prototypes are used by program designers as a substitute for real collaboration.
That’s a good question. But I think this is a better one: is showing wireframes to people a poor substitute for figuring out what users need to do, and then designing and refining a workflow process that works for them?
Wireframing, also known as paper prototyping (because it can all be done on paper, without wasting a single electron) can be an effective tool during design. However, it is not a substitute for sitting down with some of each class of users, using anthropological techniques to document the tasks they are accomplishing as they work, and using personas to guide the design of the computer-based work process for these classes of users, and then going back and using discount usability testing to refine the process.
Wireframes are good but not a substitute for either collaboration or task analysis.
This entry was posted by kconover on Wednesday, February 26th, 2014 at
1:27 pm and is filed under
Tutorials .
You can follow any responses to this entry through the
RSS 2.0 feed.
Both comments and pings are currently closed.