Best way to handle when typology used by tech is different than typology presented to users?

Question

This question is a follow-up to this one on Meta.SE about the flag dialog used on SE sites. In the dialog, the first two ("spam" and "rude/abusive") are considered the same type of flag, and the second two ("should be closed" and "duplicate") are considered to be the same type of flag and different from the first. Thus, if someone raises one kind of flag, the UI will tell the user that s/he has already raised in both, like so:

The five options seem to me to set up an expectation that there are five types of flags and they are listed here. That is not an accurate reflection of the underlying technology or the meaning of the word "type" in this interface, though.

The SE mod response is that "It's not really a matter of what the user expects to happen" but then what is primary in UI design decisions?

Is this good design? Specifically why or why not? What would you change about it?

Are there general guidelines for UI design in cases where a technical typology differs significantly from the typology presented to users?

Answer 1

Past experiences shape the user’s mental model. They were presented with 5 independent options for flagging the post. On returning to perform the same task (flagging for a different reason), the 'system image' (interface) communicates to the user something different than what they were likely expecting - that actually each option is not independent (which conflicts with the user's mental model).

In this case the user then has to correct their mental model and work out for themselves that their single flag has a relationship with other flag types. They might even hold on to their mental model and convince themselves that they accidentally submitted the other flag types.

If we look at the actual options - 'Should be closed' and 'in need of moderator intervention' are suggestions as to what the resulting action should be. Whereas 'rude or abusive', 'spam' and 'duplicate' are labels or descriptions of the content. This could be causing some of the problem, as flagging something as 'duplicate' will (I assume) result in the question being closed, but 'should be closed' is itself its own option!

So what can we do? Some options could be:

• Group related flag types together, so they are informed of their relationship and it is clear why related options are later disabled. This could be done with a sub heading for each group, but is made difficult due to the labeling problem mentioned. For example what would the group label be for ‘should be closed’ and ‘duplicate’ options? They aren’t the same type of thing. We could change the 'should be closed' label to something else like 'Low quality', then use 'Should be closed' as the groups label.
• A simple/quick solution which doesn’t fix the underlying problem would be: for related disabled flags, change "You have already raised this type of flag" to "You have already raised a similar flag which may close this question".

Answer 2

IMHO this already is a good enough way to handle this situation in these particular circumstances.

Majority of users of this form will close for a single reason and won't see the message. This design solves a real problem that not all people need to understand that duplicate is a subcategory of close, so 5 options make this form more usable to most.

Out of the minority who see this message, some will understand because we have correct mental model in the first place. Out of the rest, some will not care. But there are millions of users, so there will still be dozens of those who will be puzzled enough with the mismatch of their mental model - and they have an option to JFGI https://www.google.com/search?q=%22you+have+already+raised+this+type+of+flag%22 as well as ask for clarification on the meta.

Maybe there is some wording of the message that would help. But any change requires testing and there might be unintended consequences that the wording would create a wrong mental model in some users who would then do some unintended action like reopening and reclosing the question or whatever...

Can you say the that current design is really that bad that it is worth to change? I would say that status quo is good enough.

Answer 3

Is this good design? Specifically why or why not? What would you change about it?

If you are referring to the flag states of deactivated with an error like state, then I would say this isn't a good solution.

The 'why not' springs from my understanding of how everyone reads from top to bottom and how in this example the user is presented a deactivated state flag that is then followed by the explanation. I would suggest moving the red type to above the section it is referring to, then add space above to separate from the section preceding it. This way the explanation as to why you aren't allowed to select that radial button is given rather than making the user hunt for it.