Understanding users that use notebooks.

[NeroOkwa]

Description

From the non-technical user research #1280 we discovered a group of 'low-code' users that only use notebooks ( e.g. Data Analyst, J. Data Scientist, Researchers). This is a sizeable group (estimated at 70%) within data teams.

The goal is to learn about this user persona: pain points, needs, user journey and workflow. This would be towards optimising the Kedro experience for their use case.

Context

This ticket is part of a larger initiative to increase the usage of Kedro-Viz and hence Kedro framework, by supporting this user base. It builds on the findings in #1280.

This ticket has implications for #1279 and #1116.

Outcome of this ticket

This ticket proposes designing the research study and completing recruiting for it. It will define the research outputs we need to move forward, and who we will be talking to.

[astrojuanlu]

Would love to participate in this, or shadow in interviews

[amandakys]

One part of this research relevant to Kedro would be to understand:

• Why they might want to view their Jupyter notebook project in Kedro Viz (what are the incentives?)
• When in a project's life cycle do users seek to make this transition
• How users might currently move from a Jupyter Notebook project to Kedro Viz

At the moment, usage of Kedro Viz is dependent on users having a functioning kedro pipeline. Therefore, in order to enable a jupyter notebook user to use kedro viz, an initial step would be to understand the "minimally viable kedro" that we can create out of an existing project using jupyter notebooks that will enable Kedro Viz deployment. This is related to our existing standalone datacatalog feature, and other open tickets:

• Incremental Starter #2054
• Minimal Kedro Adoption #2512
• Methods to refactor projects to use Kedro #2820

Relevant to this is discussion on whether supporting kedro integration onto existing projects is more a technical problem requiring a technical solution (like supporting a dynamic/automated integration) or a documentation problem requiring better education on the steps users need to take to integrate kedro, and clearer communication on what represents "minimally viable kedro" without using kedro new. (@merelcht just bringing to this your attention)

Alternatively, as part of this research we could also look into the viability and justifications for a direct Jupyter -> Kedro Viz flow. But I feel this warrants further discussion on the future of Kedro-Viz's dependency of users having a full kedro pipeline