Before I knew I was a Product Designer

Around 16 years ago, while working within Citi’s middleware and web hosting environment, I designed and built an internal application in Excel and VBA to support the Technology Infrastructure Chargeback process.

At the time, I did not think of this as product design. I thought I was simply solving a business problem. Looking back now, I can see that this work involved many of the same skills I use today, understanding complex workflows, translating business rules into software, and creating tools that people could actually use.

The application went on to support a departmental workflow used by more than 400 employees.

Role: Internal tool designer and builder
Organisation: Citi
Team: Middleware and web hosting, working alongside infrastructure leadership and security stakeholders
Responsibilities: Workflow design, business process automation, internal tooling, enterprise UX, operational efficiency
Platform & Product Type: Excel + VBA, Internal enterprise application
Year & Users: 2010, 400+ employees
Status: Ongoing/Live: Then – Original internal application built approximately 16 years ago / Now -Reframed and reimagined through a modern product design lens

I was working in Citi’s middleware team, within a broader enterprise technology environment shaped by infrastructure delivery, compliance, technical standards, and security.

I worked under leadership responsible for middleware delivery and resourcing across EMEA, ensuring that solutions met build and compliance standards. I also worked closely with a security consultant who has since gone on to lead in cybersecurity within Citi.

This meant I was exposed early to the realities of enterprise systems, not just the visible interfaces, but the operational, technical, and governance layers that sit behind them.

I still remember touring Citi’s vast data centres and being completely in awe. It gave me an early appreciation for the invisible infrastructure behind digital systems, something that continues to influence how I think about digital products and ecosystems today.

I took full ownership of redesigning an existing internal Excel and VBA tool used within Citi’s Technology Infrastructure Chargeback process. My role was to improve how the tool worked for employees, restructure the experience, and translate a complex operational process into a clearer and more usable workflow. I worked within a highly technical environment alongside middleware, infrastructure and security colleagues, and the redesigned tool went on to support a departmental workflow used by more than 400 employees.

Ownership: led the redesign of an existing enterprise tool from problem identification through to implementation.

Systems thinking: translated business rules, process steps and technical constraints into a clearer user experience.

Collaboration: worked within an enterprise environment shaped by middleware delivery, infrastructure standards, compliance and security.

Adoption: the redesigned tool supported a workflow used by 400+ employees.

The tool supported Citi’s Technology Infrastructure Chargeback process, an internal operational process concerned with how technology infrastructure costs were tracked, organised, and allocated.

Although I no longer remember every detailed workflow step, I do remember the core challenge clearly: this was a complex internal process that needed to be structured in a way employees could use consistently and confidently.

The process sat within an enterprise environment where accuracy, clarity, and compliance mattered. That meant the tool needed to help people move through the workflow reliably, reduce manual effort, and make the process easier to manage at scale.

What I was actually doing, in today’s language

At the time, I did not have the vocabulary of product design. But looking back, this work involved many of the same activities I now associate with modern digital product practice.

I was:

• understanding a complex internal process
• turning business rules into software logic
• structuring a workflow for employee users
• designing interactions inside the limits of Excel and VBA
• improving consistency across a shared process
• creating an internal tool that people adopted and used at scale

Today, I would describe this work as a combination of:

• enterprise product design
• internal tooling
• workflow design
• business process automation
• UX thinking
• early UX engineering

The strongest outcome was adoption.

This was not a private spreadsheet or an isolated experiment. The tool became part of a real departmental workflow and was used by more than 400 employees.

That level of usage suggests the solution provided meaningful operational value. It helped bring structure to a complex process, supported consistency across teams, and showed me early on that I was capable of designing tools that people would genuinely rely on.

If I were approaching the same problem now, I would bring a much more formal product design process to it.

I would begin with deeper workflow mapping, stakeholder interviews, user journeys, task analysis, and clearer success measures. I would also explore the most appropriate platform for the problem, whether that meant a web application, an internal workflow platform, or another enterprise solution.

What has stayed the same is the core design challenge: taking a complex organisational process and turning it into something people can use with clarity and confidence.

Modern concept exploration

To revisit the spirit of this work through a modern lens, I explored a new internal concept called Projects.

This concept is not presented as a literal recreation of the original chargeback tool. Instead, it is a modern design exploration inspired by my earlier experience building enterprise tooling within Citi.

The goal was to imagine what a contemporary internal product might look like today, one that helps teams plan, track, and deliver work across a complex organisational environment.

This exploration includes both polished interface concepts and raw wireframe studies, showing how the product might evolve from early structure into a more complete system.

This project now means even more to me than it did at the time.

When I originally built this tool, I did not think of myself as a product designer. I simply knew there was a complex process that needed to work better. Looking back, I can now see this project as an early foundation for the work I do today.

The tools have changed. The language has changed. But the core challenge remains the same, understanding complexity deeply enough to turn it into something useful, usable, and valuable for people.