Designer for complex products and the systems behind them.

At NCRI, I was involved from the first meeting through live testing. The product was meant to replace a broken desktop application, scattered CSV workflows, delayed reporting, and a lack of visibility across collection teams.

The requirements changed quickly. What seemed correct one day could move in another direction the next. That forced me to work close to the people using the system and to keep asking better questions.

The important question was not only: What should this screen look like?

It was: What must remain clear as the case moves between people?

A collection agent needed to know what to do next. A manager needed to see where the operation needed attention. Another agent needed to pick up a case without reconstructing its history from several places.

That project taught me to look for continuity, ownership, cause and effect, and the hidden work beneath the interface.

I found the same pattern at TCP Software, but at a larger scale.

TimeClock+ had grown over many years without a documented design system. The product contained inconsistent patterns, unclear states, and decisions that were difficult to change safely. The instinct could have been to redesign everything at once.

I chose to audit and document the product first.

I mapped the existing interface, found the repeated patterns, built the design system, and used it to improve the product feature by feature. This gave us smaller things to prototype, review with customers, and improve before moving on.

That approach matters because users should not have to relearn an entire product to receive one improvement. Teams should be able to ship a useful change, learn from it, and keep moving.

A five-step modal that cannot save progress is not only a modal problem. It has failed to account for interruption, return, and the work the user has already completed.

When a problem is messy, I map what the user is trying to preserve, where the workflow breaks, which decisions are connected, what the team can change safely, how the next person will understand the work, and what we can test before building the entire solution.

I believe in incremental, modular design because it makes learning part of delivery. A smaller solution can be shipped, tested, questioned, and improved without forcing everyone to adapt to a completely new product at once.

That approach shaped my work at NCRI and TCP. It is also how I approach complex product requirements at TCP, including SSO workflows, Extra Duty Manager, the Substitute Agent Manager, analytics, design systems, and the Manager mobile app currently in development.

Alongside my professional work, I am studying design at BNU. It is part of how I continue developing my research practice, visual judgment, and understanding of people.

Computer science taught me how systems are built. Design has taught me to question whether they should work that way.

The work keeps moving between those two perspectives. I can prototype in code, question the experience in design, and bring the two closer before handoff.

The struggle with AI is real, but it is here to stay.

AI can help with research synthesis, exploration, prototyping, and repetitive work. It still struggles with long complex tasks, business objectives, product history, customer experience, and the context hidden between the lines.

I am an enthusiastic supporter of technological progress, but I do not believe AI removes the need for judgment. It changes where judgment is needed.

During the planning of a relaunch for Humanity's hardware products, six people spent three hours and 35 minutes working through the first meeting. Turning that conversation into something useful could have taken hours: who agreed, who pushed back, what remained uncertain, which decisions were high priority, and how the work was delegated.

AI turned the transcript into a clear working document in minutes. It surfaced the patterns, captured changes and removals, and made the conversation easier to act on.

That is where AI is especially valuable to me. It helps turn a large amount of information into a shape people can work with.

In the right conditions, development work that once took several sprints can move from an idea to a working prototype in weeks. AI helps me move faster, but I still decide what is useful, what is true, and what should be built.

I was born and raised in Abbottabad and later moved through Islamabad, Rawalpindi, Peshawar, and Lahore. Moving between cities has been a quiet but important part of my life.

Outside work, cricket is the constant. I play tennis, watch the occasional football match, hike when I can, and travel whenever life allows. I also have a weakness for action-packed movies.

I want to work on products where the hard part is not drawing another screen.

The hard part is making a complicated operation easier to understand, safer to change, and possible for a team to keep improving.