In the last meeting of the UX workgroup we talked a bit about the need for retroactively documenting rationales for certain features: why did we decide that a certain feature was a good idea? What evidence did we have to support it?
Separately, at FPF, we are gearing up to spend more effort towards the development of the SecureDrop Workstation based on Qubes OS. The SecureDrop Workstation consolidates the Secure Viewing Station and the Journalist Workstation of the current implementation of SecureDrop into a single device; it may become an alternative to the current SecureDrop experience if we can fully validate that this approach works.
As a first step towards better understanding
what features we might need in the workstation
where we have high/low confidence about these features, based on previous conversations with users (or lack thereof),
Jen (@redshiftzero) and I have put together a first draft for “User Stories” for the new SecureDrop Workstation. These user stories are useful for discussions within FPF, but with some additional work they may also help inform the work of UX volunteers who wish to get involved in user interviews, wireframing/prototyping, etc.
Covered in web UI and available via API (on branch), but not implemented in workstation: We have an experimental API for the journalist interface of SecureDrop (journalist-api branch in the main SecureDrop repo; issue 1761). Tracking what is and isn’t in the API is important, because the SecureDrop Workstation will likely increasingly rely on it (for building a GUI as an alternative to the web interface).
Not covered in SecureDrop: As the note in the document says, a lot of this is achieved right now via the baseline functionality of the Tails workstation, as opposed to SecureDrop itself. But Qubes OS provides a very different baseline of features, so we have to re-validate some user stories, and also re-examine whether the original approach (of asking journalist to, e.g., use the Nautilus file manager to organize submissions) makes sense.
In addition, for the stories that aren’t implemented yet, “high confidence of value” means that there’s at least some institutional memory around a given story: We are quite sure this is something journalists will need. Some of these stories are self-evident: it’s clear that journalists will need some way to download documents, for example. “Low confidence of value” means we believe we really need more research to validate our assumptions.
How can we work with this? Well, this is a draft, open to discussion and revision. Jen and I will talk about it with Josh, who built the SecureDrop Workstation prototype. But we’d also love broader input: What are we missing? Do the stories as written make sense? And perhaps we can use this as a baseline for some research with news organizations.
Look forward to discussing more here, and in future UX meetings! And please be bold in editing the wiki page.
The current SecureDrop journalist workflow grew over years, in an organic way, including excellent intuition and by talented people. It would have benefited from user research, of course. But considering there was no user research at all, the result is quite remarkable.
I propose user research is conducted from scratch on the journalist side of a whistleblower submission system (i.e. we forget about SecureDrop). We will get a better understanding of the mental model of a journalist in this context. And based on that we will try to adapt the SecureDrop conceptual model to be a better match. Yeah, I know, I use big words but that’s because I’m new to UX
Assuming Qubes is part of SecureDrop on the journalist side and conducting user research to explain why is backwards. User research must come first and it will be allow us to explain why and how Qubes helps. Or not.
First, thank you again for the interviews you have already done; I spent some time today reading through all the transcripts that have been completed, and they’re extremely helpful!
I don’t think the stories on the wiki page are predisposed towards any particular solution. User stories like “I want to securely talk with the source and ≥1 other journalists in a single conversation, so that we can communicate and collaborate effectively.” are pretty generic. Many of them could be implemented within the current SecureDrop architecture, or in completely different architectures. They just happen to be organized for us internally in a way that’s helpful for workstation development.
I do believe interviews with journalists who are currently using SecureDrop, or who are using a different process for handling whistleblower submissions, are a useful way to validate/check our assumptions. I agree that such interviews need not reference the workstation at all. For example, by reviewing one of your transcripts it became clear to me that a way to organize decrypted submissions by recency is likely an important user story we’re currently missing.
I would suggest that, in addition to the questions in the current interview script, it is useful to ask explicitly about some of the low confidence user stories – again, this can be done without reference to any specific implementation. The combination of open ended high level questions followed by specific validation questions should help us with all elements of the decision-making process, from strategic decisions (which architecture to use) to tactical ones (which features to implement).
Naturally, the level of specificity that makes sense for an interview depends on the user’s familiarity with SecureDrop specifically and whistleblower submissions in general.
For FPF’s part, we have a couple of interviews we’re lining up for this month. These will be with experienced SecureDrop users. Would love to talk more about the approach we’ll take for those interviews in the next UX meetings, and discuss opportunities to collaborate on additional sessions.
I think they are. For instance imagine the mental model of the journalist is very similar to the one they have when they use a mailbox which they read with thunderbird. Each source is the sender of text messages in the body of the message, possibly with attached files. The following:
I want to securely talk with the source and ≥1 other journalists in a single conversation, so that we can communicate and collaborate effectively
fits perfectly. But having that in the list:
Covered in web UI and available via API
assumes there is an API/UI that is different from a POP/IMAP server. But why would such an API be a conceptual model that better serves the above mental model? I think it would be really useful to challenge these assumptions.
Again, I think there’s some confusion between the user stories vs. the categorization of those stories on that page. That’s perhaps a flaw of the way the information is currently presented. I’m happy for us to organize user stories in a different way that decouples them a bit more from possible implementation details – these implementation details were just useful for us to capture here, since FPF is committed to continuing work on the Qubes OS pilot (as a pilot - no decision has been made beyond that).
FPF commitment will be better served by a user research that shows where the Qubes OS piliot fits. Noone will blame FPF for doing their homework. Worst case scenario user research shows it is not worth doing and it will save time for everyone. Best case scenario everyone will know why journalist need it, how they will use it and it will allow us to move forward with enthusiasm
