Bringing AI Into the Product Design Practice

Changing how far Design could take a product problem

The design team was small relative to the breadth and complexity of the product. We needed to support delivery while contributing earlier to discovery, improving interaction quality and strengthening Design’s influence over product decisions.

I became interested in AI less as a way to generate screens and more as a way to reduce the distance between understanding a problem, exploring it and having something realistic enough to evaluate.

I experimented hands-on across research synthesis, problem framing, interaction design and coded prototyping, then brought the approaches that proved useful into critique and day-to-day project work with the design team.

Use AI to compress the work, not skip the thinking.

Move Design closer to production

The same approach became useful beyond prototypes. Altus had a recurring gap between designed interfaces and what reached production, so I worked with the CTO and Engineering Lead on a more direct route for Design to influence reusable product components.

Using AI-assisted coded design, I could work closer to the component itself, refining layout, interaction behaviour and states before Engineering reviewed the implementation for production use.

Column-header filtering was the first pattern to progress through this approach into the production Design System. It showed that AI-assisted design could reduce some of the translation between design intent and implementation without bypassing Engineering ownership of production code.

Start with context, not generation

Rather than asking AI to invent a solution from a blank prompt, I grounded it in product documentation, customer feedback, existing workflows, domain knowledge and technical constraints.

context → problem framing → exploration → working behaviour → critique → refinement

AI could accelerate synthesis and exploration, but the output still needed to be challenged against the product problem, customer evidence and domain constraints. People remained accountable for the design decisions.

That became the basis of a context-first approach I used across ChatGPT, Claude, Claude Design, Claude Code and Figma Make.

Treat working software as a design material

Coded prototyping changed what I could evaluate during design. Static screens are useful, but they can hide important behaviour. Working prototypes expose states, focus, overflow, responsive behaviour and the consequences of interaction much earlier.

A Microsoft Teams timesheet concept became one clear test. Using the context-first workflow, I moved from product framing to a runnable interactive prototype. The important result was being able to critique realistic behaviour while the product direction was still easy to change. See the Timesheet case study →

From experiments to a more deliberate practice

The useful experiments became a small set of working principles for how I and the design team used AI:

• Establish product context before generating.
• Use AI to explore possibilities rather than provide unquestioned answers.
• Validate outputs against customer evidence and domain constraints.
• Use working prototypes when behaviour matters.
• Keep people accountable for design decisions.
• Distinguish design prototypes from production engineering.
• Reinvest saved effort into better thinking, not simply more output.

This was still developing when I left Altus. I would not claim every designer used the same workflow consistently, describe it as an organisation-wide AI transformation, or claim measured evidence that it reduced total product-delivery time.

The more important shift was in where Design could contribute. AI made it practical to move more continuously from understanding a problem into realistic behaviour, while leaving more room for judgement, critique and product thinking.