Mobile/Projects/Quickshare: Collect aggregate usage data: Difference between revisions
Jump to navigation
Jump to search
m (→Goals) |
m (→UX design) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 9: | Line 9: | ||
== Use cases & user stories == | == Use cases & user stories == | ||
* When we have implemented multiple Quickshare buttons and Quickshare defaults, I want to collect usage information about the Quickshare feature as a whole so we can tweak or redesign the feature to better support user needs. | * When we have implemented multiple Quickshare buttons and Quickshare defaults, I want to collect usage information about the Quickshare feature as a whole so we can tweak or redesign the feature to better support user needs. | ||
* ''FOR DISCUSSION ONLY'' Possible data points to collect: | * ''FOR DISCUSSION ONLY'' Possible data points to collect: | ||
** How many users actually use Quickshare at all | ** How many users actually use Quickshare at all | ||
** How often users use Quickshare over various periods of time | ** How often users use Quickshare over various periods of time (day/week/month) | ||
** Which services users use in the Quickshare feature | ** Which services users use in the Quickshare feature | ||
** How many & how often users use the default services we set for the Quickshare feature | ** How many & how often users use the default services we set for the Quickshare feature | ||
| Line 23: | Line 21: | ||
== UX design == | == UX design == | ||
* Not handed off yet | * Not handed off yet | ||
== Justification == | |||
* Ensuring user value - having a better understanding of what people do (and don't do) with the Quickshare feature will allow us to change or optimize the feature to better support real-world use cases. This supports our marketshare and pre-install goals. | |||
* Supports third-party service integration drive - understanding how users actually use this feature will help us explain the value of the feature (assuming data shows its valuable!) to potential third-party service integration partners. This potentially supports our rev-share and co-marketing goals, as well as (eventually) our WebApp/ecosystem goals. | |||
== Quality criteria == | == Quality criteria == | ||
Latest revision as of 14:31, 16 December 2013
Tracking
- Meta-bug to be filed
Goals
Our Quickshare feature is great -- or so we think. We want to start collecting usage data for this feature so we can better understand how users actually use it, and how we might better design the feature to support them.
Whether this is something we do in FHR or as part of Telemetery or something else is to be determined.
Use cases & user stories
- When we have implemented multiple Quickshare buttons and Quickshare defaults, I want to collect usage information about the Quickshare feature as a whole so we can tweak or redesign the feature to better support user needs.
- FOR DISCUSSION ONLY Possible data points to collect:
- How many users actually use Quickshare at all
- How often users use Quickshare over various periods of time (day/week/month)
- Which services users use in the Quickshare feature
- How many & how often users use the default services we set for the Quickshare feature
- How many users end up with different services as their default Quickshare services over time
- How many users manually set their own defaults for their Quickshare services
- How many users manually unset their own defaults for their Quickshare services
UX design
- Not handed off yet
Justification
- Ensuring user value - having a better understanding of what people do (and don't do) with the Quickshare feature will allow us to change or optimize the feature to better support real-world use cases. This supports our marketshare and pre-install goals.
- Supports third-party service integration drive - understanding how users actually use this feature will help us explain the value of the feature (assuming data shows its valuable!) to potential third-party service integration partners. This potentially supports our rev-share and co-marketing goals, as well as (eventually) our WebApp/ecosystem goals.
Quality criteria
- No user-perceptible performance degradation
- All goals are met
- All user stories are implemented & tested