How I work.

Designing under constraint

A secure, regulated environment shapes how I work. I work through governance and approval requirements, documenting the evidence behind my decisions so reviewers can assess them. The reasoning behind a design needs to be clear enough for others to assess, alongside the design itself.

That means paying attention to what a decision is based on, which constraints it addresses and what remains uncertain. I need to make the work understandable to colleagues involved in review and delivery, while respecting the limits on what can be shared.

Using AI to make ideas testable

I mainly design in Figma and now use AI tools almost daily. My toolkit includes Claude Code, Figma Make, Figma’s agent and ChatGPT with Codex. I use them for inspiration, early iteration and working implementations. For prototypes, I give Claude Code access to my Figma designs through the plugin and provide the context it needs to build an interactive version.

More recently, I have also used Claude Code for high-fidelity prototypes, turning to Figma Make when an implementation needs another approach. I remain responsible for judging the output against the design intent and research, and for respecting what can leave a controlled environment.

“I remain responsible for judging the output against the design intent and research.”My responsibility when using AI

A framework, and where it bends

I work to the Double Diamond, from the Design Council’s Framework for Innovation. At Northrop it gives me a shared language with customers and clients. Discover, Define, Develop and Deliver help a mixed group agree where we are in the work and what a decision at that stage costs.

The framework has to bend under real constraints. In a secure environment, who I can speak to and what I can ask depend on more than the research question. Discovery becomes a judgement about which evidence is obtainable and how much weight it can carry. Delivery also extends into approval and assurance: the design and its reasoning need to survive review.

Engagement and leadership matter throughout. Access to customers shapes the evidence available. Owning a design system means deciding what becomes a shared pattern and holding that consistency across teams with different delivery pressures.

Royal Nawaab shows those constraints in public work: roughly eight weeks alongside my main role, four paired research sessions, no usability-testing round and an existing booking provider I could not redesign. The process adapted to the time and scope available. The case study explains the research limitations and what I would evaluate with more time.

Owning the design system

I am the sole owner of the design system used by six Northrop-owned products. I work to maintain consistency while teams face their own delivery pressures. Part of that responsibility is deciding when a requirement belongs in a shared pattern and when it should remain specific to a product.

Ownership also means challenging unnecessary variations. An existing pattern gives teams a starting point, but I still need to understand whether it fits the task. I challenge proposals to introduce a different version of something the system already supports.

Working inside established systems

I have designed within GDS and ICDS, using established components and patterns. The task is to understand what the library already supports and extend it appropriately when there is a need. That experience informs how I approach consistency and the boundary between shared patterns and product-specific requirements.

Leading across concurrent projects

I currently lead UX across three separate projects. Prioritisation and sequencing are a substantial part of that role: deciding where design attention is needed and how work can move forward within the available time.

I clarify requirements, explore concepts and develop reusable interface patterns with delivery colleagues. That work connects individual design decisions to the wider pattern library and the practical constraints of delivery.

Developing other designers

I line-manage two junior UX designers who report directly to me. Our fortnightly check-ins cover support, wellbeing and the work they are doing. Mentoring is a regular part of that relationship, alongside helping them work towards their development goals.

I support goal-setting in Workday and conduct annual performance reviews. I use those conversations to connect support on current work with each designer’s development goals. My responsibility includes making time for concerns and feedback, rather than limiting our conversations to the status of a deliverable.