# Shylendar Murali (Shyl) — Full profile, work, and products > Expanded companion to /llms.txt. Full text of Shyl's case studies and products > for AI tools that prefer one document over crawling individual pages. Shyl is a senior product designer (working since 2012) across consumer growth, mobility, marketplaces, SaaS, and operational systems. Based between Riyadh (Saudi Arabia) and Chennai (India); available for product design engagements across India, the Middle East / GCC, and global remote. Contact: mshylendar@gmail.com · Website: https://shyl.work LinkedIn: https://www.linkedin.com/in/shyl/ · X: https://x.com/shylendar Career timeline: - 2026 — present: Independent builder — self-directed products & tools - 2024 — 2025: Senior product designer — HungerStation (Delivery Hero) - 2021 — 2024: Design lead — SWVL (mobility, marketplaces, internal systems) - 2018 — 2021: Senior product designer — Hubstaff, Flumbo, freelance - 2015 — 2018: Product designer — Hotline.io / Freshworks - 2012 — 2015: Designer / front-end — agencies and early startups # Case studies ## Subscription growth at scale — HungerStation *Growth · 2024 · Product design lead, Growth systems, UX strategy · iOS + Android · Consumer* I led growth design for HPlus at HungerStation, turning a cardless trial-expiry problem into a multi-touchpoint reactivation system that helped scale daily subscription registrations from 600-800 to about 5,000.
The situation

Millions of free trials had no renewal mandate.

HungerStation distributed free HPlus subscriptions quickly in response to Keeta's market entry. Those users received the benefit, but many had no card or recurring payment authorization attached.

My focus

Make renewal part of the active order journey.

I led the design of a reactivation system across home, restaurant details, cart, and checkout, then worked across squads to make the payment model possible.

What changed

From 600-800 to about 5,000 registrations a day.

Offer periods peaked near 12,500-15,000 daily reactivations, while the subscription program generated €80Mn+ annually.

01 / The constraint

The free trial solved one problem and created another.

When Keeta entered Saudi Arabia with free delivery, HungerStation responded by automatically giving new, churned, and at-risk users three, six, or twelve months of HPlus. It stabilized the business quickly and increased ordering from those cohorts.

The catch was structural: the urgent rollout skipped the normal activation flow. As those trials expired, we needed to convert users who had experienced HPlus but had never approved recurring billing.

02 / Reactivation system

I moved HPlus renewal out of settings and into moments of intent.

Users rarely open an account page to manage a subscription. I designed a set of contextual entry points that connected HPlus to the order they were already placing, without forcing them to abandon the core food journey.

Make past value visible

For active cohorts, the homepage widget showed how much the user had already saved with HPlus and gave them a direct renewal action.

Change the reason to renew

For users whose subscription had been expired longer, historic savings mattered less. The widget shifted to current benefits and a simpler value proposition.

Active users

Show what HPlus already saved them.

Personalized savings made the value concrete and helped drive a blended 14% uplift in reactivations from the homepage work.

Price-sensitive users

Use the 1 SR month as a payment bridge.

The offer reduced the decision barrier while also solving the recurring authorization constraint.

Long-expired users

Rebuild the value story from benefits.

After fifteen days, we stopped leading with old savings and reminded users what they would regain.

HPlus one riyal reactivation offer on the HungerStation home screen

A direct reactivation entry point

The expired state and 1 SR offer were visible on the homepage, close to the user's next ordering decision.

HPlus plan selector with one riyal first month offer

Keep the purchase inside a bottom sheet

I used a bottom sheet so users could compare plans, approve payment, and return to ordering without losing context.

03 / Down-funnel experiments

The closer HPlus got to the order, the stronger the conversion.

We expanded the same reactivation logic through restaurant details, cart, and checkout. Each surface made the value more immediate by connecting it to the delivery fee on the current order.

1.6%

Restaurant details

A compact widget above the primary action replaced larger promotional banners.

2%

Cart

The message showed the exact delivery fee the user could avoid on that order.

3%

Checkout

We repurposed the existing HPlus summary component near the final payment action.

12%

Checkout interstitial

A deliberately high-friction experiment converted far above our expectation.

Checkout interstitial showing the immediate order savings from HPlus

Make the current-order saving explicit

The interstitial showed the amount saved, a preselected 1 SR plan, a clear subscription payment action, and a route to continue without HPlus.

12%

conversion, with a real trust cost

The checkout interstitial worked, but it also caused a roughly 1-2% increase in support contacts from users who thought Apple Pay was completing their food order rather than buying HPlus.

I made the hierarchy and CTA language more explicit, and we aligned with support on immediate refunds for accidental signups. The experiment taught me to treat friction as a product variable, not a rule: conversion only counts when the tradeoff is understood and managed.

04 / System design

A simple add-to-cart idea took two months to ship.

The next move was to let users add HPlus to their cart like any other item. On the surface, it was one button and one new line item. Underneath, the subscription had to remove the delivery fee from the active order, split the payment, create a recurring mandate, and behave correctly when the food order failed or was refunded.

My role was not only designing the component. I worked through where it belonged, how the total should recalculate, what the fallback authorization flow needed to explain, and which operational guardrails made the experience supportable.

Cart variation leading with unlimited free delivery as the HPlus benefit

Generic subscription value

One variation led with unlimited free delivery and exclusive offers.

Cart variation showing the current-order saving available with HPlus

Current-order saving

The contextual variation connected HPlus to the 20 SR saving available on that order.

Cart after HPlus has been added as a removable subscription line item

Added-to-cart state

HPlus became a removable line item. The cart did not expose the full fee breakdown; that calculation appeared at checkout.

What it took to ship

The visible state was one new cart item. Shipping it meant aligning the behavior behind that item across five parts of the business.

Cart

Placement

Find a prominent entry point without obscuring the food order.

Checkout

Value handoff

Carry the free-delivery benefit into the fee calculation shown at checkout.

Payments

Split authorization

Capture the order payment while establishing the recurring subscription mandate.

Support

Failure handling

Define refund behavior when an order fails but the subscription succeeds.

Fraud

Guardrails

Set controls around repeated trial and cancellation behavior, define the acceptable fraud threshold for the feature, and add kill switches with the fraud teams.

05 / Outcomes

The work connected subscription value to everyday ordering behavior.

€80Mn+

Annual HPlus revenue

The subscription program's annual revenue after the acquisition, retention, and reactivation work.

~5,000/day

Average subscription registrations

Up from roughly 600-800 per day, with offer periods peaking near 12,500-15,000 daily reactivations.

06 / Reflections

What this work changed in how I design growth.

Design where the intent already lives.

The strongest HPlus surfaces did not ask users to manage a subscription. They made the value of subscribing obvious inside an order the user already cared about.

Growth metrics need a trust counterweight.

The checkout interstitial proved that friction can convert. It also made support contacts and accidental purchase risk part of the design problem, not somebody else's cleanup.

The interface is only the visible layer.

The hardest part of adding HPlus to cart was not the button. It was aligning payment authorization, live pricing, refunds, support, and fraud behavior so the promise on screen stayed true.

--- ## Designing discovery loops for Quick Commerce — HungerStation *Discovery · 2024 · Product design lead, Discovery, Experimentation · iOS + Android · Consumer* I led a series of Quick Commerce discovery experiments at HungerStation, placing relevant grocery entry points inside high-attention moments across the food-ordering journey.
The opportunity

Food had attention. Quick Commerce needed discovery.

HungerStation already had a high-frequency food-ordering habit. My charter was to help more of those users discover and buy from its dark stores and grocery partners.

My approach

Place small shopping loops inside moments that already worked.

I treated discovery as a sequence of contextual experiments across order tracking, deals, and category browsing rather than another destination users had to remember.

Broader outcome

110Mn SAR in additional Quick Commerce revenue.

This was the result of the wider Quick Commerce discovery charter. Individual experiments had different levels of measurement and maturity.

Experiment 01 / Deal Zone

A dedicated entry point for Deal Zone.

When Deal Zone came up, the room had mostly made up its mind: ship it as one more campaign collection, a small square card in the rail next to the seasonal ones. I pushed back. A savings destination this big shouldn't have to fight for a thumbnail. It needed its own way in and its own page.

So I argued for two things. A dedicated entry point on the store landing, and a custom Deal Zone page with an "All items" view I added on top of the individual categories. I also kept making the case for a large header banner the team kept calling a waste of space, until they let me test it. It stayed, and it's a slot we can monetize or seasonalize later.

We launched with HMarket and a few AAA vendors (Lulu, Carrefour, Al Othaim), and it did well enough that we rolled it out to every vendor. That listing pattern later became the backbone of HungerStation's main category exploration.

110Mn SAR additional Quick Commerce revenue, with Deal Zone leading the way
All vendors scaled from HMarket and AAA partners after a strong launch
HungerStation Market landing with a large Deal Zone entry banner, campaign collections, and a seasonal header
The entry point I fought for: a full-width Deal Zone banner above the campaign collections, plus the seasonal header the team almost cut for space.
Dedicated Deal Zone page with an All items view and category tabs
The page I argued for, with an “All items” view I added and category tabs running across the top.
Deal Zone page scrolled down to a dense product grid across categories
Scrolling stays easy. A dense, scannable grid of savings across every category.
Experiment 02 / Order tracking

A second basket during the delivery wait.

After placing a food order, users repeatedly checked the tracking page and had a few minutes of attention. I designed an HMarket shelf that could introduce relevant products without competing with delivery progress.

We kept both cashback and non-cashback versions so the loop remained useful when an offer budget was unavailable.

~12% click-through for the cashback version
6% of dark-store orders flowed through the OTP shelf
HMarket shelf with cashback and expiry timer on the order tracking page
The strongest version paired a time-bound cashback offer with products the user could add immediately.
Expanded HMarket product shelf on the order tracking page
Expanded when products were useful to browse.
Collapsed HMarket product shelf on the order tracking page
Collapsed when tracking details needed priority.
Experiment 03 / Category browsing

A supermarket listing that's easy to scan.

Discovery did not end at the entry point. I also reworked the supermarket listing so users could scan available stores, offers, delivery times, and categories with less effort. The redesign moved generic promo tiles aside and surfaced what actually drives a choice, like ratings, distance, delivery time, and live offers, right on each store row.

Before
Earlier HungerStation supermarket listing with promo tiles and plain store rows
Promo tiles dominated and store rows carried little detail to decide on.
After
Redesigned HungerStation supermarket listing with ratings, delivery times, and live offers on each store
Ratings, delivery time, and active offers sit on every store, so comparison is effortless.
Experiment 04 / Merchandising

Shoppable merchandising banners.

The store listing was stacked horizontal rows of items under plain text titles. It worked, but it got repetitive fast and every store ended up looking alike. I added a merchandising unit that sits an image header on top of a product row, so a section can set a mood instead of just naming itself. It also shipped as an ad placement brands could buy, so the visual lift came with a new revenue line.

Before
Store listing with plain text section titles above repeating horizontal product rows
Plain text titles over repeating horizontal rows. Functional, but every section read the same.
After
Store listing with image-led merchandising banners heading each product row
An image-led merchandising unit heads each row, and the same slot sells to brands as an ad placement.
Experiment 05 / Category selector

A scalable category selector.

Each category used to be a boxed card with the title and image locked together, and the whole set ran down the page in one long vertical scroll. It didn't scale and it looked busy. I separated the image from the label, moved everything into a fixed-height horizontal scroll widget, and we built our own logic for ranking which categories surface first. The result is calmer, more consistent, and much easier to extend.

Before
Shop by category as boxed cards with title and image stacked down a long vertical scroll
Boxed cards locked the title and image together, stacked down a long vertical scroll.
After
Shop by category as a fixed-height horizontal scroll widget with separated image and label
Image and label separated in a fixed-height horizontal widget, ordered by a custom ranking.
The bigger picture 110Mn SAR

Across the whole discovery charter, these experiments added 110Mn SAR. What stuck with me wasn't the number. It was that discovery worked best as lots of small, well-placed loops inside the food journey people already had, not one big destination I had to talk them into visiting.

--- ## Community Q&A from zero — Creative Fabrica *Community · 2024 · Product design, Product strategy, Visual design · iOS + Android + Web* 0-to-1 community product for crafters. Creative Fabrica needed a space where their users could ask questions, share answers, and discover each other's work, without it feeling like a generic forum bolted onto a marketplace. ### Brief **A creative community with no community product.** Creative Fabrica had millions of users buying and using design assets, but no place for them to talk to each other. The support team fielded questions that power users could answer faster. The marketplace had no social proof layer. The community lived in third-party Discord servers and Facebook groups. **Solo designer in a team of 14.** Interaction design, visual design, and product strategy, contracted through A.teams. One designer working alongside one PM and twelve engineers across mobile and web. **A 0-to-1 community surface live on iOS, Android, and Web.** AskCF launched as Creative Fabrica's first community product: a Q&A system where crafters could ask questions, answer them, vote on the best answers, and discover related content from the marketplace. ### A marketplace community product lives or dies in the first ten questions. If the first questions on a new community platform are bad, or go unanswered, the product fails before it starts. AskCF was designed around the cold-start problem from day one: seeding quality, making answering feel rewarding, and keeping the marketplace context present without being intrusive. ### Design for the answerer, not just the asker. Most Q&A products are designed for the person with the question. AskCF's quality depended on the people with answers: experienced crafters who had no existing reason to spend time helping strangers. The interaction model had to make answering feel worthwhile through recognition, visibility in the community, and a clear connection between their answers and marketplace activity. **Question quality at cold start** We worked with Creative Fabrica's community managers to seed the platform with representative questions before launch. The ask interface included smart prompts based on asset categories, so users posting about a font saw suggested question structures rather than a blank field. **Answering incentive** Top answerers got a visible reputation signal tied to their Creative Fabrica profile. Accepted answers surfaced in marketplace asset pages where relevant, creating a loop between community expertise and marketplace trust. **Mobile-first in a desktop-heavy domain** Crafters work on desktop but browse on mobile. AskCF needed to work well for quick question browsing and voting on mobile, while supporting longer, richer answers on the web. **AI-assisted answer surfacing** Common questions with existing answers in the Creative Fabrica knowledge base surfaced AI-drafted starting points so askers could self-serve, and experienced users could focus on the harder, more specific questions where their knowledge actually mattered. ### Reflections 0-to-1 community products are one of the hardest design briefs because success depends on human behavior, not feature completeness. You can ship a technically perfect Q&A system and watch it stay empty. The decision to focus on answerer experience first, before we optimised the asker experience, was the most important product call on this project. Most community products launch for the people with questions. AskCF launched for the people with answers. --- ## Redesigning SWVL's post-booking experience — SWVL *Mobility · 2022 · Design lead, Strategy, Research · B2C mobile* I redesigned SWVL's post-booking experience so riders could understand pickup, vehicle, captain, policy, and next steps after checkout. ### Brief **Users couldn't read the state of their own booking.** After checkout, the booking-details screen did not answer the questions riders checked most: where do I go, when, with whom, and what happens next? **Design, strategy, research.** I led the redesign end-to-end: data analysis, user interviews, information architecture, interaction design, usability testing with ~25 users, and implementation handoff. **Friction down, trust up, ops cost down.** The shipped redesign reduced paid cancellations by 14%, post-booking churn by 4.8%, and support/captain calls by 20% on the measured routes. ### SWVL ran on intent, but lost users between booking and boarding. I treated the booking-details screen as the moment where SWVL had to earn confidence after payment. Riders were often outdoors, moving, and under time pressure. The screen had to answer pickup, vehicle, captain, boarding pass, route, and policy questions without making them call support. ### Treat the screen as a ride document, not a checkout receipt. I moved the surface from transaction-first to ride-first. Instead of one broad redesign, I broke the work into five rider questions and designed the screen around those moments. ### I started with support data, then tested with riders. ### The results showed up in operations. ### Usability testing made the weak points visible. Before shipping, I ran moderated tests in person and remotely with around 25 participants across new-user, regular, and edge-case cohorts. I was not testing whether the screen looked better. I was testing whether people could board without needing help. **Boarding pass** New riders did not know what the boarding pass was or when to show it. I pulled it out of the buried details and made it feel like the artifact they needed at boarding. **Booking state** The old screen hid the booking state. I made the current status explicit: confirmed, captain assigned, en route, boarding open, or delayed. **Communication gaps** Riders needed to know what they could do and what SWVL was doing next. I wrote the interface around next action, system status, and expectation setting. **Stops & stations** Stations were not always obvious physical places, and stop names were not always enough. I brought route stops and map context into the screen so riders could confirm where they were and why the bus stopped. **Captain & vehicle** When dispatch information was not ready, the old screen felt broken. I designed the waiting state clearly, then surfaced captain and vehicle details as soon as they were assigned. Fewer riders abandoned after checkout on the measured routes and cohort. Riders who completed a first booking were more likely to take another ride. Inbound questions dropped around the part of the journey I redesigned. **Captain is yet to be assigned** **Captain and vehicle assigned** **Delay or broadcast from captain** **Vehicle arrived at station** ### Reflections The win was structural, not stylistic. Treating booking details as a *ride document* instead of a *checkout receipt* changed what the screen had to answer first. Once the information model was right, the visual work got smaller and sharper. If I were doing this again, I would introduce the boarding pass at confirmation, when the rider is calm, not later in transit. The biggest discoverability issue came from teaching a new pattern at the exact moment people were already trying to board. --- ## In-app support, designed from acquisition to launch — Hotline.io *SaaS · 2016 · Product design, Research, Prototyping · Web dashboard + mobile SDK* Freshdesk acquired an in-app messaging startup called Konotor. The brief: design the full product from scratch. Agent dashboard, campaigns, FAQs, and two mobile SDKs. It reached $5M ARR faster than any Freshdesk product before it. ### Brief **Agents were context-switching to do basic things.** Two steps to toggle between conversations. A Gmail-style threading model that didn't match how support actually works. No filter, no search, no user context panel. The tool made routine work feel heavier than it should. **Full product design. One designer.** Research, interaction design, visual design, and prototyping across five surfaces simultaneously: agent dashboard, campaigns, FAQs, iOS SDK, and Android SDK, from acquisition through launch. **The fastest Freshdesk product to reach $5M ARR.** First response time dropped from 8.4 to 2.3 minutes. Average CSAT up 85%. Resolution time down 45%. Smart Plugs, a first-to-market feature, became the primary reason customers switched. ### Freshdesk acquired an in-app chat product. The brief was to ship it. All of it. Konotor was a promising in-app messaging SDK. Freshdesk acquired it and combined it with their own mobile SDK. The design task was the full product from scratch: the agent interface, the campaign system, FAQs, and two mobile SDKs, while the engineering team was still figuring out the architecture. ### Replace context-switching with toggling. Replace loading with presence. The old interface treated support conversations like email threads and page navigation like websites. We rebuilt it around a persistent split view: conversation list on the left, active thread in the center, user context on demand. Agents never had to fully navigate away to see what they needed. ### The inherited Konotor UI had the bones of a chat product, but the workflow felt like email. ### The results came from operations, not the launch announcement. **Two-step conversation switching** Moving between conversations required a full navigation step away from the active chat. We replaced it with a persistent left-rail conversation list: one click to switch, with the previous thread still visible until the next one loads. **Gmail-style threading** The message view borrowed email conventions (collapsed threads, click-to-expand, load waits) in a context where conversations are sequential, not threaded. We rebuilt it as a linear chat timeline with real-time presence indicators and no loading delays. **No filter or sort** Agents couldn't sort or filter their conversation queue. In a busy environment that meant manual scanning. We added a filter rail across status, priority, and channel, with a quick-assign action that kept agents in flow. **No user context panel** Any time an agent needed account history, tags, or user metadata, they had to leave the conversation. We built an on-demand detail pane that expanded from the right edge without navigating away from the active thread. **No search** There was no way to find a specific past conversation or message without scrolling backward through the queue. We added full-text search across conversation history and message content, with results opening inline so agents stayed in the same flow. Down from 8.4 minutes to 2.3. Agents could respond faster because switching, reading context, and composing were no longer separate navigation steps. Customer satisfaction increased significantly. Faster, more contextual replies changed how support felt from the customer side, not just the agent side. Conversations closed faster when agents had the right context in a single view. Time saved per ticket compounded across the full queue. Hotline reached $5M ARR faster than any other product in Freshdesk's history at that point. Now absorbed into Freshchat, it serves 30M+ end users globally. **Conversation dashboard** **Message composition** **Campaign analytics** **Segment builder** ### Reflections The biggest design leverage was structural, not cosmetic. Once the information model changed (presence instead of pagination, context in-line instead of behind navigation), most visual decisions became smaller choices inside a clear frame. The Smart Plugs surface was the call I didn't expect to matter most. It started as a relatively small addition to the agent interface, a way to surface inline context from third-party tools without leaving the chat. It ended up being the primary reason customers switched to Hotline over alternatives. The lesson: the feature that lowers the activation cost of the main workflow often outperforms the main workflow itself. One thing I'd revisit: the campaign analytics surface. We rebuilt it for at-a-glance legibility, but with one designer across five surfaces simultaneously, it got less depth than it deserved. The data density was right. The filtering and segmentation options were not. --- ## Create, manage, and run public transit — SWVL *B2B / B2G SaaS · 2022 · Design lead · Web platform* An end-to-end platform for transit agencies to manage fixed-line routes, demand-responsive transit, and overall network operations. Used by government and semi-government transit systems across multiple cities. ### Brief **Transit agencies ran complex networks on fragmented tools.** Public transit operators managing fixed routes, on-demand zones, and mixed fleet types had no unified control surface. Network management lived across spreadsheets, radio calls, and disconnected vendor software, with no real-time view of the whole system. **Design lead on a cross-functional team.** Led design across UX strategy, execution, prototyping, and research testing. Worked alongside Alex (D2D), Ozgur (Design), PM lead Dinesh, and five product managers across the transit domains. **A single platform for fixed-line, DRT, and operations.** Transit control centre operators could create and manage routes, monitor live network health, and handle demand-responsive trips from one surface, replacing the fragmented tooling most agencies used before SWVL. ### Government transit agencies had the complexity of airlines and the tooling of spreadsheets. Fixed-line bus routes, demand-responsive transit zones, and real-time network monitoring are three fundamentally different operational modes. Most agencies ran them separately. TCC was built to make them legible from a single screen. ### Model the operational mode before designing the interface. Transit operations have strict domain logic: routes have fixed schedules, DRT has flexible dispatch, and live monitoring has zero tolerance for ambiguity. We built a domain model first (trip types, states, actor roles, escalation paths) before designing a single screen. **Route and schedule management** Creating and modifying fixed-line routes required setting stops, schedules, vehicle types, and driver assignments. We designed a structured editor that enforced the rules (minimum headway, stop sequencing) without making the interface feel like a form. **Demand-responsive transit dispatch** DRT trips have dynamic pickup and dropoff zones rather than fixed stops. Dispatching them from the same surface as fixed-line routes required clearly different interaction patterns: zone selection vs. stop pinning, flexible vs. fixed time slots. **Live network monitoring** Control operators needed to see the health of the whole network at a glance: vehicles on time, delayed, or off-route; capacity gaps; driver availability. We designed a live dashboard that surfaced exceptions rather than showing everything, so operators only looked at what required action. **Multi-agency, multi-city configuration** The platform had to support agencies with very different network sizes and operational structures. Configuration had to be deep enough to model those differences without requiring SWVL engineering time for each new deployment. ### Reflections Government transit is a design domain that rewards deep domain knowledge and punishes assumptions. The users (control room operators, network planners, dispatchers) have years of operational expertise and no patience for interfaces that don't match their mental model of how transit works. The biggest design leverage on TCC was the domain model, not the UI. Getting the taxonomy of trip types, states, and actor roles right meant that the interface followed naturally. Most of the early design iterations that felt wrong were wrong because the underlying model was wrong, not because the visual design was bad. --- ## Fleet management for large supply partners — SWVL *SaaS · 2022 · Design lead · Web dashboard* Large fleet operators running 40+ buses on SWVL's network had no dashboard to manage their vehicles and drivers. The Vendor Portal gave them a single surface to monitor fleet status, manage driver assignments, and track contract performance. ### Brief **Large operators managed 40+ buses through SWVL ops manually.** Fleet partners operating 40 or more buses under contract had no self-serve tool. Fleet status, driver assignments, and performance data lived in spreadsheets and ops team calls, a high-touch process that didn't scale as SWVL's supply network grew. **Design lead, with Mahmoud Isaac (design) and Habiba (research).** UX strategy, interaction design, prototyping, and research alongside PM lead Ahmedyar. Ran discovery with supply partners directly to map the existing manual workflows before designing replacements. **A self-serve fleet dashboard that reduced ops dependency.** Vendors could monitor their active fleet, track driver assignments and availability, and see contract performance metrics without routing requests through SWVL's operations team. ### SWVL's supply network was scaling. The tooling hadn't. A large vendor partner running 50 buses under contract shouldn't need a phone call to know which drivers are on shift. The Vendor Portal was built to close that gap, and to make large-operator onboarding fast enough to support SWVL's expansion into new cities. ### Map the manual workflow first. Replace the highest-friction parts. Before designing anything, we ran discovery sessions with supply partners to document what they actually did today: which spreadsheets, which calls, which reports they built manually. The portal's first version was a direct replacement for those workflows, not a redesign of them. **Fleet status visibility** Vendors had no live view of which buses were active, idle, or unavailable. We built a fleet overview that showed status per vehicle in real time, with filters for zone, shift, and driver assignment. **Driver management** Driver-to-vehicle assignment was handled through ops team calls. We gave vendors a driver roster with assignment history, shift scheduling, and the ability to reassign directly, without involving SWVL operations. **Contract performance** Vendors couldn't see their own performance against contract terms (utilisation, on-time rate, rejection rate) without requesting a report. We surfaced these metrics on the portal home screen so vendors could self-monitor and flag issues early. ### Reflections B2B tooling for marketplace supply partners is a genuinely underdesigned space. The vendor is a power user who knows their workflow deeply, tolerates more density than a consumer, and cares about data accuracy above all else. Designing for them requires unlearning a lot of consumer UX instincts. The discovery sessions with vendor partners were the most important work on this project. The gap between what the ops team believed vendors needed and what vendors actually did every day was significant. The design would have been wrong without closing that gap first. --- ## Helping driver partners plan their week — SWVL *Supply-side · 2021 · Design lead · Android · Driver app* Driver partners on SWVL's network had no visibility into their upcoming schedule. The Upcoming Trips feature gave captains a week-level view of their booked routes, and gave operations the supply forecasting data they needed to run the network. ### Brief **Captains planned blind. Operations forecasted blind.** Driver partners had no tool to see what their week looked like: upcoming routes, times, or load. The operations team had no reliable way to forecast vehicle supply or plan for backup capacity when demand shifted. **Design lead alongside PM Zain.** UX strategy, interaction design, prototyping, and research across the driver app surface. Worked directly with the operations team to understand the forecasting use case alongside the driver experience. **A scheduling view that served two stakeholders at once.** Drivers could see and manage their upcoming trips. Operations could use the same data to model supply, arrange backup vehicles, and respond to rejected ride requests before they became gaps in the network. ### The captain app was a dispatch tool. It needed to become a planning tool. SWVL's driver partners operated on a mix of advance bookings and on-demand requests. Without visibility into their schedule, planning anything (from rest to vehicle maintenance) was guesswork. ### Design for two different users reading the same screen. The Upcoming Trips view had to work for the captain (personal planning, income visibility) and for operations (supply health, backup readiness). The data was the same; the priority order was different. We designed the captain view first, then verified every field against the operations forecasting model. **No weekly horizon** The existing captain app showed only the current or next ride. We added a week-level timeline that let captains see confirmed trips, pending requests, and gaps, the same view a calendar gives a freelancer. **Upcoming vs. confirmed state** Not all trips on the schedule were confirmed. We distinguished between pending requests (captain hasn't accepted yet), confirmed bookings, and completed trips, so captains could make informed decisions about accepting new work. **Operations forecasting integration** The same trip list that helped captains plan gave the ops team real-time visibility into vehicle supply per zone and time slot. Rejected or unaccepted trips surfaced as gaps the ops team could respond to with backup vehicles. ### Reflections The supply-side user is almost always an afterthought in consumer marketplace design. The captain app had less design investment than the rider app by a significant margin, and it showed, not in UI quality, but in the depth of thinking behind the product model. Upcoming Trips was a small feature with an outsized effect on driver trust. Captains who could plan their week were more reliable partners. The forecasting benefit for ops was real, but the thing that surprised us most was how much the feature reduced captain support inbound. Turns out a lot of "when is my next ride?" calls just needed a screen. --- ## On-demand rides in a scheduled transit app — SWVL *Mobility · 2022 · Product design · iOS + Android* Demand-Responsive Transit brought flexible, on-demand booking into SWVL's scheduled-route consumer app, serving zones where fixed routes couldn't run economically. DRT sat at the intersection of two very different product models: the predictability of scheduled transit and the flexibility of on-demand ride booking. For SWVL users familiar with fixed routes, the pickup and dropoff experience was meaningfully different: no fixed station, no scheduled departure, more like a hail than a reservation. The design challenge was introducing that flexibility without breaking the mental model that made SWVL feel safe and legible. Users needed to understand they were booking something different, not broken. **Team:** Vivek (Design Lead), Shyl (Design), Surbhi (PM Lead), Ehab (Engineering Lead) --- ## Platform trust and category design — Udaan *Ecommerce · 2021 · Product design, Visual design · iOS + Android* Selected design work at Udaan across platform trust, ratings systems, and category experiences for Electronics and Fashion, part of a team building ecommerce for a fast-growing B2B marketplace. These are example works from my time at Udaan, not a detailed case study. The work spanned two main areas: **Platform trust and ratings.** Designing the ratings and reviews system for Udaan's marketplace. Trust signals that help buyers make decisions in a category where product quality varies and returns are costly. **Electronics and fashion categories.** Category-level design work across the mobile app, optimising discovery, product detail pages, and the moments where category context changes what the buyer needs to see. Udaan operates in a fundamentally different ecommerce context than a consumer marketplace: buyers are often small business owners purchasing in bulk, on credit, with significant stakes per transaction. The design work had to account for that: trust, legibility, and confidence mattered more than delight. --- ## Power bank rental, designed from zero — Flumbo *Consumer · 2018 · Founding designer, Product strategy, Research · iOS + Android* 0-to-1 app for a startup building power bank rental stations across India. The market was brand new, the hardware was in development, and there was no comparable product in the country to borrow from. ### Brief **An unfamiliar product in an unfamiliar market.** Power bank rental was not a concept Indian consumers had encountered. Unlike China where WeChat mini-programs and rental services were already commonplace, India had no reference point. The app had to introduce the concept and make it feel trustworthy, while the user's phone battery was probably already dying. **Founding designer. All surfaces.** Research, interaction design, visual design, prototyping, product management, and strategy, from first concept through launch. No existing design team, no prior product to inherit. **A working product in a category that didn't exist yet.** Shipped iOS and Android apps covering the complete rental loop: onboarding, finding a station, renting, returning, and auxiliary flows. Built for users in a hurry with low battery, the worst possible moment to encounter friction. ### Build something people have never used before, fast, for when their phone is dying. The hardest design constraint wasn't the interface. It was designing for users whose patience was already zero. Every second of confusion was a reason to abandon. ### Borrow mental models from what people already trust. Indian consumers already understood Uber, Ola, and Ofo. We designed the rental flow around the same spatial logic (find nearby, tap, confirm, go) rather than asking people to learn something new. Familiarity was the product, not novelty. **Onboarding in a category with no precedent** Users had no frame of reference for power bank rental. We designed onboarding that explained the concept in one gesture rather than a tutorial: show the station, show the bank, show the return, in the time it takes to read three screens. **Finding a station under time pressure** The home screen had one job: show the nearest Flumbo station immediately. No splash, no nudge, no upsell. Map-first, station highlighted, one tap to navigate. **Renting when you're already anxious** Low battery is a stressful state. Every extra tap is a cost. We reduced the rental flow to the minimum viable confirmation: station → bank selection → confirm. Three steps, no dead ends. **Return flow for an unfamiliar artifact** Returning a power bank was a new behavior. We designed the return flow with explicit station guidance and a clear completion state so users knew the transaction was done and they were no longer liable. ### What I'd do differently The biggest design risk wasn't the UI. It was assuming the mental model would transfer. The Uber analogy worked for the spatial part (find, go, use), but broke down at the hardware level. Users didn't have intuitions about which bank slot to use or what the indicator lights meant. A better first version would have designed the physical interaction into the onboarding, not just the app. The return flow also needed more investment. Renting was motivated: users needed power. Returning was unmotivated: users had power and wanted to leave. We underestimated how much the return state needed its own persuasion logic. --- ## Selected design work — Olacabs *Mobility · 2020 · Product design · iOS + Android* A range of design work at Olacabs across categories, financial features, tipping, and safety, part of a large design team working across India's most-used ride-hailing platform. These are example works from my time at Olacabs, not detailed case studies. Four areas of work: **Categories page redesign.** Rethinking the home-screen categories surface to surface the right ride type faster, especially as Ola's product portfolio expanded (autos, bikes, electric, intercity). **Ola Money KYC.** Know Your Customer flows for Ola's payments product across both the driver and consumer sides. Financial KYC at scale requires a flow that's thorough enough for compliance and fast enough that users don't abandon it. **Tipping.** Designing the tipping experience for Ola drivers. The product challenge was making tipping feel natural without making it feel obligatory, a fine line in a market where pricing expectations are already sensitive. **Guardian safety system.** Consumer-facing safety features: trip sharing, emergency contacts, and the in-app emergency button. Safety UI carries a high bar: it has to work instantly under stress, with no room for confusion about what a button does. --- ## Dashboard and reports redesign — Hubstaff *SaaS · 2018 · Product design · Web* Redesign of Hubstaff's main dashboard and reports surface, a time-tracking and workforce management platform used by remote teams. Circa 2018. Work from 2018 on Hubstaff's dashboard and reporting surfaces. Example works, not a detailed case study. **Dashboard redesign.** Rethinking the main dashboard to surface the metrics that matter most to team leads: who is active, what's being worked on, and where time is going. The existing dashboard was information-dense but not decision-dense. **Reports redesign.** Multiple report views covering time tracking, productivity, payroll, and project budgets. The design challenge was making reports that non-finance people could read and act on, not just export to a spreadsheet. Hubstaff's users range from small remote teams to enterprises with complex project billing structures. The reports had to serve both: filterable enough for power users, readable enough for the manager who opens it once a week. # Products ## ChartCraft (Private beta) Turn raw data into publication-quality charts that look like a graphic designer spent 10 days on them. In 10 seconds. Paste CSV, pick a style, export. --- ## MakeGradient (Live · Web tool) URL: https://makegradient.com Browser-based WebGL gradient editor. Real-time mesh gradients, color math, and Figma export. --- ## Tulir (Launching soon) Tulir runs task-bound friction audits inside your live product. Install one SDK. Send 5 real users a task. Get a decision-ready friction report in 48 hours. --- ## YouTube Profiles (Live · Chrome extension) I built a Chrome extension that lets people switch YouTube viewing contexts so research, learning, and personal watching stay separate. YT Profiles is a small consumer tool with a real trust boundary underneath. I am proud of the polish, but the important lesson is sharper: if a product touches identity, it has to be honest before it is clever.