intrigeri:
> What follows should be of some interest to our developers, help desk,
> UX people, and more. I don't want to do a huge cross-post, so let's
> discuss the general bits here, and if you feel there's something in
> there that could/should be handled by your own team, please forward it
> to them (and Bcc -project@ once to make it clear that you're moving
> the discussion away from here).
For me that's definitely UX :)
> In square brackets I'll add some comments of mine wrt.
> how we're doing.
>
> 1. It's important to have communication channels with users, and to
> process their feedback [I miss the reports from help desk to -dev@
> that were meant to help developers understand what the user experience
> looks like.] Some feedback could be prioritized, e.g. what comes
> from trainers.
It's part of the objectives of the ticketing system for our help desk to
improve on the feedback loop with developers, be able to inspect better
singular problems and also aggregate data on which issues are the most
common, the most painful, etc.
> 2. We need both a good understanding of who our current user base is, and
> a vision of who our project wants to better serve (target user base).
> Both. Then 80% of our efforts should be directed towards our *target*
> user base, and 20% to existing users. Stating non-goals explicitly can
> be useful as well.
Regarding knowing better our user base, it's partly what I had in mind
when starting researching survey platforms [1]. That seems our best bet
to have quantitative data about our user base.
[1]:
https://mailman.boum.org/pipermail/tails-ux/2016-December/003312.html
> 3. It's useful to *also* gather general, non-bug feedback. [Do we
> advertise any way to do that?] One way to gather this would be a blog
> post about the state of the project that says we are looking for
> feedback and asks very few questions (with an end date):
>
> * what's the most painful aspect of Tails for you?
> * what's the part of Tails you love most?
See "Intercept Interviews" in the Needfinding framwork of Second Muse
[2]. Practicing this and gathering some first feedback is part of my big
objectives for my next conference (IFF probably). I'm sure yet but I'll
try to have a way of making these public, after anonymizing and getting
consent from the interviewees.
http://internetfreedom.secondmuse.com/wp-content/themes/needfinding-overview/assets/if_framework_low.pdf
Another tool we should use is to analyze better the logs of our website.
Even if they have no IP in them and will provide way less info than the
usual spyware analytics tools they would give us info on search terms,
where people are coming from, what they do most on our website, shares
of favorite language, etc.
> Another way would be to provide a way to send non-bug feedback from
> Tails itself.
>
> So far, we've mostly have done quite heavy-weight usability research.
> We could benefit from quick and crappy user studies, e.g.:
>
> * at conferences, his can last 5 minutes / person;
> * propose one bug reporter each month to answer a few questions;
That's a good idea!
> * the aforementioned blog post asking for feedback;
> * a blog post looking for users who are fine with being interviewed
> (offer them a t-shirt?).
>
> We could ask them what are the top 3 things in Tails, what are the bad
> parts. We should shut up, listen, and thank them.
>
> 4. Rephrasing the WhisperBack bug report template
>
> The sentences should be along the lines of:
>
> * What were you doing?
> * What did you expect to have happened?
> * What happened instead?
Now I'm seeing these four data gathering tools (ticketing system, web
log analysis, survey platform, and interview archive) as a possible
bundle for some grant :)
