User testing and community feedback for VeraCrypt support
This is “A.8 User testing & community feedback”:
- Doing in-person user testing. This will be suited to identify UX issues in our design.
- Asking for feedback online through our blog and Twitter. This will help us identify bugs in our software implementation.
- Analysis of WhisperBack reports, to identify both technical and usability issues.
|Feature #14481: Release Beta for VeraCrypt support in Tails||Resolved||
|Feature #15589: Process community feedback||Resolved||
|Feature #15966: Include list of device-mapper devices in debug output||Resolved||
#4 Updated by intrigeri 2017-09-29 17:28:11
- Description updated
I wonder how the “identify UX issues in our design” part should relate to upstreaming code: on the one hand we want to upstream stuff ASAP. OTOH it would be lame to upstream something and come back to it 2 months later saying “sorry, user testing proved that our design was bad, here’s a new one”. Perhaps the 2 tickets we have about upstreaming user-facing stuff should take this into account so we can tell upstream when submitting our initial PR that the design will be user tested and improved later if needed, which might give us the best of both worlds :)
#8 Updated by sajolida 2017-10-03 15:10:21
Yeap. In addition to what you are proposing, note that we will have a first round of user testing when designing the interface during the UX sprint in November. There we will do paper testing to quickly iterate on our initial ideas. The objective by then is to have a “good design”: a solid basis that works and won’t change too much. After the beta and user testing of it we will improve the current design but not question it completely; otherwise we’d screwed up badly during the UX sprint in November.
So hopefully, the improvements coming out from the test of the beta version can be formulated as such to upstream (“improvements” and “bug fixes” and not “complete redesign of a bad design”).