Dick Taylor, the CMIO at Providence Health and Services Oregon Region has been speaking to this principle of usability for some time.
“No Stupid Questions: remember why your clinical users came to work today, and honor their needs.”
Until recently I had been filing this under “obvious but impractical.” Recently I had a chance to talk this through with him. I came away convinced that his principle is a valuable approach to the most nuanced issues of UI design.
Like any good scientist-philosopher Dick has developed a taxonomy. He describes
- First order stupid questions: those that are so trivial that they are an insult to user’s time to ask them.
- Second order stupid questions: those that cannot be answered by most users.
He offers this example of a first-order stupid question. You say you want to delete something and the system asks “do you want to delete this thing? Yes No. “ First-order stupid questions arose because of the need to protect users from their mistakes. “Do you really want to delete 5 pages of text?” Before computers had “undo” function users might have preferred such alerts; these days we expect software to offer “undo” or to “exit without changing” or other ways to worry about errors after they happen.
Stupid questions sometimes come disguised as statements. If, after the user signs an order there is a dialogue box that says “order submitted, press OK” the system is either insulting the user or expressing great doubt about its own reliability. From the time the user signed the order her mind has been running ahead to the next order or patient. Let’s not distract her.
An example of a second-order stupid question might be “this is a secure web page but some of the contents come from a non-secure server, do you want to proceed?” Few users know what this means. Even those that do couldn’t make a decision without knowing which data came from the insecure server. All this question does is to encourage users to develop the habit of clicking through security alerts blindly and to give some security person somewhere the false idea that users are safer.
Today every implementation of clinical decision support involves finding a balance between improving care and creating alert fatigue. Alert fatigue is really “stupid question fatigue.” We don’t ask pilots whether they want to climb steeply when they pull back on the yoke even though lives may be put at risk. We optimize the pilot’s time and attention by assuming a certain level of professionalism and training. If the result is to approach stall speed then the balance swings to providing an alert.
The “no stupid questions” principle doesn’t lead to a formulaic determination on the validity of questions. However the principle should be applied routinely during of any functional or UI design. Designers should ask themselves:
- Is this question necessary for a competent professional user who is working efficiently?
- If the question is about a potential user error, can we wait until the error occurs? (If not, we should rethink the overall system design.)
- If the question is going to be “blown through” by most users why ask it? If the goal is to detect rare security issues maybe the right approach would be to create an entry in an audit file.
- Does this question represent trading a fraction of a second of user’s time for a few days’ programming time? If the answer is “yes” this is a bad decision even under deadline pressure. For example, if the question identifies a rare but important user error that might occur can more complex programming eliminate the question most of the time for most users?
Sometimes reviewing these issues at design will eliminate stupid questions. Sometimes it will affirm the questions are not stupid. Sometimes it will cause the designer to rethink the flow so the question becomes unnecessary. In all cases the user benefits.