Am 23.02.2018 um 11:54 schrieb Edward Welbourne:
>> The proposed system provides anonymised and presumably aggregated
>> data; so you won't be given, much less asked to evaluate, information
>> about a specific user A doing things at a specific time B; your
>> objection is a straw man. You'd be getting data on what proportion
>> of users spend what proportions of their time doing which things. In
>> particular, knowing which bugs bite most users most often might not
>> be entirely useless when it comes to prioritising which bug to fix
>> first.
Robert Loehning (23 February 2018 15:59)
> If many users spend much time doing a "thing", does that mean that
> this is most important to them? Or that it is most fun to do? Or does
> it just mean that the design is so bad that they lose lots of time
> there and can't use it efficiently?
You don't necessarily know - but you do at least know it sees a lot of
use, as distinct from the things that no-one uses. That, in turn, might
be because the thing doesn't work, or is too confusing; or it might mean
it does a thing no-one feels any need to do. However, you have now
separated two classes of feature from one another: you won't waste time
asking users why they never use the heavily-used feature; and you won't
assume that users know how to use the feature you know none of them use.
You'll have more information along with just "what proportion use which
features what proportions of the time"; some of this may help you to
distinguish between the various possible explanations. When you look
into the feature that no-one uses much, you may find that most users
that do use it have a crash report following close on the heels of their
use of it; you can make an educated guess at why they don't use it after
that. For another feature, users may methodically work their way
through the steps your tutoral for the feature outlined and never touch
it again; it's probagly useless.
You won't be throwing away your other ways of getting information from
users; you can ask them, in all the usual ways, what they like best and
what ticks them off about each feature. That's quite likely to
distinguish, among the ones that are commonly used, the ones that are
fun from the ones that are time-consuming pain points.
Data on how your users use your product can contribute to your
understanding of what questions to ask your users and what work to
prioritise. Like all data, of course, you have to use it intelligently
to get actionable information out of it; the possibility that you might
misunderstand it doesn't mean it's worthless; it *supplements* the other
sources of insight into how best to use your time, it doesn't replace
them.
All of which, of course, does depend on taking care that the process of
collecting the data does not, in itself, cause greater harm than the
benefits that you can glean from using the information, once collected,
Eddy.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
