It was an interesting research and made me realize that we need a methodology to decide on journalist workflow changes. Luckily, with the work done by the UX team in the past weeks, that’s more or less what we are doing. Only we did not declare something as dramatic as this is our methodology
As a developer I must confess I tend to hate administrative overhead and deciding on a methodology needs to have serious benefits compared to let’s just patch the code because a user said something that sounded sensible. I vividly remember a remarkable case where, based on this patch away practice, I introduced something in SecureDrop that made the life of sources more confusing instead of simpler during a release. It went like this:
- In the past, when the source decided to submit a document for the first time (as opposed to checking for messages using a passphrase), the page asked them (again) if they wanted to use a passphrase. A contributor submitted a patch changing the language of the question to avoid confusion. That sounded reasonable to me and I approved and merged the change.
- After the release of that change, two SecureDrop users came to me and said the language was misleading. And when the explained why, it struck me: it was worse than before. I was too much into SecureDrop to even see how confusing it was for a new user.
- I tried to come up with a better language, asked around and then it struck me: the problem was not in the language, it was in the workflow. It went as follow:
- On the home page, the sources were asked to decide if they want to publish a document for the first time or if they wanted to check for replies
- After the sources decided to publish a document for the first time, they were asked again if they wanted to check for replies, but in a different way
- I proposed a patch to remove the redundant question from the source interface, therefore changing the workflow instead of the wording.
It looks like it was the right decision but I now see it was really not the right way to handle that problem. It may have taken longer to conduct some user research but it would have saved the user the pain of a regression (i.e. introducing a change that made the confusion even worse).
Another benefit of a proper methodology would be to allow us to challenge all our decisions. And I would like to start with the webmail metaphor we currently have for the journalist interface. What if a communication channel metaphor provides a better user experience? To illustrate what I mean by communication channel, imagine the journalist workflow goes like this:
- Boot Tails with persistence activated and a USB storage key attached to it
- A GUI shows on the desktop displaying the progress of downloading unread documents/messages (it is a communication channel over which the journalist has no control).
- When it completes the journalist unplugs the storage key and move it to the SVS
- On the SVS the journalist opens the documents.
I’m not saying this is a better metaphor. I’m saying we did not challenge the current metaphor, we don’t have user research explaining why it is justified, we did not compare it with other metaphors and we did not publish a rationale to remember why we should keep the webmail metaphor. I am convinced this is a conversation we need to have now.
What do you think?