Injecting user interaction design in the journalist interface

UX
1

Bonjour,

During the UX meeting last Friday @eloquence suggested it would be useful to dig into the shared inbox and the proposed changes to this model.

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 :wink:

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?

2

Thank you for starting this conversation, @dachary! I’ve previously worked with UX, user research and analytics teams, and I agree that iterative development with continued validation helps us to avoid accidentally missing the mark when we change the UI. I’ve also extensively used low-cost user testing services like https://www.usertesting.com/ which, while reaching a non-specialized audience of testers, can be useful for the general “does this UI make sense” question. (You can offer your testers instructions, like “Imagine you are a whistleblower trying to leak a document.”)

Ideally we’ll align our product planning and our UX work, so that, for example, the UX team knows that we’ll tackle journalist workflow functionality soon [just an example, see *], and can work a few weeks ahead of time to build and validate some prototypes/wireframes, then work with the team during the sprint to validate the actual implementation. I understand the issue of fluctuating availability, hence the “ideally” in the above sentence.

Pau Giner, one of Wikimedia’s UX designers, publishes most (all?) of his interactive prototypes online, and has also blogged extensively about the practice. I would encourage anyone interested in prototyping to play with these examples:
http://pauginer.github.io/prototypes/

As you can see, many of his prototypes are quite sophisticated. But having this kind of interactive prototype that you can send to a tester (specialized or not) for feedback is incredibly valuable, and because only the bits you want to focus on are there, it’s very quick to tweak and re-validate.

[*] On the issue of journalism workflows specifically, to be clear, we haven’t decided to tackle functional changes soon; my personal bias is that we’ll want to achieve at least a near term win in this area, while shifting the bulk of this effort to the Qubes OS workstation. But we’ll need to talk more about that together.

2 Likes
3

Hi @eloquence

Thanks for pointing to Pau’s work. Interestingly, I have been working very much in the same way (see http://belenbarrospena.github.io/patchwork-redesign/index.html and https://belenbarrospena.github.io/sreview_design/ for a couple of examples). I’d be happy to help with prototyping so that we can validate and iterate designs with users before building them.

I tend to combine this kind of activity with more exploratory research that builds contextual knowledge about users. Things like the interviews that were done at IFF, for example. In my experience, those can provide very useful insights for prioritising feature development, and also for design of course :slight_smile:

Looking forward to working together!

1 Like