AI savviness – how you design your work with AI.

Saying that you use AI is becoming as informative as saying that you use a computer. That part is no longer particularly interesting. Almost everyone uses it now. My archaeologist friends use AI in their work.

It reminds me of the time when “computer skills” appeared on CVs. At some point, the tool becomes infrastructure. Nobody needs to tell you they use a laptop anymore. What matters is what they can actually do with it. The useful professional question is no longer whether you use AI. It is what level of AI savviness you have developed around your actual work. And that level is not demonstrated by the number of tools you use or prompts you have collected. It shows in how well you understand your own work and how deliberately you can redesign parts of it with AI.

AI becomes personal very quickly

Unless we are talking about an organisational workflow designed for an entire team, AI often becomes an extension of the way an individual already works. Two Product Designers sitting next to each other, working on the same product and doing broadly the same job may need completely different AI workflows. One may automate documentation. Another may use AI primarily for synthesis. Someone else may build support for research, quality assurance or information management.

That is because our work is shaped not only by our job descriptions but also by our habits: how we organise information, where we lose time, what we check repeatedly, how we prepare before making a decision and which parts of the process create friction. It is a little like cooking. Most of us can boil water. What happens next depends entirely on what we are trying to make. AI works in a similar way. Access to the tool tells me almost nothing about the sophistication of the workflow built around it. That is why I have become less interested in collecting other people’s prompts and more interested in identifying repetitive parts of my own work and turning them into reusable skills and workflows. This is where AI savviness becomes a professional competency.

The skill is not simply knowing how to use AI. It is being able to recognise what should be systematised, define how it should work, provide the right knowledge and constraints, and build something you can reliably use again.

Recently, I have been doing this in two different areas of my Product Design work.

From UX finding to Jira-ready work

One recurring part of my work happens after I identify a problem in an implemented product. Finding the issue is only the beginning. I need to understand what is happening, evaluate its UX impact, collect evidence and communicate it in a form that can move further into delivery.

In one client project, I developed a repeatable structure for this transition. Each issue became a separate package following the same logic: context, steps to reproduce, expected and actual behaviour, user or business impact, proposed priority and supporting evidence such as recordings, screenshots or reference materials. I used this approach for real issues identified in the implemented product and delivered the resulting packages to the Product Owner as Jira-ready material.

This is a good example of the distinction I make when deciding what to automate. Identifying the problem, understanding why it matters and assessing its impact require product and UX judgement. Rebuilding the same documentation structure around every issue does not. Once I had defined what a useful ticket needed to contain, that repeatable part of the work could become an AI-assisted workflow.

The benefits:

• Speed: less time rebuilding the same documentation structure for every issue.
• Consistency: every problem follows the same Jira-ready logic and contains the information needed to understand it.
• Quality control: requiring expected behaviour, actual behaviour, impact and evidence exposes gaps before the material is delivered.
• More attention for UX judgement: the repetitive documentation is systematised while problem identification, analysis and assessment remain with the designer.

From “I can’t talk to users right now” to structured audience research

The second workflow started from a different constraint. Sometimes I need to investigate a product assumption but cannot quickly speak to users. That does not make desk research a substitute for user research, but waiting for perfect access is not always the best way to move a product question forward either.

I wanted a repeatable way to investigate what could already be learned from available evidence while keeping the limitations of that evidence visible. So I created an Audience Research Discovery workflow.

It starts with a deliberately small input: a problem, assumption or Job to Be Done, product context, user group and research constraints. From there, the workflow turns the input into a research focus, searches and evaluates potential sources, selects the strongest sources for deeper scanning, creates a project sheet and evidence table, analyses the collected material and produces a short decision-oriented summary. User voice and product documentation are treated as different types of evidence, and the workflow evaluates whether the available information is strong enough to continue. If it is not, it should recommend another source or a source pivot rather than manufacture a confident conclusion.

I used this approach when exploring what information could matter to business users working with shipment-management products. I did not have immediate access to those users, but I could investigate public reviews, discussions, comparable products and documentation to look for recurring behaviours and frustrations around searching, filtering, statuses, history and shipment management.

The benefits:

• A structured starting point: the output separates evidence, patterns, assumptions and unknowns rather than presenting everything as a research conclusion.
• Evidence quality control: sources are evaluated rather than simply collected, and weak evidence can trigger a source pivot.
• Faster early discovery: available evidence can move a product question forward while direct user access is still unavailable.
• Better preparation for validation: the workflow makes visible what we already know, what we only suspect and what still needs to be tested with users.
• Repeatability: the same research methodology can be applied to another audience or product question without rebuilding the process from scratch.

A reusable workflow requires more thinking than a reusable prompt

A skill or workflow requires me to understand the task well enough to describe how it should be performed repeatedly. That means defining what information is mandatory, what sources are acceptable, what good evidence looks like, which criteria should be checked, where uncertainty needs to be surfaced and where the process should stop rather than invent an answer.

Before I can automate part of my methodology, I have to make the methodology explicit. That exercise is useful in itself: it exposes assumptions that previously lived only in my head, forces me to define what I mean by “good enough” and separates decisions that follow repeatable rules from decisions that depend on context and experience.

This is also why I do not think sharing a library of prompts or skills is necessarily the end goal. Someone else’s workflow can be useful as inspiration, but the most valuable automations I have built are closely connected to the way I actually work. The more personal the workflow, the more important AI savviness becomes — because eventually you need to be able to build the tool you need yourself.

The next layer: design QA

I am applying the same thinking to another repetitive part of Product Design: auditing and verification. Many things we repeatedly inspect in interfaces are based on explicit bodies of knowledge: accessibility requirements and WCAG, usability principles, typography, interaction states and other established design rules.

I have started structuring knowledge and audit criteria around these areas so they can support AI-assisted UX and design reviews. An automated system can check defined criteria, surface inconsistencies and identify potential issues. Whether those issues matter in a particular context, what should be prioritised and how the product should respond remain different questions. The more clearly I can define that boundary, the more useful the automation becomes.

AI savviness is becoming part of the job

“I use AI at work.”

Of course you do.

The differentiator is what happens after that. Can you recognise where AI genuinely improves your workflow? Can you turn tacit knowledge into explicit rules? Can you distinguish a repeatable process from a contextual decision? Can you build reliable workflows around your own methodology rather than repeatedly starting from an empty chat window?

That is the level of AI savviness I am interested in developing: not learning how to ask AI to do my job, but learning my own work well enough to decide which parts of it I should never have to do manually in the same way again.

AI savviness – how you design your work with AI. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.