Thinking about misunderstandings (in systems)
One of the things that I am trying to do now with the web application I'm building is to think about how people may misunderstand and misinterpret it.
When I create a system I know how it's supposed to work and be used to do particular things, and I write the code and create the interface to fit this. Of course, how to use the system is clearly obvious to me. But it's not necessarily clearly obvious to other people, and so I need to turn a sceptical eye on my own work and ask myself what people could get wrong. What perfectly reasonable alternate interpretations could they put on the labels of the interface? If they are starting from scratch, without my knowledge of the system, how would they try to do some particular operation that they want to do? Once I've figured this out, I can go in and fix the system in various ways so that these foreseen potential misunderstandings won't cause problems.
All of this sounds really wishy-washy and theoretical, so I'll give you a practical example drawn from the new account request system.
In the system, the normal situation is that people basically request accounts from some particular sponsor. That sponsor can then ignore them, approve their request, or reject it, and so the sponsor interface offers those choices. Now, when a bunch of new graduate students are accepted there is a somewhat different procedure to get pre-approval from all of their various supervisors to be; the Graduate Office enters a list of new students and their supervisors, the requests are sent to the supervisors for approval, and when they are approved, the new students are prompted to complete their account request by providing a login name.
It sometimes happens that the Graduate Office data on who is supervising a new student is wrong. When this happens, what my design wants the supervisor to do is to change the student's sponsor; if they know who the correct supervisor is, they can directly change the sponsor to it, and if not they can send the student back to the Graduate Office. There is a procedure for this, and help text telling the supervisors to do this.
When I was looking at this recently, it struck me that a completely natural thing for a supervisor to do instead was to reject the account request. After all, they're not sponsoring the student. This was bad, because a rejected request disappears entirely (rejection is assumed to be a permanent condition). My fix was to change the code so that if a sponsor rejected a request that looked like an incoming grad student, the request was instead quietly reassigned back to the Graduate Office.
(It's also now obvious to me that the system needs a somewhat convenient way to undo rejections; sooner or later, someone is going to make a mistake.)
Sidebar: one view of this misunderstanding
The classical view of this sort of misunderstanding is that the users have a different conceptual view of the system than the designer does. In this case the mismatch comes from the sponsor having a local view of their actions, when the system actually has a global view. To the sponsor, 'reject' just means that they reject the request; to the system, 'reject' means that the request is rejected, period, globally.
The challenge here is that sometimes the local action of 'I reject this request' implies the global action and sometimes it doesn't. When people make requests themselves, their listed sponsor rejecting them means that their request goes down in flames. But for new graduate students, really only the Graduate Office gets to declare that a request is invalid for some reason (the student has declined our offer, for example).
(If I wanted to complicate my schema design instead of just doing some code hacks, this suggests that I could give account requests an 'owner' field. 'Reject' would only have global effect if done by the owner; otherwise, it just reassigns the request back to the owner.)