Problem

Atlas has a very large free tier, but only a small share of those users ever move to a paid plan. The Growth team needed to know what holds them back, and whether developers who build with AI tools behave differently from everyone else.

Evidence

I interviewed ten active users, split between long-term free-tier users and recent upgraders, half of them heavy AI users. I then surveyed 104 users to test which patterns held at scale.

The findings themselves are confidential to MongoDB and are not disclosed here.

Options and decision

I turned the findings into twelve opportunities in three groups, then ran a workshop with Growth stakeholders to place each one by effort and expected impact.

Outcome

The internship ended with the final readout, so nothing has been tested or decided yet. The Growth team left with the findings, a ranked map of opportunities and a list of paths to research and test next.

What I'd do next

The survey sample was too small to give statistically firm answers, so I would rerun it at larger scale. In parallel I would test the low-effort ideas as small experiments before committing to the expensive ones.

Problem

Withdrawing cash is routine for most people and a real obstacle for visually impaired users. Where does the card go? Where are the buttons? Is someone looking at my information?

Evidence

We ran interviews and ethnographic observation with visually impaired users to find where the ATM experience breaks down. One finding shaped everything after it: most blind users are expert screen-reader navigators on their own phone.

Decision

We moved the interaction off the machine and onto the user's phone. Cards are stored in a wallet inside the app, and the whole withdrawal is done through screen-reader navigation, a skill these users already have.

What we built

After an ideation phase we designed the app as a low-fidelity and then a high-fidelity prototype in Figma.

Open the prototype in Figma →

Outcome

We evaluated the prototype with 7 visually impaired users to judge how well the app and its interaction worked, and which parts had to be redesigned.

The evaluation went well: the app worked for them, and most participants were optimistic about using it in a real-life setting.

What I'd do next

Integrate the app with existing mobile banking apps and with real ATMs, so the withdrawal works end to end outside a prototype.

Problem

Feedback helps people correct their balance, which matters for motor recovery. We wanted to know whether two kinds of feedback at once, vibration and sound, work better than each one alone in a balancing task.

What we built

A balance board that rocks along one axis, fitted with a motion sensor that reads how fast it tilts. The board controls a space-themed game where the player steers an astronaut along a set path. Two sets of vibration motors and a loudspeaker tell the player when they drift off course.

How we tested it

We ran a study with 16 participants and scored each run on two metrics: path accuracy, and how closely the player's path matched the target (path similarity). Afterwards, the session data was analysed in R.

Outcome

The results aligned with the Principle of Inverse Effectiveness, which states that multimodal feedback has the greatest impact when responses to each single mode of feedback are weak. In practice, combined feedback helped most the participants who struggled with a single type.

The paper was accepted at the CHItaly 2025 conference, and the project received maximum marks in the course.

What I'd do next

The haptic feedback was set up so that a signal on the left meant the user should rotate away from the left. I would test whether reversing this, so that users rotate towards the source of the feedback, changes the results.