Read on Twitter
1/ Most designers are not capable of analysing quantitative data. And it's not entirely their fault. A thread 
2/ Even basic analysis of business/ user data is "perceived" as a complicated task.
Problem: It's perceived to be complicated because the tools provided are.
Problem: It's perceived to be complicated because the tools provided are.
3/ Folks would eventually stop asking better, questions - and eventually give up if the tools to do so are difficult and have high-friction entry point.
4/ The perception in engineering and design teams about data analysis of any kind is that it's to be done either by PMs or Data Analysts.
Problem: Unnecessary dependency creation that slows everyone down.
Problem: Unnecessary dependency creation that slows everyone down.
5/ A lot of designers I speak with still need to raise requests to specific teams/ folks to get information (or insights).
The problem: While raising requests, one is expected to know the pointed question to ask. It defeats the purpose of data-exploration for insights.
The problem: While raising requests, one is expected to know the pointed question to ask. It defeats the purpose of data-exploration for insights.
6/ Suggestion:
a. Data literacy:
If you're a PM, Data custodian, educate teams on what's being captured, what data are available, how to use them (with examples)
a. Data literacy:
If you're a PM, Data custodian, educate teams on what's being captured, what data are available, how to use them (with examples)
7/ Suggestion:
b. Enable self-serve and de-centralise:
Enable other teams to do analysis by themselves.
Don't do it by asking them to write scripts. Do it by putting better tools (Mixpanel etc.) in the infrastructure.
b. Enable self-serve and de-centralise:
Enable other teams to do analysis by themselves.
Don't do it by asking them to write scripts. Do it by putting better tools (Mixpanel etc.) in the infrastructure.
8/ Suggestion:
c. Make data part of design toolkit, not a driving factor:
Just like one'd take research insights, business insights while designing solutions, take data as an input as well; not necessarily as a driving factor.
c. Make data part of design toolkit, not a driving factor:
Just like one'd take research insights, business insights while designing solutions, take data as an input as well; not necessarily as a driving factor.
