Context

Fifteen ministries and departments published real problem statements; final-year engineering students across the country built winning solutions against them. The political intent was explicit: departments would adopt the winning innovations into their systems.

The operational reality: nothing existed between the podium and the department. Everyone was designing the event. Nobody owned what came after it.

The failure modes, diagnosed before designing

Engaging stakeholders across all fifteen departments, the colleges and the students surfaced failure modes that were structural, not logistical.

• The lifecycle mismatch. Government integration (rigorous testing, security checks, compliance) takes one to three years in a department like ISRO. The builders were final-year students who would graduate mid-integration.
• The continuity gap. When the original student leaves, who carries the project without restarting the compliance clock?
• Six plausible IP claimants. Nobody had decided whose innovation this was.
• The bandwidth conflict. Students building government systems while completing coursework.
• The funding vacuum. Nobody had named who pays.

The builderFinal-year student

The integrationTesting, security, compliance

Award1 year2 years3 years

The six people who could each claim the innovation:

Designing for the binding constraints

The framework had to survive the strictest compliance regime and the shortest participant tenure, simultaneously. If it worked for ISRO's three-year cycle and a graduating student, it worked everywhere.

Two more principles followed. Each department had to be able to adopt the framework without renegotiating its own internal rules, or it would die in committee fifteen separate times. And the ownership questions went on the table at kick-off, while goodwill was highest and resolution was cheapest.

The result was the Post–Smart India Hackathon operational framework: continuity and handover between student cohorts; roles across nodal officers, mentors and institutions; the IP position; funding; and a compliance-aware timeline honest about government integration cycles. I drafted it, and negotiated it across fifteen secretariats with fifteen different rulebooks.

What changed

The framework was rolled out and executed at national scale for the first edition, and the intent became operational reality: student projects were incorporated into departmental systems. An initiative that had a podium got a pipeline.

What I carry from this

Design the after, not just the event. The podium was the easy part; adoption needed a service of its own, with owners, timelines and money. Design for the binding constraint. A framework that survives the strictest department and the shortest tenure survives everywhere. Settle ownership early. The hardest questions are cheapest at kick-off, while goodwill is at its highest.

Context

At the heart of BT's client engagement lies the Configure, Price and Quote (CPQ) journey: the critical component in securing new business and keeping existing relationships alive. This is the story of transforming it, fought on two fronts: the global sales process at large, and its hardest proving ground, a major hardware resale line where the gap between strategy and reality was widest.

The legacy labyrinth

My first task seemed simple enough: map the existing CPQ process. I quickly realised I was staring into undocumented workflows, each product line with its own approach, built on years of unwritten rules and institutional knowledge.

How do you map something that exists primarily in people's heads?

So I interviewed sales users and stakeholders across product lines. A jigsaw without a picture on the box, each conversation adding a piece to the landscape of the legacy journey.

The blueprint that nobody used

With those hard-earned insights, I built a comprehensive service blueprint on Mural. I thought I had cracked it. Weeks later I noticed something odd: nobody was using it. A quick survey found two barriers: limited Mural licences, and the overwhelming complexity of the artefact itself.

So I translated the blueprint into a tabular, Excel-based document. Less beautiful, universally accessible. It was widely adopted, regularly updated, and became a living repository of organisational memory for the legacy sales journey.

The proving ground: the 2% discovery

Understanding the landscape is one thing; changing it needs a beachhead. The hardware line supplied one, in a single brutal statistic.

2%of the offers were even eligible for the strategic quoting journey. Almost all of the revenue still ran through the legacy process.

I reframed: why can only 2% of the business use the strategic journey at all, and can the sanctioned direction ever serve it?

I mapped the as-is at task grain (stage, frequency, owner, tools, process time, waiting time, and critically how many times data gets re-keyed), turning "the journey feels heavy" into a measurable quantity: 35 screens, propped up by four Excel side-tools. Root-causing the eligibility failures showed that 68% came from one structural blocker: unavailable legal-entity data. This was never a training problem.

Charting the future

Alignment came in two intensives. A three-day workshop with business leaders, sales representatives and technical experts produced a roadmap, guiding principles and evaluation metrics for the wider transformation. A three-day design sprint, run in relay between India and the UK, took the proving ground deep: process flow and root-cause analysis, storyboarding, then Prototype 1.0 with a trial run. With a business analyst and a systems architect, we crafted the to-be blueprint through countless whiteboard sessions and heated debates.

The three-way test

Then came the move that made this effort different from the ones before it. I scored every pain point on the evidenced register against three options side by side: the as-is journey, the strategic-tool journey, and a redesigned journey.

So I recommended against the sanctioned direction and proposed two things instead: a contextually aware guided journey, and an alternative quoting journey. Saying no to a signed-off strategy is expensive; the comparative table meant the evidence took the hit instead of a person.

From concept to reality

Armed with a clickable prototype, we tested with sales users, gathered stakeholder feedback and refined, round after round. As implementation approached, I became the mediator between design aspiration and technical reality, learning to defend design choices with conviction while staying open to technical feedback.

Measuring success

Behind the numbers: improved customer satisfaction, more bid-to-order conversions, a stronger revenue funnel, and the direction itself changed as the business began building the alternative quoting journey.

What I carry from this

Adapt the artefact to the audience. A blueprint nobody opens is a service that never happened. Say no with conviction and rationale. A transparent test anyone can attack turns career risk into design leadership. Human-centricity is a mindset, not a deliverable. It has to reach every decision, including the unglamorous ones about Excel.

Context

It began with a job-interview assignment. What seemed like a standard task became a passion project, one that led me, quite literally, to the doors of the National Museum. The challenge: make museums more appealing to India's youth.

Starting with the history

I began with the essence of the thing itself, tracing "museum" to its Greek root, mouseion, a seat of the Muses, and following the idea from Roman times to the present. Museums have moved from places of preservation, to spaces of exhibition, to what they are becoming now: a medium for experiencing our past.

Casting the net wider

I researched global initiatives in museum technology, the pros and cons of digitalisation and the tools museums use worldwide, then mapped the ecosystem itself: the web of visitors, researchers, curators and government officials that keeps these institutions alive.

Boots on the ground

Theory only goes so far. I visited the Rashtrapati Bhawan Museum and the Red Fort Museum in Delhi, observing visitors and the state of digital integration, and interviewed a deliberately diverse group: a National Museum official, a curator, representatives from the Bihar State Museum and the Government of India, and a teacher leading a school trip. Then an International Conference on Reimagining Museums in India, hosted by the Ministry of Culture, offered wider perspective and validated many of my findings.

What the research said

• Stories are missing. Objects sit labelled, not narrated.
• Data collection is limited, hampering informed decisions.
• Accessibility is routinely overlooked, with barriers the spaces were never designed around.
• Ambition outpaces operations. New museums struggle to maintain state-of-the-art equipment.
• Visitor fatigue is real. Sensory overload and a lack of seating shape the experience as much as the exhibits.
• The visit is not the relationship. Community participation, links with education, and engagement before and after the visit are what sustain a museum.

Visitor-motivation research gave the work its segmentation lens:

Personas

Defining the challenge

How might we bring culture, heritage and museums into the mainstream consciousness and educational discourse of society?

With that north star set, I ideated across four fronts: spatial and experience design, communication strategy, integration into school curricula, and technology for management and visitor experience. Each concept traced back to the insight that earned it. What began as an interview assignment ended as an informal pitch to National Museum officials.

What I carry from this

Start with the essence. Tracing what a museum is for gave every later idea a test to pass. Go and see. Desk research described museums; standing in them showed what visitors actually do. Design the whole relationship. The visit is one moment; what happens before and after decides whether people come back.

Context

When a large business signs an order, everyone celebrates the signature. What follows is weeks or months of work the customer rarely sees: details gathered, sites surveyed, equipment shipped, services switched on, and the customer kept informed along the way.

At British Telecom, that work was about to move onto a new platform, and the build money was already committed. But the journeys being moved lived in people's heads and in spreadsheets. Every large order was treated as a one-off, so every fix was a one-off too, and nothing added up.

My brief was to document the journey. But documenting a broken thing only gives you a well-drawn broken thing. So I asked a different question.

Why does it break, and what is actually different about a large order?

One engine, wrapped by hand

The answer became the thesis the rest of the work stands on.

To test the thesis rather than assert it, I broke "large orders are just complex" into four things that could be checked: who the customer is, how the service is managed, what is being bought, and how complicated the set-up is. Then I mapped the manual layer itself, drew sixteen views of how delivery actually ran, and catalogued every bespoke variation. They fell into nine families. The bespoke part turned out to be small; the shared engine was large.

Dozens of problems, one cause

The programme had logged dozens of pain points, most of them rated high or critical. On a list, they looked scattered across every stage. Traced properly, all six root causes were facets of the same thing: manual re-keying, spreadsheets and chasing, done by hand by service teams and order managers. Fix that layer and most of the pain goes with it.

One stage alone, gathering the order details after the sale, caused well over a third of all delay, hiding in plain sight. And because a service is defined by how it fails, I worked through dozens of ways an order goes wrong and consolidated them into a set of designed recovery paths.

Design once, compose many

Fixing one journey at a time would only repeat the problem, so I designed building blocks instead: sixteen journey patterns and ten smaller components, each framed around the job it does. A component is specified like an interface (what triggers it, what goes in, what comes out) because on its own it isn't a journey.

The future state was traced, not asserted: eleven experience principles, each with a simple test; a north star of full order visibility, unlocked for customers step by step; and an end-to-end journey in which every capability traces from a pain point, to its fix, to a delivery ticket.

Every ticketin the backlog traced to a pain point and its fix

Delivery blockstickets grouped into coherent chunks of work

Quick winsthe lowest-risk work, ticketed to go first

Does it travel?

A method that works on one journey is a project. One that travels to another product line is a capability. So I took the same thinking further and built it into a library of reusable service blocks: stretches of journey designed once and in full, including what can go wrong and who puts it right. The library now holds a few dozen blocks, and a new journey is assembled from them rather than drawn from scratch.

Journey A · customer buys one product online

Discover›Check eligibility›Configure›Contract and consent›Submit order›Activate›Record what they own

Journey B · agent sets up three products for a new office

Discover›Check eligibility›Configure several products›Agent builds the order›Customer approves by link›Submit order›Orchestrate dependencies›Engineer visit›Activate›Record what they own

Shared block, used as isSwapped for a variantAdded

Then I tested the library on a harder case: three different ways to buy the same product, led by an agent, done by the customer alone, and approved by the customer through a link. Assembled from one library, around 93% of their blocks were shared, and each journey took hours rather than days. Only the parts that genuinely differed had to be designed, and everything shared arrived already tested, with its failure paths and owners in place.

So that the approach outlives any one project, I designed a hands-on session that teaches other designers to compose journeys from the library instead of drawing them, and sends them back to their teams with one question to ask whenever a new blueprint is requested: which blocks?

What changed

The wrapper thesis was adopted as the programme's working model, redirecting investment from one-off fixes to shared architecture. Mapping the backlog into delivery blocks gave the programme a way to prioritise it didn't have before, and the quick wins gave it a low-risk place to start. The block library showed its value early, too: three different buying journeys built from it shared around 93% of their blocks, and each took hours rather than days to assemble.

Some of the value was estimated in the design itself. Gathering order details was identified as the single highest-leverage target, and one redesign, for equipment returns, came to over a thousand hours of manual work saved every month. The rest is projected and held to defined measures: cycle time, rework, manual touches per order, and satisfaction at the moments the order changes hands.

What I carry from this

Augment people; don't automate them away. A senior design lead challenged the automation direction: past a point, a great order manager is the relationship. The evidence agreed in part, so the design automates the mechanical layer and protects the relational one. Build blocks, not one-off fixes. It's slower to first value, but every journey after the first compounds the investment. Go deep before going wide. Large orders went to full design depth first, including every recovery path, because that's where the platform move carried the most risk.