In 2020, I joined Qubole as a design intern, filling the spot of the quiet one in a team of four. Back then, Qubole was a bootstrapped startup on a mission to serve dataanalytics solutions to it's customers.
Every week we used to have a company wide workshop to brainstorm on problems that any of us felt was wasting user’s efforts. In one of those sessions somebody raised the issue of ‘Dependency Hell’. It was the first time I had heard the term, but to my surprise it was a common problem faced by almost everyone who did coding. Before I can explain the problem in a bit more detail, we need to understand what Qubole did.
what did Qubole do?
Qubole's primary goal was to helps its users analyse large amounts of data and derive meaningful insights to help businesses make decisions. The process involves multiple personas, and Qubole offered a variety of applications tailored to each part of the process. Data Engineers, Data Analysts, and Data Scientists used these applications to work on their part of the process.
Now as you have understood what Qubole did, let's delve into the problem.
As by now it must had became evidently clear that Qubole was majorly operated through coding. And the most common languages used for this were Python and R.
the problem
Python and R provide libraries of packages (bundle of codes each used for a specific function) that the users can install to save efforts of writing the whole set of code.
Each package comes with a set of dependencies like having to install a certain package or a certain version of a package (this could be a single or multiple packages at a time). And as the number of packages increase so do the dependencies which results in bugs, errors and programs running abnormally leading to a situation which in the coding world
is popularly known as 'Dependency Hell'.
As Qubole was a suite like Adobe that provided a bunch of applications. Each account was used by multiple users making it even more difficult to manage all the dependencies at once without ruining anyone's work.
wasn't a cakewalk
In order to mitigate this problem of dependencies among multiple users, we thought of isolating each user's packages hence removing conflicts. And with this we thought we solved it
but…
while this approach may sound promising, it wouldn't solve the whole problem as the individual users will still have to manage their own dependencies and along with that we would also be limiting the capability to share packages among each other which was a practise common between users.
On top of that, now as the system would have to manage packages for each user separately it would also increase processing hence ultimately increasing the operating costs as well.
what we did
After brainstorming and researching a lot about the domain, we came up with few solutions to tackle this problem.
restore to a previous state just like Figma
First of all we added a 'History' section which captures all the states of an environment throughout its timeline…moreover we added the capability for certain users (depending on the access level) to be able to restore any previous state of an environment. This enabled the users to rollback to a previous state for any dependency hell situations.
notifications
Secondly, we enabled each user with the capability to get notified of any changes happening to the environment to resolve the issue of ambiguity between users.
We also started notifying the users of any version conflicts that would arise in case of adding or updating packages.
visibility of dependencies
Lastly, we created a digital blueprint of all the packages in an environment along with the dependencies they had. This visually showcased of all the relations between packages. We called it 'Dependency Map'
how we did it
We started by revisiting the current workflows and asking numerous questions along the way. Additionally, we extensively researched 'Environments' and examined various scenarios involving dependency conflicts between packages.
gathering insights
Due to resource limitations, we couldn't access our customers directly for insights. Therefore, we turned to online research to gather user feedback, helping us understand the pain points of the problem.
ux audit
After thoroughly examining the application and receiving user feedback, we realised that the application needed an overhaul in terms of improved usability and intuitiveness.
We conducted a comprehensive UX audit of the entire 'Environments' section,
uncovering not only usability issues but also architectural problems that needed to be resolved to make Snapshots work effectively.
re-design
With the insights we gathered and our creative input, we redesigned the entire Environments application, aligning it with the current design system to ensure consistency
a happy ending
You know, what I learned from this project is that sometimes pushbacks from teams can actually lead you to something more meaningful. I want to give a special thanks to everyone who worked with me on this project because their input and collaboration really made a difference.
However, just when we were ready to move into the development phase, my internship came to an end. It was a bit disappointing because that's the part I was most looking forward to in a product development project. But you know what? Since then, I've been fortunate enough to be a part of several other projects, starting from the initial discovery all the way to development. It has been an incredible learning experience for me.
Aug 2020 | Duration: 3 months
Aug 2020 | Duration: 3 months
In 2020, I joined Qubole as a design intern, filling the spot of the quiet one in a team of four. Back then, Qubole was a bootstrapped startup on a mission to serve dataanalytics solutions to it's customers.
Every week we used to have a company wide workshop to brainstorm on problems that any of us felt was wasting user’s efforts. In one of those sessions somebody raised the issue of ‘Dependency Hell’. It was the first time I had heard the term, but to my surprise it was a common problem faced by almost everyone who did coding. Before I can explain the problem in a bit more detail, we need to understand what Qubole did.
what did Qubole do?
Qubole's primary goal was to helps its users analyse large amounts of data and derive meaningful insights to help businesses make decisions. The process involves multiple personas, and Qubole offered a variety of applications tailored to each part of the process. Data Engineers, Data Analysts, and Data Scientists used these applications to work on their part of the process.
Now as you have understood what Qubole did, let's delve into the problem.
As by now it must had became evidently clear that Qubole was majorly operated through coding. And the most common languages used for this were Python and R.
the problem
Python and R provide libraries of packages (bundle of codes each used for a specific function) that the users can install to save efforts of writing the whole set of code.
Each package comes with a set of dependencies like having to install a certain package or a certain version of a package (this could be a single or multiple packages at a time). And as the number of packages increase so do the dependencies which results in bugs, errors and programs running abnormally leading to a situation which in the coding world
is popularly known as 'Dependency Hell'.
As Qubole was a suite like Adobe that provided a bunch of applications. Each account was used by multiple users making it even more difficult to manage all the dependencies at once without ruining anyone's work.
wasn't a cakewalk
In order to mitigate this problem of dependencies among multiple users, we thought of isolating each user's packages hence removing conflicts. And with this we thought we solved it
but…
while this approach may sound promising, it wouldn't solve the whole problem as the individual users will still have to manage their own dependencies and along with that we would also be limiting the capability to share packages among each other which was a practise common between users.
On top of that, now as the system would have to manage packages for each user separately it would also increase processing hence ultimately increasing the operating costs as well.
what we did
After brainstorming and researching a lot about the domain, we came up with few solutions to tackle this problem.
restore to a previous state just like Figma
First of all we added a 'History' section which captures all the states of an environment throughout its timeline…moreover we added the capability for certain users (depending on the access level) to be able to restore any previous state of an environment. This enabled the users to rollback to a previous state for any dependency hell situations.
notifications
Secondly, we enabled each user with the capability to get notified of any changes happening to the environment to resolve the issue of ambiguity between users.
We also started notifying the users of any version conflicts that would arise in case of adding or updating packages.
visibility of dependencies
Lastly, we created a digital blueprint of all the packages in an environment along with the dependencies they had. This visually showcased of all the relations between packages. We called it 'Dependency Map'
how we did it
We started by revisiting the current workflows and asking numerous questions along the way. Additionally, we extensively researched 'Environments' and examined various scenarios involving dependency conflicts between packages.
gathering insights
Due to resource limitations, we couldn't access our customers directly for insights. Therefore, we turned to online research to gather user feedback, helping us understand the pain points of the problem.
ux audit
After thoroughly examining the application and receiving user feedback, we realised that the application needed an overhaul in terms of improved usability and intuitiveness.
We conducted a comprehensive UX audit of the entire 'Environments' section,
uncovering not only usability issues but also architectural problems that needed to be resolved to make Snapshots work effectively.
re-design
With the insights we gathered and our creative input, we redesigned the entire Environments application, aligning it with the current design system to ensure consistency
a happy ending
You know, what I learned from this project is that sometimes pushbacks from teams can actually lead you to something more meaningful. I want to give a special thanks to everyone who worked with me on this project because their input and collaboration really made a difference.
However, just when we were ready to move into the development phase, my internship came to an end. It was a bit disappointing because that's the part I was most looking forward to in a product development project. But you know what? Since then, I've been fortunate enough to be a part of several other projects, starting from the initial discovery all the way to development. It has been an incredible learning experience for me.
Aug 2020 | Duration: 3 months
In 2020, I joined Qubole as a design intern, filling the spot of the quiet one in a team of four. Back then, Qubole was a bootstrapped startup on a mission to serve dataanalytics solutions to it's customers.
Every week we used to have a company wide workshop to brainstorm on problems that any of us felt was wasting user’s efforts. In one of those sessions somebody raised the issue of ‘Dependency Hell’. It was the first time I had heard the term, but to my surprise it was a common problem faced by almost everyone who did coding. Before I can explain the problem in a bit more detail, we need to understand what Qubole did.
what did Qubole do?
Qubole's primary goal was to helps its users analyse large amounts of data and derive meaningful insights to help businesses make decisions. The process involves multiple personas, and Qubole offered a variety of applications tailored to each part of the process. Data Engineers, Data Analysts, and Data Scientists used these applications to work on their part of the process.
Now as you have understood what Qubole did, let's delve into the problem.
As by now it must had became evidently clear that Qubole was majorly operated through coding. And the most common languages used for this were Python and R.
the problem
Python and R provide libraries of packages (bundle of codes each used for a specific function) that the users can install to save efforts of writing the whole set of code.
Each package comes with a set of dependencies like having to install a certain package or a certain version of a package (this could be a single or multiple packages at a time). And as the number of packages increase so do the dependencies which results in bugs, errors and programs running abnormally leading to a situation which in the coding world
is popularly known as 'Dependency Hell'.
As Qubole was a suite like Adobe that provided a bunch of applications. Each account was used by multiple users making it even more difficult to manage all the dependencies at once without ruining anyone's work.
wasn't a cakewalk
In order to mitigate this problem of dependencies among multiple users, we thought of isolating each user's packages hence removing conflicts. And with this we thought we solved it
but…
while this approach may sound promising, it wouldn't solve the whole problem as the individual users will still have to manage their own dependencies and along with that we would also be limiting the capability to share packages among each other which was a practise common between users.
On top of that, now as the system would have to manage packages for each user separately it would also increase processing hence ultimately increasing the operating costs as well.
what we did
After brainstorming and researching a lot about the domain, we came up with few solutions to tackle this problem.
restore to a previous state just like Figma
First of all we added a 'History' section which captures all the states of an environment throughout its timeline…moreover we added the capability for certain users (depending on the access level) to be able to restore any previous state of an environment. This enabled the users to rollback to a previous state for any dependency hell situations.
notifications
Secondly, we enabled each user with the capability to get notified of any changes happening to the environment to resolve the issue of ambiguity between users.
We also started notifying the users of any version conflicts that would arise in case of adding or updating packages.
visibility of dependencies
Lastly, we created a digital blueprint of all the packages in an environment along with the dependencies they had. This visually showcased of all the relations between packages. We called it 'Dependency Map'
how we did it
We started by revisiting the current workflows and asking numerous questions along the way. Additionally, we extensively researched 'Environments' and examined various scenarios involving dependency conflicts between packages.
gathering insights
Due to resource limitations, we couldn't access our customers directly for insights. Therefore, we turned to online research to gather user feedback, helping us understand the pain points of the problem.
ux audit
After thoroughly examining the application and receiving user feedback, we realised that the application needed an overhaul in terms of improved usability and intuitiveness.
We conducted a comprehensive UX audit of the entire 'Environments' section,
uncovering not only usability issues but also architectural problems that needed to be resolved to make Snapshots work effectively.
re-design
With the insights we gathered and our creative input, we redesigned the entire Environments application, aligning it with the current design system to ensure consistency
a happy ending
You know, what I learned from this project is that sometimes pushbacks from teams can actually lead you to something more meaningful. I want to give a special thanks to everyone who worked with me on this project because their input and collaboration really made a difference.
However, just when we were ready to move into the development phase, my internship came to an end. It was a bit disappointing because that's the part I was most looking forward to in a product development project. But you know what? Since then, I've been fortunate enough to be a part of several other projects, starting from the initial discovery all the way to development. It has been an incredible learning experience for me.
Aug 2020 | Duration: 3 months