# Konigi

> Essays, tutorials, and resources on combining design thinking with AI-assisted building. By Michael Angeles.

AI makes building easy. Building the *right* thing still takes design thinking. This site is a working notebook on designing and building with AI — focused on people shipping products with Claude Code.

## Writing

- [How to Research a Company's UX in 30 Minutes Before Your Next Interview](https://konigi.com/articles/how-to-research-a-companys-ux-in-30-minutes-before-your-next-interview): A repeatable workflow for pulling real UX sentiment about any company's product, turning it into talking points, and walking into the interview as a peer instead of a candidate. Worked example with a real company. Includes a downloadable Claude skill.
- [Claude Design has the incumbents scrambling](https://konigi.com/articles/claude-design-has-the-incumbents-scrambling): Anthropic shipped Claude Design a month after Google's Stitch 2.0. Everyone's watching Figma. The tools that should actually be nervous are Lovable, Bolt, and everything in that lane.
- [Think first, prompt later](https://konigi.com/articles/think-first-prompt-later): Generative coding with AI makes building easy. Building the right thing still takes design thinking. Here's why that matters more, not less, in the age of AI.

## Pages

- [About](https://konigi.com/about): Michael Angeles — product designer, former Balsamiq designer for 15+ years, co-author of *Wireframing for Everyone*, now building with Claude Code.
- [Resources](https://konigi.com/resources): Curated tools and links for designing and building with AI.
- [Contact](https://konigi.com/contact): Get in touch.

## Feeds

- [RSS](https://konigi.com/rss.xml): Full article feed.

---

# [How to Research a Company's UX in 30 Minutes Before Your Next Interview](https://konigi.com/articles/how-to-research-a-companys-ux-in-30-minutes-before-your-next-interview)

> A repeatable workflow for pulling real UX sentiment about any company's product, turning it into talking points, and walking into the interview as a peer instead of a candidate. Worked example with a real company. Includes a downloadable Claude skill.

I got an interview for Staff Product Designer. I had a couple of days to prep, so I sat down to do what designers have always done before an interview. I dug into the product.

My first instinct was to build a tool to do the research because I'm a builder. The thought was this, "I can build a little app that pulls reviews from G2 and Capterra and the App Store, runs sentiment analysis, and shows me the points of pain and friction. It'd help with every future interview. Maybe it could be a side product."

Thankfully I paused and caught myself before heading to the terminal. I'd build the tool, get sucked into scrapers and rate limits and anti-bot protection, and maybe I'd have a half-working tool in a few days and zero research done for the actual interview that's happening. Pausing for self-reflection as a practice saved my bacon today.

So I did the boring, correct thing instead. I just did the research in Claude by hand. It took 30 minutes. It produced better material than any tool I could have built. Then I turned the workflow into a Claude skill so I can do it again in 10 minutes next time.

Here's the workflow and what it gives me for my interviews. The skill is at the bottom of this post.

## Why some candidates don't do this

Walk into a design interview and ask "what are your biggest UX challenges?" and you've told the hiring manager three things:

1. You didn't use the product.
2. You don't have your own opinions yet.
3. You expect them to do the work of framing the conversation.

We may do this because real research can take a full day. You had to find the reviews, read them, organize them, write up patterns, formulate questions.

The economics are different now. With Claude doing search and synthesis in parallel, you can do that whole pass in 30 minutes. Which means there's no longer an excuse not to.

Now, I should say, this is a summary of what's been extracted from the sources this skill searches. It's your job to review for yourself to think critically about the output and think through the issues raised.

## The 30-minute workflow (as summarized by Claude)

The skill goes through seven steps after you pass the name to it. Duration is a rough estimate.

**Step 1: Scope (2 minutes).** Names the product and note whether it's B2B SaaS, consumer mobile, consumer web, developer tool, marketplace, or mission-driven tech. Different categories have different signal-rich sources.

**Step 2: Broad search pass (10 minutes).** Do six or so parallel queries: G2 reviews, Capterra reviews, App Store reviews if mobile, Reddit, "alternatives to X" (reveals competitive friction), and Glassdoor (for internal product team complaints). Capture verbatim quotes with source names.

**Step 3: Friction-targeted pass (5 minutes).** Search with negative-sentiment anchors: `[product] frustrating`, `[product] confusing`, `[product] missing feature`, `[product] doesn't work`. Different sentiment words surface different shapes of complaint.

**Step 4: Read the product's marketing (5 minutes).** Reading marketing first anchors you to the team's framing. Read it last and the gap between promise and reality jumps out.

**Step 5: Pattern-match (5 minutes).** Group complaints into categories: wayfinding, error handling, onboarding, performance, feature gaps, integration friction, pricing clarity. If two or more independent reviewers mention the same thing, it's a pattern. One-off complaints are noise.

**Step 6: Generate improvements and questions (5 minutes).** For the top two or three patterns, draft a concrete change and the framing for a question. Each question should reference a specific finding, not a generic platitude.

**Step 7: Write it up (5 minutes).** Friction patterns with quotes. Two or three improvements. Three to five questions. Under 1,500 words. If it's longer, you're hedging.

That's it. The whole thing is in a Claude skill I'm sharing below.

## Review the output

I ran this pass on the company I was interviewing with. For an example of what it outputs, here's a sample of what the research produced using Notion.

> ### Notion UX Sentiment Research
>
> **Sources scanned:** G2 (10,149 verified reviews), Capterra (4.7/5 across 2,000+ reviews), Reddit (r/Notion), UX Planet, Medium, Hacker News, and targeted Google searches across alternatives discourse.
>
> **Time spent:** ~30 minutes of search and synthesis.
>
> #### The pattern: the flexibility that sells Notion is the same thing that breaks it
>
> Every major friction cluster in Notion traces back to one architectural decision: the product is a canvas, not a system. That's the pitch and the problem. Power users love it. Everyone else hits a wall somewhere between "open blank page" and "have a working workspace." The complaints are not random — they cluster around four consistent themes, and they've been consistent for three years across independent reviewers.
>
> #### Top friction patterns
>
> 1. **Blank canvas paralysis.** New users open Notion and find themselves asking "What's a block? What's a rollup? Why are there five database types?" The template gallery partially addresses this, but templates teach the format, not the logic. Users still have to understand the underlying data model before the tool clicks.
> 2. **Search doesn't scale with the workspace.** The more information lives in Notion, the harder it is to find anything. Quick Find doesn't cover subpages. There's no global search across databases from the main search bar. The painful irony: Notion markets itself as a second brain, but the search behavior actively undermines that promise at scale.
> 3. **Performance degrades once teams actually use it.** Databases over 5,000 rows load in 3–5 seconds. Databases over 10,000 rows make Notion "impractical as a primary database" for enterprise teams. The root cause is architectural: Notion stores every element as an individual block in a centralized database, which creates exponentially more overhead as workspaces grow.
> 4. **The May 2025 AI pricing change felt like a bait-and-switch.** In May 2025, Notion retired the $10/month standalone AI add-on and bundled AI exclusively into Business and Enterprise plans. Free and Plus users now get 20 lifetime AI responses — total. Reddit's reaction was mostly negative.

## What this gets you

A few things change when you walk in with research like this.

* Asking a question about a valid concern gives the interviewer a sense that you've done the work to research the product. With luck, the conversation might start to feel like a peer conversation, rather than a candidate audition.
* You stop being the candidate and the interviewer may see you as a person who could already be on the team who's just having a working conversation about the product.
* You catch signals you'd otherwise miss. For instance, if you ask about IA work and the interviewer's answer treats it as cosmetic, you learn something important about the role.
* Interviews are designed around them evaluating you. Research flips part of that. You're evaluating them too, with specifics.
* You give the hiring manager a clean way to advocate for you. After the interview, when they tell their team about the candidates they met, you're the one who said something concrete about the product.

## Why this is pairing, not prompting

The instinct some might have with Claude is to write one long prompt and hope it works. "Research [Product X] for me and give me everything I need for my interview." That's transactional prompting. You ask, Claude answers, you take what comes out.

Pairing is different. You stay in the loop. You read the first round of results, you notice a pattern, you steer the next search at a friction word, you read the marketing site after the reviews not before, you push back on a finding that feels thin. You don't leave your critical thinking behind.

The skill I'm sharing below codifies that pairing pattern. It's a workflow with checks and time-boxes and decisions about when to stop collecting and start synthesizing. This is the difference between designers who use AI well and designers who don't.

Stay in the loop. Don't outsource the thinking. Use the model to optimize the parts that can be executed to make you efficient (search, parallelism, formatting). Hold onto the parts that shouldn't be left to the LLM (judgment, pattern recognition, what to ask next).

## The skill

I packaged this as a Claude skill you can drop into your Claude Code setup or use as a workflow template in Claude chat. It includes the methodology, the source matrix by company type, and the query patterns that consistently surface real friction.

Download and instructions: https://github.com/jibbajabba/ux-sentiment-research

---

# [Claude Design has the incumbents scrambling](https://konigi.com/articles/claude-design-has-the-incumbents-scrambling)

> Anthropic shipped Claude Design a month after Google's Stitch 2.0. Everyone's watching Figma. The tools that should actually be nervous are Lovable, Bolt, and everything in that lane.

Anthropic launched Claude Design on April 17, 2026. Three days earlier, Mike Krieger, Anthropic's CPO, stepped down from Figma's board. Figma's stock dropped 7% the day of the launch.

Google released Stitch 2.0 on March 20, 2026. Infinite canvas, multi-screen consistency, voice input, a Direct Edit feature, an MCP server, and a path to AI Studio for development handoff.

Anthropic shipped Claude Design a month later. I don't know if Anthropic's move was a reaction to Stitch, and maybe it doesn't matter. But in the battle for the desktop, Google and Anthropic are going at it at breakneck speed.

My read is that Anthropic already had the product in hand and waited until they could ship it alongside Opus 4.7. Whether or not that's right, the sequence of events from Krieger stepping away from Figma, to Anthropic's release of Design signals a commitment to the already-crowded category of generative product design tools.

## Who actually needs to worry

I don't know if Figma is the target for now. I've seen plenty of "Figma is dead" comments, but what I've learned from being around awhile is that "____ is dead" pronouncements and lines in the sand can be premature. But I don't think Figma is dead yet.

As someone who designs in code, I can't get past the fact that 99% of design jobs require Figma. It's just where teams manage their design tokens, run design reviews, and where the mega companies keep their design system source of truth for multi-product systems. Claude Design doesn't do any of that, and Anthropic isn't pretending it does. The Canva partnership makes the positioning explicit. What Claude Design produces in a few iterations seems like a really good draft, but not yet a replacement for a final product. But this is early days, and there's no denying that the output is impressive.

The tools that should be watching this closely for now are the ones sitting in the same lane: Stitch, Figma Make, Lovable, v0, bolt.new. The "describe a thing, get a working prototype" category of apps. Claude Design isn't at feature parity with any of them on depth yet. Lovable and Bolt generate full-stack apps with auth and a database. v0 has a mature component library integration. Stitch has multi-screen canvas and voice.

But Claude Design has two things none of them do as well at the moment:

1. **It reads your codebase to extract your design system.** Point it at a repo, and every project after that uses your actual colors, typography, and components. Stitch has theme-level customization. Lovable, Bolt and v0 can import a Figma file. Claude Design infers the system from production code.
2. **It hands off directly to Claude Code.** When a design is ready to build, Claude packages it into a bundle that Claude Code can pick up with one instruction. That's vertical integration between the design surface and the agent that writes the code.

The second one is a structural advantage. Stitch can export to AI Studio. Lovable generates its own backend. But my guess is that a majority of developers that are actually shipping AI-assisted products right now are mostly using Claude Code. This move to ship a design tool that talks to the coding agent that these devs already trust might be hard to counter from the outside.

## My first tries with it

A few experiments from the last week:

**Generating a design system from a Figma project.** I pointed Claude Design at a Figma file and had it extract a system I could then apply to new screens for a prototype. The result took a while and wasn't production-ready, but it was close enough for having a conversation about the design with the client.

**Redesigning pitch deck slides with context-aware illustrations.** A colleague has a pitch deck he's been working on for an agency. I copied three slides from it and asked Claude Design to redesign them with animated illustrations tied to the topic of each slide. I was impressed by how well the illustrations actually corresponded to the content.

**Swiss grid variations from a single portfolio screen.** I gave it the first screen from my portfolio and asked for layout variations based on different grids drawn from Josef Müller-Brockmann's principles. It understood the grid system as a design constraint and generated layouts that respected it.

**A full DIY environment for konigi.com.** I have a playground site that I wanted to turn into a DIY-themed environment for fun. I generated a graphic to establish the scene, then gave it to Claude Design and asked it to build the experience around that graphic. What I got back was closer to a site than a mockup.

None of these are shippable without my hands on them. All of them compressed what could have taken me a week of exploration into a few hours.

## What this may foretell

Right now, Claude Design and Stitch are positioned as generation tools. You describe something, they produce something. The output keeps getting better and better, but it's still a first draft that you either refine in chat or export to a real design tool or code for polish.

The scenario worth thinking about is what happens when the generative layer becomes the ideation surface for serious design work, and the professional tools have to rethink what they're for.

Claude Design offers inspector-level control over individual elements. It enforces design-system consistency at generation time. It supports agentic coding of full application flows from the same canvas. If it keeps going that way, the thing Figma does best — fine-grained manipulation of screen elements — starts to look like a subset of what a prompt-native tool can do.

AI tools like these are closing the gap between ideation, specification, and implementation into a single surface. Figma won the design tool category by collapsing design and collaboration into the browser. It's not radical to imagine that the next collapse is design, specification, and code into the agent.

When that happens, the question for designers isn't "which tool do I use" but "what am I actually doing that the tool isn't." And the answer, as I keep writing here, is design thinking. Knowing what to build, figuring out the right problem, and making decisions a prompt can't make for you.

The output of Claude Design can be stunning and still not be the thing that closes the gap between an idea and a product that works for its users. The outcome is what matters, and the outcome still depends on someone who knows what they're trying to accomplish and can judge whether the generated work gets them closer.

The tools are getting very good at outputs and Anthropic made that more obvious. The work moves upwards toward outcomes, problem definition, and the judgment calls a prompt can't make for you. Knowing what to build, and whether what you got is any good? That's still on you.

## Where do we go from here?

Claude Design is a research preview. Features will change, limits will shift, and some of what I described above will break or get reworked before it stabilizes. That's the nature of a Labs release.

But the shape of things to come is becoming apparent. One of the foundation-model companies shipped a design product, tied it to its coding agent, and did it a month after its biggest competitor's major release. Those are big moves in a software category and it will have an effect on incumbent tools in this space.

If you're a designer watching from the outside, the takeaway is simpler. The ground is moving below us faster than anyone expected a year ago. The designers who come out of this well are the ones treating these tools as collaborators for exploration, not threats to their craft.

The craft is still the craft. The tools are just getting a lot more interesting.

---

# [Think first, prompt later](https://konigi.com/articles/think-first-prompt-later)

> Generative coding with AI makes building easy. Building the right thing still takes design thinking. Here's why that matters more, not less, in the age of AI.

Conventional wisdom says AI is going to eat our jobs. Design is among the fields where there is a sense of worry about this and a lot of senior designers, including myself, are quietly pivoting or considering a switch. I think we may have it backwards.

## The bottleneck moves

Generative coding with AI makes building easy. Building the right thing still takes critical design thinking. That matters more, not less, in the age of AI.

When building gets cheap, execution stops being the bottleneck. The question stops being "can we build this?" and starts being "should we build this?" That question was always the harder one.

AI doesn't answer that question. It just makes the cost of answering it wrong go up. With AI-enabled design tools making it easier to build products, often regurgitating what has already been built, you have to wonder if we're headed in the right direction.

A year ago, building out a full product meant weeks of engineering time. The friction was high enough that you had to think before you built. You couldn't afford not to. Today, with Claude Code, you can go from idea to working prototype in a weekend. That sounds like a superpower, and it is, but only if you know what you're building and why before you start. The speed of the tool doesn't change the quality of the thinking behind it. It just makes the gap between good thinking and bad thinking more visible, faster.

## The app I built too fast

Let's take one of my small failures as a cautionary tale. Last year I had an idea for a DJ profile app. I called it HeyDJ! The concept was straightforward: mobile DJs could have a profile page, list their upcoming events, and each event page could take song requests from guests.

So I built it. I used Bolt.new at first and it came together quickly. Profile pages, event pages, a song request flow. It looked good. It worked.

Then I did the research I should have done first. The emperor was apparently buck naked.

Services like this already existed. Not one or two, but several, and some of them were well-established. After a few months, I started feeling like I had overdesigned a tool that I wasn't actually using enough to maintain.

More surprising was what I found when I actually talked to DJs. Many of them didn't want to use a service for this at all. They had their own much simpler systems. Some had been doing this for years and had it handled.

The problem I thought I was solving wasn't the problem they were sitting with. I hadn't built the wrong thing technically. I'd built the wrong thing strategically. I'd built it at speed, which meant I'd invested more time and energy into the wrong direction than I would have if I'd stopped to think before I started. The AI will happily build the wrong thing at three times the speed it used to take.

## What the tax on exploration actually means

Before AI tools, the expensive part of product design was execution. Exploration was cheap: sketching is free, talking to a handful of users costs a few days, even wireframing is low-cost. The expensive part was handing something to an engineer and watching weeks evaporate.

Now execution is cheap. An afternoon with Claude Code and you have a working prototype or an MVP. This means real exploration is now the expensive part. Not in dollars, but in the discipline required to resist the pull of just starting to build.

My take is that the value of design thinking moved into the thinking that happens before you open a terminal or prompt screen.

## What thinking first actually looks like

"Think before you build" sounds obvious until you try to do it under pressure with a good idea and a low-friction tool sitting right in front of you.

It means asking who this is for. Not "mobile DJs" but which DJ, at which stage of their career, with which kind of gig. What is the job they're trying to get done? What does their current workflow look like, and where does it break down? What would they have to believe for your solution to be worth switching to?

It means writing down a problem statement before writing a prompt, and articulating a hypothesis: "I believe that [user] needs [thing] because [reason], and I'll know I'm right if [signal]." It means sketching the critical user journey not as a deliverable, but as a thinking tool, so you understand what has to be true before someone ever touches your product, and what has to happen after.

None of this is new. Everything written about early-stage ideation in Wireframing for Everyone still applies here, probably more than it ever did. The discipline of sitting with the problem before you solve it, the humility to sketch a bunch of ideas before committing to one, and the willingness to let go of your first draft — those aren't quaint artifacts of a pre-AI era. They're the skills that separate people who ship the right thing from people who just ship fast.

## Why I built Klarita

After the HeyDJ experience, I kept thinking about how to make the thinking-first part easier. Not softer, not a shortcut, but more structured. The reason most people skip it isn't because they're lazy. Maybe there isn't always time for it, no reliable container for it in the process, no format that makes it feel like progress rather than procrastination.

So I built Klarita (klarita.app) to be my design assistant — to walk me through discovery questions, user definition, jobs to be done, a problem statement, a hypothesis, user journey, and light wireframing before touching a prototype tool. At the end of those steps I have a design brief I can share as a spec with a team or stakeholder.

The design brief isn't a bureaucratic artifact. The important thing is to do the activities that give you the signal that you're building the right thing. So call it whatever you want, just don't skip the step.

If you're building products in an AI tool, you're doing your stakeholder and user a disservice if you're not doing this work. A well-considered, intentional plan can lead to a successful execution of your idea. And that's where the brief comes in — it can make your first prompt specific instead of vague, and your second iteration informed instead of guesswork.

## Something to ponder

The designers who thrive in an AI-assisted world aren't going to be the ones who prompt fastest. They're going to be the ones who know what their stakeholders, their users (or themselves, if they're building for themselves) want before they prompt at all. Those who can articulate the problem clearly enough that the AI becomes a real collaborator rather than a fast way to go sideways. You're the design director and Claude is your design/development implementer.

I don't know if AI is a threat to designers when you look at it this way. I see it as an argument for their value.

---