🇪🇸 Este post está escrito en inglés y español. Puedes encontrar el texto en español más abajo.
🇺🇸 Your ultimate goal while working as a researcher or data scientist is to communicate findings that contribute to making decisions. Your audience, partners, and decisions will depend on your context. Yet the goal is the same regardless of your context.
Much of our training as researchers and data scientists is focused on fancy stats and data viz tricks. We call these insights, without much hesitation. But an insight should not be confused with a table or a plot. An insight is a change in understanding (here’s a fun article on the topic). It’s something you find while making meaning of data in a table or a plot that will change your or other people’s understanding of things.
A lot of people start by thinking about the analyses they will run, the tables they will create, or the plots they will design. Fewer people take a step back and start by thinking about the container of their findings (slides, report, dashboard, etc.). Even fewer people take another step back and ask themselves: “What do I want my audience to learn?” This is a loaded question, but it is a better starting point than thinking about analyses or containers. This question helps you focus on learning or the change in understanding that you need to promote.
Before writing a single line of code, ask yourself:
Who is my audience and what do they care about?
How will my audience and I make decisions based on insights? What is the process like?
What type of delivery will help my audience prepare to make decisions based on our process?
Only once you have answers for these questions you should start designing your workflow. These answers will tell you the kind of output you need, and thus, the type of workflow you need to generate such output.
If you don’t start by answering these questions, you are likely to create a messy workflow that is hard to document, reproduce, and scale. This is because you won’t have a clear goal in mind for each file and line of code. And in my experience, starting a workflow without a clear goal takes you in many directions. Your code ends up looking like a collage; a collection of pieces that barely fit together and are difficult to reproduce by other people (even your future self).
🇪🇸 Tu objetivo final como investigador(a) o científico(a) de datos es comunicar hallazgos que contribuyan a tomar decisiones. Tu audiencia, colegas y decisiones dependerán de tu contexto. Sin embargo, el objetivo es el mismo independiente del contexto.
Gran parte de nuestra formación como investigadores(as) y científicos(as) de datos se centra en estadísticas sofisticadas y trucos de visualización de datos. A estos los llamamos insights, sin mucha vacilación. Pero un insight no debe confundirse con una tabla o un gráfico. Una idea es un "cambio en la comprensión" (aquí hay un artículo interesante sobre el tema). Es algo que encuentras mientras das sentido a los datos en una tabla o un gráfico que cambiará tu comprensión o la comprensión de otras personas sobre un tema.
Muchas personas empiezan pensando en los análisis que llevarán a cabo, las tablas que crearán o los gráficos que diseñarán. Algunas personas dan un paso atrás y comienzan pensando en el "contenedor" de sus hallazgos (diapositivas, informe, dashboard, etc.). Y una minoría de las personas dan otro paso atrás y se preguntan: "¿Qué quiero que aprenda mi audiencia?" Esta es una pregunta compleja, pero es un mejor punto de partida que pensar en los análisis o contenedores. Esta pregunta te ayuda a enfocar tu atención en el aprendizaje o el "cambio en la comprensión" que necesitas promover.
Antes de escribir una sola línea de código, pregúntate:
¿Quién es mi audiencia y qué les importa?
¿Cómo tomaremos decisiones mi audiencia y yo basándonos en los insights? ¿Cómo es el proceso?
¿Qué tipo de entrega ayudará a mi audiencia a estar preparada para tomar decisiones basadas en nuestro proceso?
Solo una vez que tengas respuestas para estas preguntas debes comenzar a diseñar tu workflow. Estas respuestas te dirán el tipo de resultado que necesitas y, por lo tanto, el tipo de flujo de trabajo que debes generar para obtener dicho resultado.
Si no empiezas respondiendo estas preguntas, es probable que crees un flujo de trabajo desordenado que es difícil de documentar, reproducir y escalar. Esto se debe a que no tendrás un objetivo claro en mente para cada archivo y línea de código. Y en mi experiencia, iniciar un flujo de trabajo sin un objetivo claro te lleva en muchas direcciones. Tu código termina pareciendo un collage; una colección de piezas que apenas encajan y son difíciles de reproducir por otras personas (incluso tu "yo" futuro).