A two-month design thinking engagement at Lenskart, working directly with the CTO, to understand why users were deleting the app within 30 days of installing, and to design new retention-focused use cases beyond the original try-and-buy AR feature.
Lenskart's app had a standout try-and-buy AR feature that users genuinely loved on first use. The feature let users see how different frames would look on their face using AR, which was novel in 2019 and produced the kind of word-of-mouth that drives downloads. The download metrics were healthy. The first-session engagement was strong. The reviews were positive.
The problem was what came after that first use. Users were deleting the app within roughly 30 days because the value proposition stopped existing once they had bought their glasses. The app was, in effect, a one-shot product. You used it, you bought your glasses, you uninstalled. The headline feature that drove acquisition was also the feature that capped retention, because it had no reason to be used a second time.
The brief from the CTO was direct and well-scoped: identify use cases that would bring users back, then prototype and test them. The trap to avoid was the obvious one, which was bolting on tangentially-related features that diluted the core value rather than extending it. Many e-commerce apps in 2019 were drifting toward content, social, and lifestyle features in search of engagement, and most of those drifts ended up making the apps worse rather than retaining them better. The brief explicitly cautioned against this trap.
This was my apprenticeship project, working directly with the CTO. The seniority of the sponsorship was unusual for a junior designer, and it shaped what was possible. Decisions that normally take weeks of cross-functional alignment happened in single conversations. The lessons from that experience have stayed with me as I have moved into more senior roles myself.
I ran a two-month design thinking engagement structured as a classical double-diamond: a wide research phase, a wide ideation phase, then progressive narrowing into prototypes and testing.
Weeks one and two were research. I interviewed users across three segments: recent buyers (within last 30 days), older buyers (60-90 days post-purchase), and lapsed users who had uninstalled. The lapsed-user interviews were the most useful, because they captured the moment of decision to uninstall in language that current users would not have produced. I also visited Lenskart physical stores to observe how customers actually engaged with eyewear shopping in person, which informed how the app might extend that experience digitally rather than replicate it.
Competitive teardowns covered both direct competitors (other eyewear e-commerce apps) and adjacent retention archetypes (apps that had successfully retained users in low-frequency purchase categories). The pattern that emerged was that successful retention in low-frequency purchase categories required either becoming a content destination (which violated the brief's constraint) or finding genuine reasons for users to engage between purchases without that engagement being filler.
The research output was a lifecycle journey map that identified moments where Lenskart could provide value to users between purchases, and an archetype taxonomy of the kinds of features that would qualify as genuine extensions versus tangential additions. These two artifacts steered the entire ideation phase.
Weeks three to six were ideation. The goal was to produce as many viable concepts as the time allowed, then progressively narrow to the strongest. I generated 15 viable concepts across the lifecycle journey, ranging from eye health tracking to lens care reminders to family eyewear management to vision-test integration with optometrist partners.
The filtering criteria were strict and explicit: every concept had to be a direct extension of the eyewear use case (not adjacent, not lifestyle, not content), had to provide genuine user value rather than filler engagement, and had to be plausibly buildable within Lenskart's existing operational capabilities. Concepts that violated any of these criteria were rejected even when they were individually compelling.
The 15 concepts narrowed to 3 prototyped in weeks five and six. The three were chosen for diversity of approach (one operational, one informational, one community) rather than just for quality, so that the testing phase would produce learnings across different types of concept rather than just refining one concept.
Weeks seven and eight were prototyping and testing. I built clickable prototypes of the three concepts and ran moderated tests with target users. The tests captured both quantitative preference data (which concept did users want most) and qualitative reasoning (why). The testing phase was deliberately structured to surface unexpected reasons users liked or disliked concepts, which produced more useful design intelligence than the headline preference data alone.
Of the three prototyped concepts, one was prioritised for development by the Lenskart team after the apprenticeship ended, based primarily on the qualitative tester reasoning rather than the preference rank.
Reject concepts that were not direct brand extensions. The discipline that produced useful concepts was rejecting every concept that was not directly an extension of the eyewear use case. Lifestyle features, social features, and content features were tempting in isolation but would dilute Lenskart's positioning as an eyewear brand. The three prototyped concepts all extended the eyewear journey directly, which made the qualitative tests sharper because users were not being asked to consider Lenskart as a new kind of brand.
Prioritise qualitative reasoning over quantitative preference. The testing phase captured both, but the design recommendation was driven by the qualitative reasoning. Quantitative preference data in concept tests is famously unreliable because users do not yet know how they would actually use a feature. Qualitative reasoning surfaces the underlying need that drives the preference, which is more transferable to design decisions.
Use the CTO sponsorship strategically. Working directly with the CTO meant that decisions which would normally require cross-functional alignment could happen in single conversations. This was a significant advantage that I learned to leverage rather than take for granted. Senior sponsorship is one of the most under-discussed factors in whether a project ships, and I have sought it out for important projects ever since this apprenticeship.
Document the process for the team that would build it. The handover document captured not just the recommended concept but the reasoning behind why the other two were rejected, so that the engineering team that would build the chosen concept would understand the design intent rather than just the surface feature. This is rarely done in apprenticeship projects and made the work much more likely to ship faithfully.
Prototype that moved forward to launch
The selected concept moved into the development pipeline and was eventually launched by the Lenskart team after the apprenticeship ended. As a junior designer at the time, the more durable outcome for me was the process itself.
Running a structured design thinking engagement with a CTO sponsor was a formative experience in how research translates into product decisions, and it shaped how I approach scoped engagements with senior stakeholders to this day. The seniority of the sponsor changed what was possible in ways I did not fully appreciate at the time but have leveraged consistently in the years since.
The 15 concepts to 3 prototypes to 1 launched funnel also calibrated my expectations for ideation quality. Most concepts in any wide-ideation phase will be wrong, and that is fine. The discipline is in the filtering criteria, not in the volume of concepts. A wide ideation followed by a strict filter produces better results than a narrow ideation followed by a loose filter, even though the second approach feels more efficient.
Working directly with Lenskart's CTO gave the engagement a sponsorship level that most junior projects never get. Decisions that would normally take weeks of internal alignment happened in single conversations. Resources that would normally require begging were made available without friction. The work itself was not different from what a junior designer would normally do; the surrounding conditions were different.
The lesson, and one I have used repeatedly since, is that the difference between a project that ships and one that does not is often the seniority of its sponsor more than the quality of its design. Junior designers should seek out senior sponsorship as carefully as they seek out senior mentorship. The two are not the same and produce different career-shaping outcomes.