How I Use AI for UX/UI research and design

AI has now become part of my research and design workflows, but not in the way most people imagine. I use it more like a collaborator, or copilot, similar to how Tony Stark uses J.A.R.V.I.S.

This article breaks down how AI fits into my day-to-day workflow, the tasks I use it for, the tasks I deliberately keep human-led, and some of the tools and systems I have built along the way.

Figure 1: Early AI-assisted workflow from Figma screens to testable prototype.

The approach

The way I use AI is task-specific.

I use it for tasks that are repetitive, high-volume, or useful as a first pass, reviewing source material, processing transcripts, clustering responses, generating prototype code, or drafting rough content.

I avoid using it when the work requires accountability, context, or interpretation that should come from the researcher or designer.

Figure 2: How AI involvement changes across my research and design workflow.

I work within levels 01 to 04. Level 05 is not part of my workflow. I do not entirely hand over the research interpretation or product direction to a model.

Level 02

I lead, AI supports

Getting up to speed on a new domain

When I join a project in a technical area I am not familiar with, I use AI to work through source material faster.

For publicly available material, I use NotebookLM. For confidential project material, I use a local RAG pipeline in n8n, so client documents stay on my machine and are not sent to an external service.

This helps me build enough context to ask better questions early in the project. It does not replace reading, interpretation, or follow-up with the team. It gives me a faster way to understand the landscape before I start making research or design decisions.

Figure 3: NotebookLM workspace used to query public source material and build domain context faster.
Figure 4: Local n8n RAG pipeline used to query confidential project documents without sending them to external tools.

Update

I recently started using Open WebUI as my main interface for local model work. My n8n RAG pipeline was the earlier setup; Open WebUI now gives me a cleaner way to manage project knowledge, reusable prompts, and local workflows.

Understanding user sentiment at scale

On one project, I needed to review several hundred user reviews to understand where a service was falling short. So I built a pipeline from my existing understanding of how aspect based sentiment analysis works, some articles and GitHub repos.

This pipeline read each review and sorted it into a fixed set of categories I had defined in advance. The system handled the volume. I defined the categories, checked the output, and interpreted the patterns. This made the process faster.

The pipeline showed which categories were discussed positively or negatively and how often they appeared, giving me a structured view of sentiment at scale. But deciding which patterns actually mattered for the product was still my job.

Figure 5: n8n workflow that turned large sets of user reviews into structured sentiment data.

Reference behind the workflow

This pipeline was adapted from a zero-shot aspect-based sentiment analysis proof of concept and the ABSA prompt repo referenced with it. I used them as a starting point, then rebuilt the workflow in n8n around my own review sources, categories, and output format.

Drafts and brainstorming

I also use AI for early drafts: emails, research planning notes, scaffolding documents, and rough concept directions.

I treat these outputs as starting material, not final work. Anything client-facing goes through a full review and rewrite before it leaves my desk.

This is useful when I need momentum. It helps me get a rough version on the page so I can start editing against something.

Level 03

AI does the first pass, I refine it

Prototyping for usability testing

On a project involving a scanning workflow for a retail store staff, a standard Figma prototype was not enough. Participants could follow the screen flow, but they could not experience how the scanning interaction would behave in practice.

So I built a browser prototype that could show scan success, scan failure, and the states in between. I used Figma’s MCP server and AI-assisted code generation to move from designed screens to a working prototype, while defining the interactions and constraints myself.

This made the usability sessions more realistic. Participants could react to timing, failure states, and recovery flows instead of imagining them from a click-through prototype.

Figure 6: Evolution of my workflow from static handoff to AI-assisted prototyping.
Figure 7: Refined pipeline for building prototypes from Figma screens.

Level 03

AI does the first pass, I refine it

Transcription

Interview and meeting recordings go through a local transcription pipeline I built using Whisper.cpp, an open-source speech recognition tool.

The transcripts are produced automatically and stay on my machine throughout the process. This matters because most interview content is confidential. This keeps transcription local on my machine.

The transcript is still reviewed before analysis. The automation saves time, but I do not treat the raw transcript as perfect.

Figure 8: Local Whisper.cpp workflow used to turn interview recordings into timestamped transcripts for review.

How I structure prompts

Brief, Ask, Scope, Examples

I use BASE to give AI enough context before asking for an output. It helps me define the brief, the task, the limits, and what good output looks like.

For quick tasks, I use the same thinking informally. For complex work, I write each part deliberately so the output is easier to review and refine.

I also store reusable prompts in Open WebUI along with project knowledge, saved instructions, and custom tools I use across my local AI workflow.

Figure 9: BASE framework for writing structured AI prompts.

Staying current

I try to stay close to AI in two ways

  1. Tracking what is changing,
  2. Learning from people applying it to real research work.

For regular updates, I follow a mix of AI company blogs, newsletters, podcasts, and independent creators. These help me understand where the tools are heading and which changes are actually relevant to my workflow.

I also look for structured learning that goes beyond tool updates. Recently, I joined Debbie Levitt’s AI and Excellent Research course focused on using AI in qualitative research. Her Claude Skill and approach to reviewing AI outputs helped me think more clearly about where AI can support research.

My overall goal is not to chase every new AI tool. It is to understand which changes actually affect how research, design, prototyping, and product decision-making can be done.

Sources I follow regularly

The links below are the sources I check most often across AI updates, product shifts, tooling, and broader technology context.


Up Next

Rapid Prototyping with Figma MCP and AI preview

Rapid Prototyping with Figma MCP and AI

Figma frames to an interactive, session-ready prototype.