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.
As you can see, it’s organized at a high level in sections, e.g.:
Covered in current SecureDrop Workstation prototype: This is what you can find in the Qubes OS SecureDrop Workstation prototype totday
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.