#elicitation

#elicitation

The /insights command analyzes the history of your commands in the last 30 days and generates a detailed HTML report with key findings and insights.

Voice interaction with Claude Code significantly enhances the user experience by allowing for faster input. Speaking is often 2-3 times quicker than typing, which can streamline the process of giving commands.

For decades in SAAS, products reduced ambiguity. Users supplied constrained inputs, and the system handled the output. It's never been Minority Report cinematic, but it was predictable. By providing predictable environments for manipulating data, users learned by moving things, adjusting variables - and the outcome emerged through interaction.

Capacity Planning is the process of right-sizing the 'Total Project Demand' with the forecasted Team Capacity. Most UX teams have no idea what their capacity is. Fewer still have a process for calculating it and using it during quarterly planning activities with their counterparts in Product Management & Engineering to ensure teams don't commit to more work than they can handle.

At some point, every UX learner realizes that having a portfolio isn't the same as having a convincing portfolio. You may have screens, wireframes, and prototypes. You may even have multiple projects. But when your work is reviewed, the feedback feels vague. "Tell me more about your process." "Why did you make this decision?" "What was the impact?" That's because a strong UX case study isn't a gallery of designs. It's an argument.

Your junior designer spins up a prototype in Lovable before lunch. Your PM shows you a "working" MVP built entirely with Cursor within a day. And your CEO forwards you a LinkedIn post about how AI will replace 80% of UI work by 2026. And it seems like anyone can now make an app to solve a specific problem. Has the graphical interface really died, as Jakob Nielsen provocatively suggests?

The question dropped into the Slack channel before the user research summary. Before the problem was clearly defined. Before anyone asked if users actually needed this feature. Your product manager already generated three interface options in ChatGPT. Now they're asking which one to build. Not whether to build. Not why to build. Which. And when you slow the conversation down to ask those questions, you're about to discover that strategic thinking now reads as bottleneck behavior.

My role was straightforward: write queries (prompts and tasks) that would train AI agents to engage meaningfully with users. But as a UXer, one question immediately stood out - who are these users? Without a clear understanding of who the agent is interacting with, it's nearly impossible to create realistic queries that reflect how people engage with an agent. That's when I discovered a glitch in the task flow.

During my eight years working in agile product development, I have watched sprints move quickly while real understanding of user problems lagged. Backlogs fill with paraphrased feedback. Interview notes sit in shared folders collecting dust. Teams make decisions based on partial memories of what users actually said. Even when the code is clean, those habits slow delivery and make it harder to build software that genuinely helps people.

My role was straightforward: write queries (prompts and tasks) that would train AI agents to engage meaningfully with users. But as a UXer, one question immediately stood out - who are these users? Without a clear understanding of who the agent is interacting with, it's nearly impossible to create realistic queries that reflect how people engage with an agent. That's when I discovered a glitch in the task flow. There were no defined user archetypes guiding the query creation process. Team members were essentially reverse-engineering the work: you think of a task, write a query to help the agent execute it, and cross your fingers that it aligns with the needs of a hypothetical "ideal" user - one who might not even exist.