Hello my friend!

Recently I’ve been working on CUBE, a small web app that turns text into 3D isometric typography. You type something, choose a style and colour, and export an image or animation.

I started it as a side project, partly to explore an idea I’d had for a while, and partly to see what it feels like to design and build alongside AI.

As a product designer, I’ve spent years working with developers to bring ideas to life. With Claude Code, I can now do much of that work myself.

It’s exciting. But it also raises a question: when AI can handle much of the implementation, where should I spend my time as a designer?

Looking through my CUBE notebook, I found a few decisions that mattered much more than the code.

It started with a Pinterest board

Like many of my projects, CUBE started with collecting references. I made a Pinterest board of isometric typography, geometric shapes, and interfaces I liked.

For the interface, I kept coming back to Braun’s industrial design: simple controls, clean typography, and Dieter Rams’ principle, less but better.

I also loved some vintage styles. But when I put them next to CUBE’s modern, geometric output, something didn’t feel right. It was like mixing two different products.

So I dropped that direction.

That’s one thing I’ve always enjoyed about design. You can explore dozens of directions, but eventually you have to decide what belongs together.

AI makes it easy to generate five variations of an interface in almost no time. That’s wonderful for exploring ideas. It’s also tempting to keep adding things simply because you can.

I found myself needing to be more deliberate about what to leave out.

Four ideas on one page

One notebook page had four different product ideas: CUBE, Big Type for displaying very large text, Quote Type for making quote images, and Bubble Type.

I briefly considered putting them all into one typography tool. More features, more possibilities. It sounded appealing.

But I wanted something simpler: type a few characters and immediately see something interesting.

Even that interaction involved a decision. My first sketches used a grid-based text input. It looked distinctive, but would people understand it?

Everyone knows how to type into a text field. Why make that part complicated?

I switched back to a regular input with a character limit. The interesting experience should come from what happens to the text, rather than how you enter it.

I wrote down the core workflow:

Type something. Change the style. Export the result.

That became my reference whenever I wanted to add another feature. The other ideas are still in my notebook. I may explore them again someday.

The details I cared about

Once the basic functionality worked, I explored the smaller interactions: transitions between views, hover states, and the animation when switching between light and dark mode.

Some started as rough drawings. I’d photograph a notebook page, share it with Claude Code, explain what I wanted, and test the result.

The first version was rarely perfect. Sometimes an animation felt too fast or the movement was awkward. I’d adjust it, try again, and occasionally go back to the drawing board.

I really enjoyed this process.

In previous design jobs, I’d build prototypes in Figma, explain interactions to developers, and discuss what was worth implementing. Some details wouldn’t survive that process. Now I can experiment with them directly.

It reminded me of Jussi Pasanen’s illustration of a Minimum Viable Product: build a small slice that considers functionality, usability and emotional design together.

Brian de Haaff also made a memorable case for the Minimum Lovable Product. His analogy: you can survive on cat food, but you probably won’t love eating it.

I made a video about MVP and MLP, using CUBE as the example:

I think AI makes this approach more practical. CUBE doesn’t solve an urgent problem. People can live perfectly happy lives without a 3D typography generator. So the experience itself matters.

That doesn’t mean every product needs fancy animations. Sometimes removing an unnecessary interaction is just as useful as adding a nice one.

Three words, but do they mean anything?

Early on, I wrote down three things I wanted CUBE to be:

Effortless. Shareable. Playful.

I know. These sound like words you’d see in hundreds of design presentations.

So I tried to make them useful.

For effortless, I could look at whether visitors started typing. For shareable, I could check whether they exported something and whether their sharing links brought anyone back.

Playful was harder. I could measure how many styles someone tried, but that wouldn’t explain why. Maybe they were having fun. Maybe they couldn’t find anything they liked.

That’s where watching someone use the product, listening to feedback, and making design judgments still matter.

Data can tell me how many people exported a file. It can’t tell me whether they loved the result or were disappointed after downloading it.

What changes for designers?

Working on CUBE has made me optimistic about designing with AI. I can go from sketches to a working product, test details directly, and change things without a long handover.

But AI is also very willing to build whatever I ask. If I request another feature or a more elaborate interface, it will happily make one.

I still have to decide whether it belongs in the product.

And after launch, I discovered another set of questions: who actually uses it, what they make, and how they find it. That’s been a different experiment, which I’ll share in the next issue.

I also recorded a video walkthrough of my CUBE notebook, including the sketches and the development process:

Try this on your own product

Write down the three words you want your product to be. Next to each one, note what you could actually measure, and what you would only learn by watching someone use it.

Then look at the last feature you added. Did it make the core workflow better, or did you add it because it was easy to build?

Also from me

A few other things I have written, outside the main story.

English is how I work. Chinese is how I think fastest.

For a few years, I had a strict rule for myself: read everything in English.

I live and work in New Zealand, so it felt sensible. It also felt disciplined. If a Chinese translation was available, I would still choose the English version.

Recently I have started using translation tools more often, especially when I am trying to understand a difficult subject quickly. My first reaction was embarrassment. I wondered if my English was going backwards.

Then I looked at how I actually spend my days. I speak English with clients. I write in English. I read it constantly. I am not short of English practice.

The point of reading was never to prove that I could read English. It was to understand something.

English is the language I work in. Chinese is still the language I think fastest in. I need both, and I am finally comfortable using both.

A book I read fifteen years late

I finished this book fifteen years after it came out. Which, given that I’ve been doing design work for most of those fifteen years, is a slightly embarrassing thing to admit.

“100 Things Every Designer Should Know About People” is not a hard read. It’s just 100 psychology principles, explained plainly. No theory rabbit holes, no academic posturing.

But here’s what surprised me: reading it now, after years of shipping real products, landed completely differently than I think it would have earlier. Every principle clicked against something I’d actually built, or misjudged, or fixed by accident.

The framework was always there. I just didn’t have it.

If you work in product and haven’t read it, it’s worth a weekend. Especially if you think you already know most of it.

My daughter’s risk assessment

My daughter told me not to go for a walk last night.

“It’s too dark. It’s dangerous. You’re important to us, Dad.”

I was touched for about two seconds.

Then she added: “We still have a lot of mortgage left.”

Well...

Love, apparently, comes with a repayment plan.

Where to next

The full CUBE story is on my site, including what happened after launch: bearliu.com/blog/building-cube-with-ai

If you’re also designing with AI, I’m curious: are you spending more time on design decisions, or simply building more things?

Hit reply and let me know.

Thanks for reading!

Bear

Hello, I’m Bear.

I’m a product designer in Auckland, New Zealand. Most of my work is as a Fractional Design Partner, which usually means being the design lead a small team cannot yet hire full time.

Design Decisions is where I take one product apart each week and write up the decisions behind it. I make videos and record a bilingual podcast for much the same reason. I like working things out in the open.

• bearliu.com · the full teardown library, and what I do for teams

• hi@bearliu.com · the old fashioned way, and I read every reply

• linkedin.com/in/bearliu · where most of my English writing goes first

• youtube.com/@Bearliu · a video is worth a thousand words

• x.com/bearliu · shorter thoughts, as they happen

This year I rebuilt my portfolio three times, after moving from in-house product designer to design partner. Version one got the message across but felt messy. The site and the portfolio were built with different tools (Claude Code and Claude Design), and side by side they didn’t feel like the same person.

Version two was cleaner: a short intro video, a clearer hero, case studies and testimonials. Then Eric Sin, a Staff Product Designer at Netflix, reviewed it. His point: it was good for knowing who I am, but not for helping a founder judge whether to start a conversation. The offer needed to be bigger than my name, and “startups and enterprise at every stage” describes every company on the planet. You can watch Eric’s full roast of my portfolio here:

That review moved me from a portfolio mindset to a trust conversion mindset. Before the first call, a founder wants to know why you, whether you can do it, and what happens next. Version three puts the offer first, redraws the client logos so they can actually be read, and cuts each case study down to the problem, the outcome and what I delivered.

As Eric put it: this is the same thing you would do for a startup. You just have to do it for yourself.

Chapters
0:00 “I like your website, by the way”
0:56 What does your portfolio website do?
1:09 Version 1: from job seeker to design partner
2:49 Same site, two design languages
3:44 Version 2: a cleaner message and hero
5:03 Eric Sin’s portfolio review
5:43 Message hierarchy and a sharper offer
6:51 From portfolio mindset to trust conversion mindset
8:13 Turning interest into a conversation
9:03 Version 3: the new homepage
10:13 Redraw the logos so people can read them
10:50 Case studies people can scan
12:22 Testimonials and a positive signal
13:24 Treat yourself like a product
14:21 So, what does your portfolio do?

Show Notes

• My portfolio website: https://bearliu.com

A while ago I started applying for a US visitor visa, for a possible family trip. We have since postponed it. Partly that was the flights, which got ridiculous once fuel prices went up.

The other part was the application itself. I picked the wrong location when I submitted it, and the system would not let me go any further. It would not let me start again with a new account either. It was frustrating enough that I simply walked away.

Maybe I will go back once flights are back to normal. That probably depends on whether my wife chases me about it.

The mistake itself was small. What made me leave was a system that offered no way forward and no explanation.

Last week was about where Wise’s website and app diverge. This issue is about the screens nobody puts in a launch deck: the ones where the product cannot give you a full answer.

Price is explained. Time is not.

Wise is very good at telling you what a transfer costs. It is much quieter about when the money turns up.

I ran two US dollar transfers on the same afternoon. One was estimated to arrive in about 30 minutes. The other would not land until the following day. Same product, same afternoon, and no explanation for why one route was so much faster.

That gap matters because anyone making a transfer is buying two things. One is price. The other is certainty.

Sending $50 to a friend, a few extra hours cost you nothing. Paying rent, settling an invoice, paying a supplier before a deadline, and knowing when it lands is worth more than saving a few dollars. Wise has made the first thing completely transparent. The second is still mostly a black box.

What do you do when you are not allowed to explain?

This gets much sharper when an account is frozen.

Wise has an extremely high rating on Google Play. The negative reviews cluster around one experience: an account is suddenly restricted, the customer does not understand why, support replies read as generic, and there is no obvious next step.

There is an important complication. When financial institutions suspect fraud or money laundering, they may be legally prevented from warning the customer in advance, and in some situations, once certain reports have been filed, from explaining what triggered the review at all. So some of that silence is not a product decision. It is regulation.

Which leaves a more interesting question. If your product promises to explain clearly what is happening, what do you do when the law stops you explaining?

Wise still has room here. There is little public detail on what an account review looks like, what a customer can realistically do, how long the stages take, or what comes next. There is also nothing separating two very different situations: we are legally unable to tell you, and we have not got to your case yet.

From the customer’s side, both look the same. Silence. And people handed an information vacuum will fill it themselves, rarely with the optimistic version.

Think about a delayed flight. Everyone would rather leave on time. Once that is gone, knowing why, how long, and what happens next beats staring at a red DELAYED label that never changes. Transparency does not require you to reveal everything. The hard part is explaining what happens next when you cannot.

Freezing a card takes seconds, and that changes what it is for

Card management is where the two platforms part company again.

On the website you get a list of cards, each with its last four digits and status. You pick one, open it, then act. Slightly old fashioned, and completely clear.

The app is more compact. A carousel sits at the top and the actions sit underneath: Show PIN, Card details, Freeze card. Swipe to another card and those actions now apply to the new one, without the interface making that relationship obvious. With one card it does not matter. With several it does, and one of those buttons switches off your ability to pay.

So I tried it. The card went grey and the button became Unfreeze. Tapped again, and the card was live. The whole thing took a few seconds.

Most of us arrive at a button like that carrying assumptions from traditional banking. Will I have to call support? Verify my identity again? Wait hours to get it back? Wise made the answer to all of that no.

That produces something the feature was probably not designed for. When reversing an action costs nothing, people stop treating it as an emergency. Some customers keep the card frozen most of the time, unfreeze it to pay, then freeze it again.

And if somebody is doing that two hundred times a year, making the button easy is no longer the interesting opportunity. Automation is. Freeze above a certain amount, freeze outside a region, or let people write their own conditions.

Designers argued about the green. Customers argued about their money.

One more piece worth sitting with. In 2023 Wise moved off the familiar fintech blue and adopted a very bright green, a new typeface and a much more expressive visual language. The product did not work differently. The price did not change.

In a Hacker News thread about the redesign, a surprising number of designers reached for a word that does not usually come up about colour palettes. Trust. A company handling people’s money should not look this playful.

The business data makes that hard to defend. Wise now has around 19 million active customers. The share of personal customers using more than one Wise product rose from roughly 44 per cent around the rebrand to close to 50 per cent. The app rating sits around 4.8. And when customers do complain, they complain about frozen accounts, support, and when the money will arrive. Almost nobody leaves a one star review because the app is green.

Different audiences read different signals. Designers read typography and visual language, because that is what we look at all day. Most customers read price, speed, and whatever has previously gone wrong for them. That is the whole argument in one line: trust is not decided on the screens we like showing each other.

Two notes that sharpened this

Withholding only works when you have already promised the thing. I have been playing Control, which stretches progressive disclosure across ten or more hours. New abilities arrive deep into the game and the map you thought you understood opens up again.

It lands because the withholding is architectural rather than arbitrary. The places you cannot reach are visible from the start, so you register the gap before it gets filled. Hide something that was never hinted at and the reveal just feels like you forgot to build it sooner. A frozen account is the same shape. Silence is survivable if the customer has already been shown what the process looks like.

When the cost of an action collapses, people do it far more, and something else starts compounding. Pilots do not log simulator hours because each flight produces anything useful. They log them because the reflex only builds through repetition.

I think about that with AI tooling, where the founders who feel behind are not short on knowledge, they are short on hours. It is the same mechanism as the freeze button. Drop the price of one action low enough and you do not get slightly more of it. You get a different behaviour, and usually a product opportunity nobody scoped.

Try this on your own product

Take your worst case. Account locked, payment declined, order stuck somewhere. Write down what you are genuinely not allowed to say, and separate it from what you simply have not got round to saying.

Customers cannot tell those two apart. Given the choice, they will assume the worse one.

Then pick the heaviest, most alarming action in your product and time how long it takes to undo. If undoing is cheap, watch whether people start using it as a routine instead of an emergency. That is usually where the next feature is hiding.

Also from me

A few other things I have written, outside the teardown.

Slow on purpose is different from slow by default

I picked up a sketchbook five years ago and have filled maybe 400 pages since.

I felt pretty good about that until I came across an artist who filled 500 pages in nine months. Six sketchbooks. Same period I was slowly working through one.

The gap is not really about talent. It is about frequency. He drew every day, roughly, and that repetition made him genuinely expressive in a way I am not yet.

What I did not expect is that realising this felt freeing, not deflating. Because the bottleneck is simple. Not skill, not tools, not the right notebook arriving in the post. Just showing up more often.

Slow is fine. Slow on purpose is different from slow by default.

They redesigned the reporting surface, not the headcount

New Zealand’s coastline is thousands of kilometres long. There aren’t enough staff to monitor all of it. So someone made a simple call: put QR codes at key erosion-prone points along the shore.

When a local notices a crack, a slump, or something that looks off, they scan the code, snap a photo, and submit it. The agency gets a timestamped, geotagged report without deploying a single additional staff member.

It’s a textbook crowdsourcing pattern, but what makes it work isn’t the technology. It’s the zero-friction submission path. No app to download. No account to create. No form to hunt for. The action cost is low enough that a curious person on a morning walk will actually do it.

This is the same design problem that shows up constantly in early-stage products. Teams build powerful features, then bury the contribution or feedback path three clicks deep. The result: silence. Not because users don’t care, but because the moment of friction arrived before the moment of motivation passed.

If you’re building anything that depends on user-generated input, whether that’s onboarding feedback, bug reports, feature requests, or community contributions, map the distance between when someone notices something and when they can act on it. That gap is where participation dies.

The coastline team didn’t hire more rangers. They redesigned the reporting surface. That’s the move.

Not every product needs to solve a problem

I had an idea for a small side project last week. Before writing a single line of code, I ran it through a Socratic dialogue with Claude, asking it to pressure-test the concept. Within a few rounds of questioning, it had dismantled nearly every assumption I had about the business model, the target user, and the core problem being solved.

And then I realised: I didn’t actually want to build a product. I just wanted to make something. The same way a kid folds paper into a crane, not because cranes are useful, but because the folding itself is satisfying.

That’s a legitimate reason to build.

We’ve absorbed so much startup orthodoxy that we’ve started treating “does this scale?” as a moral question. Every side project needs a TAM. Every prototype needs a waitlist. Every experiment needs a north star metric. But the first person to draw on a cave wall wasn’t thinking about distribution. They were just compelled to make a mark. And that’s exactly where human creativity separated from everything else.

The Socratic questioning was still worth doing. It cleared the fog and helped me see what I actually wanted, rather than what I thought I was supposed to want. That’s a useful diagnostic move whether you’re building a $5 product or raising a seed round: ask why until you hit something true.

For me, the true thing was small and personal. And that’s fine.

Where to next

The full Wise teardown is on the site, including why the consistency between web and mobile is the cheapest part of the whole thing: bearliu.com/blog/wise-consistency-is-the-cheap-part

What is the screen your product hopes nobody ever sees? Hit reply and tell me. I read everything that comes back.

Hello, I’m Bear.

I’m a product designer in Auckland, New Zealand. Most of my work is as a Fractional Design Partner, which usually means being the design lead a small team cannot yet hire full time.

Design Decisions is where I take one product apart each week and write up the decisions behind it. I make videos and record a bilingual podcast for much the same reason. I like working things out in the open.

• bearliu.com · the full teardown library, and what I do for teams

• hi@bearliu.com · the old fashioned way, and I read every reply

• linkedin.com/in/bearliu · where most of my English writing goes first

• youtube.com/@Bearliu · a video is worth a thousand words

• x.com/bearliu · shorter thoughts, as they happen

I love my Traveler’s Notebook. My first one was not even from the original brand, and it was still a good notebook: a decent cover, and easy to carry everywhere.

I have written a lot in it. Over two years I have logged around 500 journal entries and gone through more than a dozen inserts.

Somewhere along the way I started noticing the paper, the pens and the inks. Small details matter when you write by hand. The weight of a pen changes how comfortable you are, how long you keep going and how carefully you write. Fascinating, isn’t it?

None of that shows at a glance. It only shows after a few hundred pages.

Wise’s website and app look almost identical too. The interesting part is the handful of places where they do not.

Matching screens are what the system outputs

At a lot of companies the website, the iOS app and the Android app belong to different teams. Give it a year and the same feature has quietly become three features. A button moves on one platform and stays put on another. The web gets a new flow while mobile is still running the version from six months ago. Then somebody schedules a meeting to bring it all back into line.

Wise did not solve that with discipline. It solved it with plumbing. Much of the interface comes out of a shared component library, and some screens have their structure defined on the server.

Think about a chain of coffee shops. If every store designs its own menu, picks its own cup sizes and invents its own way of taking orders, keeping them consistent becomes somebody’s full time job. If the menu, the cups and the till are designed centrally, the stores feel the same without anyone managing it.

Wise is the second kind. So when I see two near identical screens now, I read them as output rather than achievement. Matching is what that system produces when nobody intervenes.

The differences are where somebody made a decision

There are not many of them. They are worth more than the hundred screens that agree.

Some are easy to account for. A phone has a camera, so QR based payments such as Alipay make sense there and are absent from the web. Businesses can upload a CSV and pay hundreds of recipients at once, and that lives only on the website. Someone paying several hundred suppliers is sitting at a desk. Rebuilding that for a phone to keep the platforms level would buy very little.

Then there is Insights, the spending analysis feature. The website gives it a more prominent position. The app buries it deeper, then hands you finer control, including the ability to drop a single transaction out of it. The platform that promotes the feature harder gives you less say over it.

That reads like a house renovated a few times. Every room works. You can still feel that the decisions were made in different years by people who were not talking to each other.

The one that stayed with me is smaller. On the same phone, signing in through a browser and signing in through the app can be treated by Wise’s security system as two separate devices. You see one phone. The system sees two doors.

Two interfaces can look identical while the systems underneath them make different calls about risk.

The best decision Wise made sits before the signup

Open the Wise homepage and there is no hero image and no wall of company statistics. There is a calculator that works.

Put in NZ$1,000, convert to Australian dollars, and you get the rate, the fee, the amount landing in the other account and when it is expected to arrive. Open the fee and it splits into what Wise takes and what the payment method takes. There is a comparison table underneath. On the transfer I ran, Wise showed the recipient getting around A$830, against roughly A$813 at Westpac and about A$788 at PayPal.

Wise never has to write a headline claiming it is cheaper. The numbers have done that.

Then comes the part I keep returning to. Press Send money and you do not get another marketing page. You get the registration form. The calculator is not a tool sitting beside the signup. It is the first screen of it.

So the trade-off is not consistency against inconsistency. Consistency makes a product easier to use, and Wise buys it cheaply because it paid for the infrastructure years ago. What actually earns the account is a prospect verifying the main claim themselves, before being asked for anything.

Most products state the claim first and leave you to check it later. Wise runs that order backwards.

Two notes that sharpened this

The real source of a product is not the thing you are looking at. A colleague reframed this for me in a meeting a while back. The source of truth for a software project is no longer the codebase. That is compiled output. The real source is the intent document, the problem framing, the scope somebody defined.

Matching screens are compiled output too. If you want to know why two platforms agree, do not read the screens. Read whatever generates them.

A hundred small decisions make or break an interface, not one brilliant idea. The Vercel design team published a set of web interface guidelines that reads like a quiet checklist of things most teams skip. Tap targets. Input font sizes. Alignment systems.

One of them: mobile input fields need to be 16px or larger, because iOS Safari will otherwise zoom and pan the viewport. That is not taste. It is a constraint with a consequence attached. The decisions worth finding are usually that small, and there are usually a hundred of them.

Try this on your own product

Open your web and mobile versions side by side and list every place they diverge. For each one, name the decision and the person who made it.

The ones you can name are design. The ones nobody can account for are drift, and drift is cheaper to fix now than after somebody builds on top of it.

Then find the moment a prospective customer could verify your main claim without your help. If that moment sits behind a signup, see how far forward it can move.

Also from me

A few other things I have written, outside the teardown.

Two people, two years, one hour of game

Two people. Two years. No dialogue, no text, no tutorial. Just hand-drawn art and sound design.

I finished Pilgrims this week, a short puzzle game by Amanita Design (the studio behind Machinarium and Botanicula). It took just over an hour to complete. The studio spent two years making it.

That ratio stopped me.

Amanita has always built games that cross language and culture entirely through visuals. No localisation needed. No copy deck. The craft carries everything. Pilgrims does the same, reimagining classic fairy tale archetypes (the traveller, the farmer, the devil, the king) through illustration alone.

Here is the thing that stuck with me as a product person: the game is short by design, not by accident. The constraint is the point. They chose depth over length, and the result is something with a clear aesthetic identity that a large studio would likely have bloated into a 20-hour open world.

Which raises an uncomfortable question for anyone building products right now: how much of what we ship is longer, heavier, or more complex than it needs to be, simply because we had the resources to make it that way?

The AI angle is real too. A small team with genuine creative direction and aesthetic taste could produce something like Pilgrims today at a fraction of the production cost. Not because AI replaces craft, but because it removes the bottlenecks that used to require headcount. The constraint shifts from resources to judgement.

That is the harder thing to develop.

If you are building a product with a small team right now, the question probably is not “how do we do more?” It is “what would we cut if we only had time to get one thing exactly right?”

It was Bluetooth

Arrived at the gym this morning to find my phone couldn’t open the door. Tried everything. Restarted the app, checked my membership, nearly convinced myself the system had dropped me.

Got home and noticed my fitness tracker had stopped syncing with Google Health too. Two separate failures, both happening at once. Something must be seriously wrong.

It was Bluetooth. I’d turned it off the night before and forgotten.

I build digital products for a living. I think about user flows and error states for fun. And I stood in a car park for five minutes troubleshooting two apps that were working perfectly fine.

The lesson I keep relearning: when something breaks, check the simplest thing first. Not because you’re not smart enough to find the complex problem. Because the simple one is usually it.

The $40 clip, and the wrong question

I used to ask the wrong question when buying something expensive.

Last week I nearly talked myself out of a $40 notebook clip. Forty dollars. For a clip. My internal monologue went straight to: how can this possibly be worth that?

But that is not really the question, is it.

The actual question is: am I worth using something this good?

I answered yes, bought the clip, felt zero guilt about it.

It is a small reframe but it changes where the scrutiny lands. Instead of defending the object, you are deciding something about yourself. And once you have made that call, the $40 stops feeling like a leak and starts feeling like a standard.

Anyway. The clip is excellent.

Where to next

The full Wise teardown is on the site, including what happens to a brand built on transparency when an account gets frozen: bearliu.com/blog/wise-consistency-is-the-cheap-part

Where do your two platforms disagree, and can anyone say why? Hit reply and tell me. I read everything that comes back.

Hello, I’m Bear.

I’m a product designer in Auckland, New Zealand. Most of my work is as a Fractional Design Partner, which usually means being the design lead a small team cannot yet hire full time.

Design Decisions is where I take one product apart each week and write up the decisions behind it. I make videos and record a bilingual podcast for much the same reason. I like working things out in the open.

• bearliu.com · the full teardown library, and what I do for teams

• hi@bearliu.com · the old fashioned way, and I read every reply

• linkedin.com/in/bearliu · where most of my English writing goes first

• youtube.com/@Bearliu · a video is worth a thousand words

• x.com/bearliu · shorter thoughts, as they happen

Raycast runs on one grammar. You key in a few letters, hit Enter for the main action, or Command K for everything else. Every one of its 2,500+ extensions works with the same two keys, so once your hands know it, you stay.

My legs and knees are not what they used to be. Mostly that is age. Leg days at the gym help, but I wanted something that took less effort.

So now I do a minute of squats while I brush my teeth, morning and evening. Easy as. Brushing my teeth is already a habit, and adding a step to an existing habit is far easier than building a new one. The point is to wire the two together until they feel like one thing.

Linear teaches its keyboard shortcuts in much the same way: inside work you were already doing, never in a tutorial.

The cheapest training system in software

Almost every common action in Linear has a keyboard shortcut. Change an issue’s status, adjust priority, expand a list, create a task, switch workspace, all without reaching for the mouse.

The decision worth noticing is where those shortcuts live. Hover over an action and the shortcut appears inside the tooltip you were already reading.

No onboarding tour. No ten-minute video. A few characters added to something that was going to be on your screen anyway.

Plenty of products have the same shortcuts. Most of them keep the list in a help page, or behind a question mark, or in a modal you can summon once you already know it exists. That version only ever reaches people who go looking for it. Linear’s version reaches everyone, because it arrives attached to work they were already doing.

The first time, you click the button. The second time, you notice the shortcut and try it. A few weeks in, a good number of repeated actions have stopped requiring any thought at all. Your fingers go without asking.

Cognitive cost can be relearned. Physical cost is slower.

In most software the learning cost stays in your head. You remember where a feature lives, which page holds a setting, which menu creates a project. Switch to a competitor and you spend a few uncomfortable days learning a new layout, then you are fine.

Linear moves part of that cost somewhere else.

It is closer to driving. You do not work out how far to turn the wheel on the way into a corner, or decide where your foot goes before you brake. Those are physical habits now, which is exactly why a car with a different control layout feels wrong even when it is technically simple to operate.

After a few months in Linear, leaving means giving up a whole set of hand movements. The switching cost is no longer just migrating data and comparing feature lists. Part of it is retraining your body.

The same feature would do much less somewhere else

None of this works in isolation. It works because of who Linear had already chosen.

Engineers spend their days inside terminals, code editors and keyboard-first tools. Linear is not teaching them a new way of working. It is extending one they already have.

Asana or Notion could ship the same number of shortcuts tomorrow. Their audiences are broader and plenty of those people still prefer to click or tap. Same feature, far less value.

So the trade-off is not really about shortcuts. A feature rarely becomes an advantage on its own. It becomes one when it connects to a habit a specific group of people already has, which means the audience decision has to come first and the feature second.

A moat holds you in place too

There is a bill attached to this, and it arrives later.

Once a shortcut is in somebody’s fingers, you cannot move it. A menu can be reorganised between releases and most people adapt inside a day, grumbling a little. Change what a key does after two years and you have broken something people were not consciously using, which makes it the hardest kind of complaint to answer. They cannot tell you what is wrong. They can only tell you it feels wrong.

The same mechanism that raises the cost of leaving raises the cost of changing your mind. Every action you train into somebody’s hands is one you have quietly promised to keep. That is a fine promise to make, as long as you know you are making it.

Two notes that sharpened this

Users do not hate learning. They hate learning things that have nothing to do with their work. Bonnie Nardi studied why spreadsheets succeeded where programming languages did not. Her answer was that spreadsheets mapped onto concepts people already held. A baseball fan does not struggle to calculate a batting average. It is his world, and the formula only makes it faster.

So the question to ask early is whether you are building something new, or asking somebody to learn a new vocabulary before they can do the thing they came here to do. One of those is a product. The other is homework.

A tool sticks when you need it for something real. I had skimmed past Claude’s Skills feature in some article and none of it landed, because I had no reason to care yet. Then I wanted to automate a set of repeated prompts on a client project, and it went from background noise to something I actively wanted to understand.

Structured learning has its place. The messy version, where you hit a wall and work it out mid-flight, is the one that tends to stay. Linear’s tooltips are that second kind, handed to you during the work rather than before it.

Try this on your own product

Take the five actions your customers perform most often and watch somebody fluent do them. Not a new user. Someone six months in.

Then ask the question that actually decides retention: could that fluency be carried into a competitor’s product, or does it only make sense inside yours?

Speed that transfers is a feature, and a good one. Speed that does not transfer is a moat. Most teams build the first and describe it as the second.

Also from me

A few other things I have written, outside the teardown.

Save the Cat is a user research method

A screenwriting book taught me more about user testing than most UX frameworks I’ve read.

I picked up “Save the Cat” this week, a classic screenwriting guide. The title refers to a simple technique: if your protagonist is morally grey, give them one small moment of kindness early on. The audience forgives a lot after that. One gesture does the work of pages of backstory.

The author also suggests a brutally honest feedback method. Take your story pitch to a café, find a stranger, and ask if they’d mind hearing a plot summary. If their eyes glaze over mid-sentence, the story isn’t working. No survey. No structured debrief. Just a real human in real time.

That’s a product research method, not just a screenwriting trick. How often do we sit in a room with a stakeholder deck instead of describing our product to someone who has never heard of it? If you can’t hold their attention in 60 seconds, no amount of polish fixes the underlying problem.

The book also maps out ten core story archetypes. The Hero’s Journey is just one of them, what the author calls the Golden Fleece. The others include Buddy Love, Institutionalised, and Monster in the House. His point is striking: every archetype works because a Stone Age human would understand it. The emotional logic is that old.

For product design, this translates directly. If your value proposition requires cultural context, industry jargon, or three onboarding screens to land, you’ve probably drifted from something instinctively felt to something that has to be explained. The best products, like the best films, set up an expectation and then deliver on it. The user already knows what they signed up for.

Rest that matches the work

I used to think rest meant switching tasks.

Deep in a design problem, I’d hit a wall and reach for Twitter. Five minutes, I’d tell myself. Just a reset. Then I’d come back and wonder why the thinking felt scrambled, why I had to rebuild the thread of what I was doing before I could move forward at all.

The break wasn’t the problem. The content of the break was.

Your brain doesn’t clear its working memory the way a computer flushes a process. When you swap deep thinking for a feed of unrelated, low-quality information, you’re not resting the system. You’re loading something else into it.

Rest that matches the intensity of the work: a walk, silence, staring out a window. Not another stream of content competing for the same channel.

Design is space and time

Had coffee with a friend who studied industrial design at one of China’s top art schools.

He told me something his professor said on the first day: design is about space and time. Not aesthetics, not problem-solving in the abstract. A specific problem, in a specific place, at a specific moment.

The example stuck with me: the lecture hall chairs were angled slightly forward. Uncomfortable enough that you had to engage your core to sit upright. Students stayed alert. They paid attention. Put those same chairs in a living room and they’d be awful. Same object, wrong context, completely broken.

We do this in product all the time. We chase solutions before we’ve fixed the coordinates. What kind of user? What moment in their day? What are they actually trying to do right now?

The constraints are not the obstacle. They are the brief.

Where to next

The full Linear teardown is on the site, including the $35,000 of marketing that sat underneath $100M of ARR: bearliu.com/blog/linear-the-restraint-tax

Which habit would a customer have to unlearn in order to leave you? Hit reply and tell me. I read everything that comes back.

Hello, I’m Bear.

I’m a product designer in Auckland, New Zealand. Most of my work is as a Fractional Design Partner, which usually means being the design lead a small team cannot yet hire full time.

Design Decisions is where I take one product apart each week and write up the decisions behind it. I make videos and record a bilingual podcast for much the same reason. I like working things out in the open.

• bearliu.com · the full teardown library, and what I do for teams

• hi@bearliu.com · the old fashioned way, and I read every reply

• linkedin.com/in/bearliu · where most of my English writing goes first

• youtube.com/@Bearliu · a video is worth a thousand words

• x.com/bearliu · shorter thoughts, as they happen

I recently ended an engagement with a client. Honestly, I am glad about it. It has opened up some buffer in my weeks, time I can now give to my health and my family. I am flexible, I am healthy, and the next stretch already feels more focused.

Clearing the space turned out to be the easy part. Deciding what gets it, when two things want the same hour, is harder.

Apple Health has the same gap. You choose which sources may write to it. You do not get to choose which one wins.

Apple gives you a guest list, not a referee

A single heart rate metric can be written by several things at once. An Apple Watch. Nike Run Club. A Withings device. Whatever other fitness apps you have granted access to.

You do have control here. You can disable a third-party source and stop it contributing anything new. That part works, and it is the part everybody notices.

The gap opens when two sources you both trust disagree.

Go for a run with the Watch on your wrist and a running app recording at the same time. Both write heart rate for the same stretch of the same afternoon. Neither is broken. Neither is a third party you would want to switch off. One number ends up in your trend.

You cannot mark one device as more reliable than another. Apple does not explain how the final figure gets chosen. Two valid readings go in, one number comes out, and the reasoning is not available to you anywhere in the interface.

You can decide who is allowed into the room. You cannot decide who gets the last word once they are in it.

The simplification is defensible, and it still costs something

I do not think this is an oversight. A switch plus automatic merging is far easier to understand than a source ranking system.

Ranking means explaining precedence. Then ties. Then time windows. Then what happens when the preferred source is missing for a day, or writes the same value twice, or produces a reading that is clearly wrong.

Every one of those needs a rule, and every rule needs a sentence somewhere in an interface that most people would open once and never return to.

So Apple chose the version almost everyone can understand. That is a real reduction in complexity, and it leaves a real gap in the trust story.

Apple has spent a decade buying trust the slow way, one clinical study and one regulatory clearance at a time. That is expensive to build and very hard to copy. It sits slightly oddly next to a number whose origin the product will not tell you.

Which is the reason this gap is worth more attention than the complaint everybody actually makes. Apple Health’s whole position rests on trust. A cluttered Browse tab costs you a few seconds of hunting. A number you cannot account for costs you the thing the product is really selling.

Provenance becomes part of the number

When the data was step counts, none of this mattered much. Nobody needs an audit trail for a Tuesday walk.

The stakes move as the numbers do. Show a reading to a doctor, put it beside a medication decision, use it to decide whether to train today, and where it came from stops being trivia. At that point people need to know which source produced it and why the system preferred that one.

This is not an Apple problem. Any product that aggregates from several sources has it.

A CRM holding contact details from an email integration and an enrichment service. A finance app reading the same transaction through two bank connections. Analytics stitching one person together across two SDKs. In every case somebody wrote a merge rule. In most cases the customer cannot see it, and often nobody internally can name it either.

The pattern is consistent. Teams ship inclusion controls early, because permissions are easy to reason about and easy to draw. Arbitration shows up much later, usually the first time two trusted sources disagree in front of a customer who cares.

Two notes that sharpened this

A tidy diagram is where the risk hides. I traced one number through a health platform a while back. My weight is measured by a Withings scale, stored by Apple Health, then read out by Google Health. Three hops. The platform that looks like it understands me best is displaying a figure it never measured.

The exercise worth running is to mark every source in your product as yours, borrowed, or imported. Then ask what still works if a borrowed one shuts off tomorrow.

An option that exists is not the same as a choice that is equal. I was adjusting a consent flow that touches GDPR, and the question looked small. Which button style for accept, and which for decline. The design system answer is primary for accept and secondary for decline. Consistent and tidy.

The regulatory requirement is not that a decline option exists. It is that the choice is genuinely equal. Weight one of them visually and you are nudging, with a component library as the excuse. It is the same shape as the source switch. The control is present, and one layer too shallow.

Try this on your own product

List every place your product merges data from more than one source. For each one, write down what happens when two of them disagree, and whether a customer could find that answer without asking you.

Then sort your controls into two piles: the ones that decide who is allowed to contribute, and the ones that decide who wins. Most products have plenty of the first and none of the second.

You may well conclude, as Apple seems to have, that the second pile is not worth building. That is a fine answer. It is a much better answer when somebody has actually made it.

Also from me

A few other things I have written, outside the teardown.

Marvel looks expensive and feels weightless

Marvel spent $200 million on a film and it still looked like plastic.

Denis Villeneuve spent less and made you feel the weight of a sandworm from the inside of your chest. The difference wasn’t budget. It was perspective.

Someone broke down Villeneuve’s technique recently and it stuck with me. Three things he does consistently: he keeps a human figure in frame so you feel the scale by comparison, he moves the camera slowly, the way a person’s eyes actually move, and he blurs the background so your attention lands where a human’s would. Everything is filtered through a human body, a human nervous system.

Marvel does the opposite. Cameras fly through impossible CGI arcs, backgrounds are rendered in perfect sharpness, nothing is anchored to a person’s experience of being there. It looks expensive and feels weightless.

A lot of early-stage products have the Marvel problem. The team builds something technically impressive, the demo looks clean, but users bounce in the first two minutes. When I run a product audit, I often find the same pattern: the interface is designed from a system perspective, not a human one. Every feature is visible. Every option is available. Nothing is filtered by what a person actually needs in that moment, in that state of mind.

Villeneuve’s fix translates directly. Show one thing at a time. Anchor the experience to where the user is standing, not where your architecture lives. Let some things blur into the background until they’re needed.

The best onboarding flows I’ve worked on do exactly this. They don’t show users the whole product. They show users themselves, reflected back, with one clear next step.

They sounded like Claude

I was chatting with someone from an AI product team that lives inside Claude all day. Sharp person, good thinker. But there was something odd about how they explained things: the analogies they reached for, the rhythm of how they built an argument. It took me a while to place it.

They sounded like Claude.

Not in a bad way. The thinking was solid. But the communication style had quietly drifted toward something optimised for a tool, not for the humans around them.

Tools shape us. That is not new. But AI tools are shaping how we reason out loud, and that is faster and subtler than most people notice.

Worth checking occasionally: if people keep missing your point, the gap might not be their comprehension. It might be that your defaults have drifted somewhere unfamiliar.

The flexibility is load-bearing

My wife went on a ten-day silent meditation retreat. So I had the week: school runs, cooking, housework, swimming, piano lessons, art class, all of it.

I expected to be wrecked by day 3.

I wasn’t. I felt surprisingly loose. We finished a co-op video game together, watched Harry Potter on the weekend, and I didn’t feel like I was constantly dropping something.

The thing I kept coming back to: flexible work hours meant I was never fighting the clock. I could shift things around without that low-grade panic of being somewhere you shouldn’t be, doing something you didn’t plan for.

I don’t think I could sustain it indefinitely. But this week quietly reminded me why I built my work the way I did. The flexibility isn’t a perk. It’s load-bearing.

Where to next

The full Apple Health teardown is on the site, including why an app nobody ever chose to download sits at a 3.0 rating, and why that is not a design failure: bearliu.com/blog/apple-health-infrastructure-by-design

Where does your product quietly pick a winner between two sources? Hit reply and tell me. I read everything that comes back.

Hello, I’m Bear.

I’m a product designer in Auckland, New Zealand. Most of my work is as a Fractional Design Partner, which usually means being the design lead a small team cannot yet hire full time.

Design Decisions is where I take one product apart each week and write up the decisions behind it. I make videos and record a bilingual podcast for much the same reason. I like working things out in the open.

• bearliu.com · the full teardown library, and what I do for teams

• hi@bearliu.com · the old fashioned way, and I read every reply

• linkedin.com/in/bearliu · where most of my English writing goes first

• youtube.com/@Bearliu · a video is worth a thousand words

• x.com/bearliu · shorter thoughts, as they happen

For a money app, that feels like trust.

So where does trust in a product come from?

I open Wise on my iPhone and on the web, freeze my own card, and put its landing page next to Westpac and PayPal.

Three lessons came out of it.

Most of the tools I reach for every day turn out to be interesting once you look at them properly. Dia is one of those, and I use it daily.

Its lead designer is Charlie Deets. I ended up watching a long interview with him on Dive Club, and several things I had liked about Dia without being able to explain suddenly got a lot clearer.

AI can do so many things that teams keep adding a new way in for each of them. This issue is about why that rarely produces a habit.

Four entry points, not four equals

Dia has several ways to reach AI. The important decision is that it does not treat them equally.

The address bar is the primary surface. The others handle more specific jobs around it.

That looks minor and I think it will turn out to be a lasting pattern. Because AI can perform so many tasks, the tempting move is to give every capability its own door. You end up with several usable surfaces and no strong habit around any of them.

Cursor, Linear and Dia all do the same thing. Find the most frequent and natural way in, concentrate investment there, and let the supporting surfaces take the specialised cases.

Four surfaces competing for equal attention rarely create a clear habit. One strong front door, with the rest organised around it, usually does.

Where does the saved attention go?

There is a second question underneath this one, and it is the more useful of the two.

Once a team has lowered the cost of learning its product, where does the attention it freed up actually go?

Plenty of products get simpler and cleaner without helping anyone reach the core value any faster. Complexity drops and so does the thing that made them distinctive. Simplification without a destination is just deletion.

Dia avoided that. It cut the effort Arc’s original concepts demanded, then spent the space it created on AI. Josh Miller has published two figures: chat-with-tabs reached 40 per cent of daily active users, and personalisation reached 37 per cent.

Those are among the few public usage numbers for Dia, and they suggest the AI became a real part of the product rather than a demo attached to it. Compare that with Arc’s own signature features, where multiple Spaces reached roughly 5 per cent.

One note that sharpened this

Removing a door changes behaviour more than adding one. I deleted Twitter and LinkedIn from my phone a week ago. Not a detox, just a practical change so the small screen stopped being the first thing my brain processed each morning.

Seven days later: a full product review finished, client work delivered on time, consistent training sessions, more output with noticeably less end-of-day exhaustion. I had badly underestimated how much was being burned before I opened my first task.

I did not go cold turkey either. Two fifteen-minute windows a day, on a laptop rather than a phone. The feeds still got read. The number of entrances was what changed.

Try this on your own product

Name your primary surface. Not the one you wish people used, the one they actually reach for.

Then look at every other way into the same capability and decide what specific job each one does. If you cannot say what a surface is for in one sentence, it is probably competing with your front door rather than supporting it.

And if you have simplified something recently, check where the attention went. If it did not get spent on the capability that matters most, you did not simplify. You deleted.

Also from me

A few other things I have written, outside the teardown.

Make things the way musicians make singles

I made CUBE TYPE because of a note I wrote to myself in August.

The note said: designers and developers should make things the way musicians make singles. Not portfolio pieces. Not side projects angled toward clients. Just a small, finished thing that shows what you can do, what you care about, and what you have been thinking about lately.

The music analogy landed for me because singles are not auditions. They are statements. A musician drops one every few months and you know immediately where their head is at.

Most creative people I know wait for a brief, a client, a reason. The work stays inside them, unexternalised.

Making CUBE was me testing whether I actually believed my own note.

I think I do.

The box is the screen now

I used to think “thinking outside the box” was about creativity.

Then I noticed the box had changed. It is not a room or a job or a habit anymore. It is the screen itself. Every feed, every recommendation, every notification is still a pipe. And we are inside it, experiencing the world through it, mostly without realising.

The thing I keep coming back to is bookshops. Before algorithms, you walked in not knowing what you would leave with. Someone else’s dog-eared copy on the wrong shelf. A cover that stopped you. A recommendation from a stranger at the counter. None of it was designed for you.

That randomness was not inefficiency. It was the outside of the pipe.

The most interesting ideas I have had this year came from conversations that no feed would have served me.

Thirty minutes of competitor research, with the judgement kept

Competitor research used to eat half my day. Now it takes about 30 minutes, and the output still goes straight into a client deliverable.

Here is the part most people get wrong: you do not hand your judgement to AI. You delegate the screenshotting and the copy-pasting. You keep every call that matters.

The workflow has three layers. Mobbin sources real, shipped product screens. Claude structures the patterns across them. And you, the human, choose which competitors are worth studying, pull comparators from other categories that solve the same job, and decide what the gaps actually mean for the client.

One boundary worth saying out loud: this is secondary, observational research. A pattern-and-gap inventory of shipped products, chosen by a person, not scraped. It is not user-validated insight, and it never replaces talking to your users. That honesty is exactly what makes it defensible client work.

Where to next

The full Dia teardown is on the site, including the moving list from Arc and why a $610 million acquisition still does not settle the product-market fit question: bearliu.com/blog/dia-the-budget-transfer

Which surface is your real front door? Hit reply and tell me. I read everything that comes back.

Hello, I’m Bear.

I’m a product designer in Auckland, New Zealand. Most of my work is as a Fractional Design Partner, which usually means being the design lead a small team cannot yet hire full time.

Design Decisions is where I take one product apart each week and write up the decisions behind it. I make videos and record a bilingual podcast for much the same reason. I like working things out in the open.

• bearliu.com · the full teardown library, and what I do for teams

• hi@bearliu.com · the old fashioned way, and I read every reply

• youtube.com/@Bearliu · a video is worth a thousand words

• x.com/bearliu · shorter thoughts, as they happen

AI made the building cheap. It did not make the judgement cheap. So when the machine handles the execution, what is actually left for you? I think three things: taste, judgement and care for details.

Taste is mostly about what you throw away, and being able to say why. I started with a Pinterest board, leaned towards Braun-style ‘less but better’ for the UI, and then said no to a vintage style I quite liked, because it did not fit a flat, modern 3D output.

Judgement shows up when your ideas start multiplying and you have to pull them back in. On paper, CUBE Type turned into four different product ideas before I converged back to one. From there I set the baseline (type something, change the style, export something usable), wrote three principles (effortless, playful, shareable) and tied them to metrics I can measure, like export rate and how long it takes people to start typing.

Care for details is the part people wave at and never explain, so I get specific. A person at a demo told me their brand blue was not my blue, so CUBE got a colour picker. I sketch examples by hand, then send a photo of the page to my AI agent to build. And the transition animations, hover effects and the light and dark mode switch are what make people want to play with it.

Doing things well used to be how you stood out. Now it is the baseline.

Some of what I do at a computer I am aware of doing. Most of it I am not. The clearest example is a keyboard shortcut. Control and space, a small input box appears, I type three or four letters, and the app or the file or the next job is in front of me.

That box belongs to Raycast, and it stopped being a decision a long time ago. It sits somewhere near unlocking a laptop with a fingerprint. I no longer think about it any more than I think about breathing.

No habit arrives out of nowhere, though. That one was designed.

Raycast has more than 2,500 extensions, and that number is doing a lot of work in how people talk about its moat. This issue is about what the number does not tell you.

The consistency is real

Raycast extensions are open source, written mostly in TypeScript and React, and built with Raycast’s own component library.

That constraint buys something valuable. Chrome extensions let developers use any web technology they like, so quality and interface vary wildly. Raycast controls the components and interactions an extension can use, so third-party work usually looks and behaves like a native feature.

The Color Picker extension has around 450,000 installs and 613 contributors. Simple to install, consistent to use, direct enough to be worth having. That is exactly what a healthy platform hopes to show off.

One star extension with 450,000 installs does not prove the ecosystem behind it is healthy.

What the distribution says

Public download rankings show the top 15 extensions mostly sitting between a hundred thousand and four hundred thousand installs. After that the numbers fall away quickly into a long, low-activity tail.

Raycast’s own extension guide has a section on abandoned extensions. When a maintainer stops responding, the team steps in after three failed attempts to reach them. A platform does not write that policy unless it needs it.

So when I judge an extension ecosystem now, the total count is the last thing I look at. Three other signals tell me more.

The distribution between head and tail. If the top 20 hold the overwhelming majority of installs, the long tail may be worth very little to an ordinary user.

The update frequency. How many extensions have been touched in the past six months? Sitting in a store is not the same as still running.

The rate of new developers arriving. Are new contributors showing up fast enough to replace the ones who stop maintaining?

On the figures I can see, my estimate is that somewhere between 500 and 800 extensions are genuinely, actively maintained. Still a valuable core, and a completely different thing from 2,500 all thriving.

Why this matters more than it looks

A lot of people read the extension count directly as Raycast’s defence against Spotlight and Apple Intelligence.

If the experience users actually depend on is concentrated in a handful of top extensions, then a few important maintainers going quiet could change how the whole thing feels within a couple of months. A platform’s real value tends to hide in the median, not in the biggest number on the marketing page.

One note that sharpened this

The happy path is a small fraction of the work. Years ago I worked on a sales system at Vodafone NZ. When we mapped the full purchase journey, the clean flow where a customer buys a thing and gets the thing accounted for maybe 5 to 10 per cent of the design work. The other 90 per cent was refunds, disputes, escalations, fraud, and people actively gaming the system.

Then a PS5 pre-order campaign spiked concurrent traffic. Payments processed, order confirmations failed, real money taken with no order number generated. A room full of senior people ran a war room for a week resolving transactions by hand. Building the thing was never the hard part. Keeping it standing was.

Try this on your own product

If your product leans on an ecosystem, marketplace or integration library, work out three numbers before you quote the total again.

What share of usage sits in your top 20? How many items were updated in the last six months? How many new contributors arrived this quarter compared with last?

If the first number is very high and the other two are flat, you have a catalogue rather than an ecosystem, and the difference will show up the first time a key maintainer goes quiet.

Also from me

A few other things I have written, outside the teardown.

The apprentices were learning too

Pablo Stanley posted about leaning heavily on AI, and compared it to the old masters. Michelangelo had a team. Rembrandt had apprentices finishing his canvases. He just signed them.

The comparison is meant to be reassuring. It mostly worked on me.

But one thing keeps sitting wrong. Those apprentices were not just labour. They were learning. Da Vinci started as one. You stood next to someone better than you, you did the tedious parts, and something transferred.

If AI fills that role, what transfers? Not to the AI. To the next person who wants to become the one directing it.

Maybe we are a transitional generation who will never fully answer that. The people who grew up after us, in an AI-native world, might not even feel the gap. But right now I can feel it, and I am not sure reassurance is the right response to it.

Staged commitment pricing, and where it becomes a dark pattern

The game charged me $14. Then $59. Then $29. I didn’t notice until I’d spent over $100.

The game is Hitman. The entry price felt like a bargain, a big bundle, heaps of content, easy yes. I bought it, played a few levels, enjoyed it. Then the next chapter required an upgrade pack. Fair enough. Then the final two levels were locked behind yet another purchase.

Each step felt reasonable in isolation. Each price point was low enough to avoid real hesitation. But the architecture of the whole thing was designed to make sure I never saw the total until it was too late.

This is a product pattern worth naming: staged commitment pricing. You’re not selling the full product upfront. You’re selling the smallest believable version, building habit and sunk cost, then expanding the ask once walking away feels painful.

It works. That’s the uncomfortable part.

I see early-stage teams make the opposite mistake all the time. They either charge everything upfront (too much friction, too little trust) or give away too much for free and never build a pathway to revenue. The Hitman model is manipulative in a consumer context, but the underlying mechanic, earn commitment before expanding the ask, is genuinely sound.

The question is whether you’re using it to build genuine value or to obscure it.

If you’re designing pricing for a SaaS product right now: map out every moment your user has to make a new financial decision. Are they getting real value before each ask? Or are you just banking on sunk cost and switching friction?

The line between smart staged pricing and a dark pattern is thinner than most founders think.

The standard for conversation just moved

I went for a walk last night with ChatGPT talking in my ear.

Not reading, not typing. Just walking and talking, the way you would with someone you called on the phone.

At one point it said “give me a second” before answering. A small pause, like it was actually thinking. And for a moment I forgot what I was talking to.

That is the thing that got me. Not the capability. The presence. It felt like a high-intelligence person who was genuinely interested in what I had to say. That sensation, available for twenty dollars a month, on a Tuesday evening walk in Auckland.

I keep thinking about what that does to the bar we hold for human conversation. Not in a bleak way. Just honestly: the standard just moved.

Where to next

The full Raycast teardown is on the site, including the interaction model that carries all of this and what the standalone Glaze product implies about its ceiling: bearliu.com/blog/raycast-the-interaction-model

What share of your platform’s usage sits in the top 20? Hit reply with the number. I read everything that comes back.

Hello, I’m Bear.

I’m a product designer in Auckland, New Zealand. Most of my work is as a Fractional Design Partner, which usually means being the design lead a small team cannot yet hire full time.

Design Decisions is where I take one product apart each week and write up the decisions behind it. I make videos and record a bilingual podcast for much the same reason. I like working things out in the open.

• bearliu.com · the full teardown library, and what I do for teams

• hi@bearliu.com · the old fashioned way, and I read every reply

• youtube.com/@Bearliu · a video is worth a thousand words

• x.com/bearliu · shorter thoughts, as they happen

In this video I share how a founder really found me (it was not my content), what actually won the project, and the simple test I would use if I were hiring a product designer today.

A profile or portfolio helps you screen for relevance. It cannot show you how someone thinks. Before we started working together, I did a product audit: problems, recommendations, the reasoning in a document, and a walkthrough explaining how I got there. That audit is what the founder pointed to when I asked him why he chose me.

So if you are a founder comparing designers, give them a small, real problem from your product. Watch which questions they ask first, whether they can separate an important problem from a cosmetic one, and whether they give you a clear recommendation or ten options. After you read their work, are you clearer about your product, or more confused?

A story went round an old workplace of mine that one of Atlassian’s founders was an early Arc enthusiast, and had handed the team a long list of suggestions. I have no idea whether that part is true. What is on the record is that Atlassian later bought The Browser Company outright for $610 million, and that the browser they ship now is Dia, not Arc.

Almost every designer and engineer I know went through a period of loving Arc. That is the part I keep turning over. How does a browser that good, admired by exactly the people who care most about their tools, never get anywhere?

Arc was one of the best-looking browsers anyone has built, and it never reached the mainstream. Both of those facts have the same root, and it shows up before the first click.

The first filter is how it looks

Open Arc’s old website and ignore the words for a moment. The personality arrives immediately. Warm, soft, artistic, generous rounded corners, light animation, a slightly vintage handmade texture. Visually it belongs to the same family as Notion, Substack and Linktree.

Those products tend to appeal to creators and individual users, people who enjoy shaping and organising their digital lives.

The communities where Arc actually took hold looked nothing like that. They were engineers, designers, product managers, heavy knowledge workers who found it through technology media and colleagues. They cared about speed, keyboard shortcuts, multitasking, and whether a browser could survive a complicated professional workflow.

Visual design does not decide adoption on its own. It does answer one question within a few seconds, before anyone has understood a single feature.

Was this made for someone like me?

Linear is the useful contrast. Its interface is restrained, dense and deliberately cool, and it reads as a professional instrument. Roughly the same audience, an opposite invitation.

The second filter is how much you have to remember

A traditional browser asks you to understand two things: tabs and bookmarks.

Arc introduced Profile, Space, Folder, Easel, Boost, Tab, Command Bar and Pinned Tab.

From a designer’s point of view none of that was badly organised. Each concept had a clear purpose and the relationships between them were coherent. The information architecture was arguably elegant.

That is exactly the trap. A concept being understandable does not mean anyone wants to hold it in their head alongside seven others.

Spaces were one of Arc’s most important ideas: separate environments for work, personal life or a project, each with its own tabs and state. Genuinely useful for complicated workflows. By the team’s own figures, only about 5 to 12 per cent of users ever adopted multiple Spaces. Calendar Preview reached 0.4 per cent.

Years of differentiation never became part of most people’s behaviour.

Two notes that sharpened this

Most portfolios fail before the first scroll. Not because the work is weak, but because the presentation treats finished screens as the story when the decisions behind them are the story. Anyone reviewing at an early-stage company is not asking whether you shipped something. They are asking whether you can think through a problem and make a call. Polished screens do not answer that, and the same logic applies to a landing page.

A deadline teaches a tool faster than a tutorial does. I had seen the word “Skills” float past in articles for months and filed it under things to look into later. The moment I had a real friction point I wanted solved, the concept landed in about a minute. Concepts do not stick because they are explained well. They stick when someone needs them.

Try this on your own product

Two questions, and take them in order.

Look at your landing page with the copy blurred out. Who does the visual language invite, and is that the person who eventually pays you? Then count the invented concepts a new user meets in week one, and for each of them ask what it would take for that concept to be needed rather than learnt.

Anything that has to be memorised before it is needed is a bill you are sending before you have delivered anything.

Also from me

A few other things I have written, outside the teardown.

The portfolio gap is not about skill

Most designers I know are more capable than their portfolio suggests.

That gap is not about skill. It is about evidence. The work exists, the judgement is there, the taste is real. But nothing in the portfolio shows it, because the portfolio was last touched two years ago and the case studies read like project reports.

I have been thinking about this differently lately. A portfolio piece is less like documentation and more like a single by a musician. It is not a record of what happened. It is a made thing that carries your current thinking and taste, in a form someone else can actually hold.

The question is not “do I have enough projects to show?” It is whether anything you have made recently reflects who you are now.

For most of us, it does not. And the gap is smaller to close than we think.

A shopping street borrowed the London Underground

A shopping district in Tauranga is using the London Underground wayfinding system to direct people to shops. Not inspired by it. Literally adapted from it. And it works perfectly.

The London Underground visual language, designed in the early 20th century, has outlived nearly every design trend that followed it. Clear hierarchy, high contrast, consistent iconography, ruthless reduction of noise. It was built for one of the busiest transit systems in the world, where decisions need to happen in seconds under pressure.

That last part is the key. Good wayfinding design solves for cognitive load at the moment of decision. A shopper in a busy retail precinct faces the exact same problem as a commuter at Bank station: too much information, not enough time, one choice to make. The context is completely different. The problem is structurally identical.

This is the real test of a design system. Not whether it looks good in a controlled environment, but whether it still holds up when someone drags it into a context it was never meant for. The London Underground system passes that test every time someone borrows it.

There is a useful parallel here for product work. When you are designing onboarding flows, navigation, or any moment where a user needs to make a decision quickly, the question is not “what is the right pattern for this industry?” The question is “what is the cognitive load at this exact moment, and what does the user need to do next?” Answer that clearly, and you are probably already most of the way there.

The best design systems are not precious about their original context. They solve human problems, and human problems travel.

The bottleneck is finishing friction, not drawing skill

Hand-drawn diagrams are fast to make but painful to read. That friction was bothering me, so I ran a quick experiment.

I’ve been using hand-drawn illustration comics to explain product concepts, the kind you sketch out in ten minutes to capture a thought before it disappears. The problem: rough lines and no colour make them harder to scan than they should be.

So I fed one into GPT’s image tool and asked it to clean up the line style and add simple colour. No anime transformation, no dramatic overhaul. Just enough polish to make the visual easier to follow at a glance.

The result was noticeably better. Lines read crisper, the hierarchy was clearer, and the whole thing felt more intentional without losing the hand-drawn energy that makes these feel approachable rather than corporate.

What I took from this: the bottleneck in quick visual communication isn’t always your drawing skill, it’s finishing friction. Most people abandon rough sketches before they publish them because the gap between “good enough to understand” and “good enough to share” feels too wide. A tool that closes that gap in two minutes changes the calculus on what’s worth making.

I’m not suggesting AI polish replaces good visual thinking. But for practitioners who sketch to think, not to impress, this kind of light post-processing is genuinely useful. It lowers the bar for shipping a visual explanation, which means more ideas actually make it out of the notebook.

Where to next

The full Arc teardown is on the site, including what the team carried into Dia and what users later demanded back: bearliu.com/blog/arc-the-moving-list

How many new concepts does your product ask for in the first week? Hit reply with the number. I read everything that comes back.

Hello, I’m Bear.

I’m a product designer in Auckland, New Zealand. Most of my work is as a Fractional Design Partner, which usually means being the design lead a small team cannot yet hire full time.

Design Decisions is where I take one product apart each week and write up the decisions behind it. I make videos and record a bilingual podcast for much the same reason. I like working things out in the open.

• bearliu.com · the full teardown library, and what I do for teams

• hi@bearliu.com · the old fashioned way, and I read every reply

• youtube.com/@Bearliu · a video is worth a thousand words

• x.com/bearliu · shorter thoughts, as they happen

I talk to AI every day now. Sometimes it is a terminal, sometimes the ChatGPT window, sometimes my phone, sometimes an app on the desktop. Sometimes I type it. Sometimes I just say it out loud. The whole thing has become completely ordinary.

Then I worked out how recent all of it is. ChatGPT arrived a few years ago, and that is the entire history of the habit. The part that interests me is not how fast we learned to use it. It is how fast we stopped finding it remarkable.

Almost every AI feature I am asked to look at has the same shape: a competent chat box with very little on either side of it. That gap is what this issue is about.

The chat box is becoming table stakes

The chat interface in Google Health is not new. You ask, it answers, the conversation continues. That pattern now shows up in almost every category of software.

The more interesting parts sit on either side of it. How does the conversation start, and what happens after one ends? I find it useful to split an AI conversation into three stages.

Before: someone has to speak first

Before you type anything, the system has to find something worth discussing and turn it into a question that is easy to answer.

Google Health is good at this. It reads your sleep and activity and produces something like: “Going to bed around midnight seems to be working well for you. Does keeping that schedule feel manageable as you head into the weekend?” Underneath sit a few answers you can tap.

You never face an empty input field. That matters more than it sounds. A blank box holds unlimited possibility and still leaves most people with no idea where to begin, which is one of the quietest ways a capable AI feature dies.

Google speaks first and you only have to tap. From your side the coach feels attentive. From Google’s side, the cost of getting one more signal out of you has dropped to a single interaction.

During: the part that will commoditise

Google Health reads personal data, draws charts, cites external sources, and keeps things moving with follow-up questions. It does all of that competently.

It will also stop being a differentiator. Any company with enough model access, data and engineering will eventually ship a reasonable chat experience. The chat box is on its way to becoming infrastructure.

After: where retention actually lives

Will it summarise what changed a week later? Will it notice your sleep drifting and raise it before you ask? Will it remember the goal from last time and check on it in a few days?

Across three weeks, almost none of that happened. No automatic weekly report, and the coach rarely picked up an earlier thread. Nearly every interaction still started with me opening the app.

Some of that is fair. The product is new, and unsolicited health advice carries real risk. One wrong or unnecessarily alarming notification could do lasting damage to trust.

The pattern still holds well beyond Google. Before decides whether people start. During is table stakes. After is what turns a feature into a relationship.

Two notes that sharpened this

Month one is not the signal. Most teams hit peak AI productivity in the first month and then quietly plateau. The early weeks feel like finding a new gear, because the obvious inefficiencies go first. What is left after that are capability gaps and knowledge gaps, and those are not prompting problems. AI stops multiplying and starts maintaining.

Bolting on is not the same as redesigning. Most teams still use humans as glue, copying out of one tab and into another so the next system can catch up. It looks like coordination, and it is friction wearing a lanyard. The steam engine did not transform manufacturing when it was invented. It transformed manufacturing when factory owners stopped bolting it onto the existing floor plan and redesigned the floor.

Try this on your own product

Take your AI feature and split it in three.

Before: what makes someone start? If the answer is an empty box and a hopeful tooltip, that is your weakest layer. During: is there anything here a competitor could not ship in two quarters? After: what happens between sessions, without the user doing anything at all?

Most products I look at have a strong middle and almost nothing on either side.

Also from me

A few other things I have written, outside the teardown.

Thinking is not a step you can hand off

I switched to a new research workflow a few months ago. Perplexity for discovery, Obsidian for notes, Claude for synthesis. It works. The output is faster and usually pretty good.

But somewhere in that chain I noticed something: I felt oddly distant from the work. Like I had supervised it rather than done it.

So I pulled out a notepad for the next project. Slower, messier, nothing shareable at the end of it. But when I sat down to actually write, the thinking was already there. I had not just gathered it, I had done it.

I do not think that part has an equivalent in any tool I have found. Not because the tools are bad. Because the thinking is not a step you can hand off without handing off the thing itself.

Now the default is sameness

There is a quiet irony happening in product design right now.

For years, the smart move was to borrow from the big players. Apple’s visual language lowered the trust barrier. Familiar felt safe. So everyone pulled from the same shelf.

AI has made that instinct dangerous.

Build something with Claude or any of the popular tools, and you will get a pale, clean, slightly washed-out interface almost by default. Not because you chose it. Because the tool steered you there before you even noticed. A lot of products launching right now look like cousins.

This is where a designer earns their fee. Not by making things look good, but by making deliberate choices that put distance between your product and the AI house style, while still making sense to your specific audience.

Differentiation used to be hard. Now the default is sameness. The gap is the opportunity.

MVP vs MLP: why most products stay minimum and never lovable

Most products get to “it works” and stop there. Eric Ries never said an MVP should be low quality, but that is what it became in practice: ship the function, promise the rest later, never come back.

I spent a second pass on CUBE, a small isometric type tool I built. The interesting part is what I did first. I did not add features. I cut them. Then I spent the time on the typing feel, the cursor, the transitions between views, and the sound.

The feature list did not change at all. The feeling did.

Brian de Haaff has a good line for this: you could eat a can of cat food if you had to, but you would not ask for a second serving. Jussi Pasanen puts it better as a model, build a slice across functional, reliable, usable and delightful, instead of one layer at a time.

What is new is that designers can now do this without waiting for an engineer. I did the motion in this thing with prompts.

Honest limit: CUBE does not solve a real problem. If yours does, you still need an MVP, and it still has to be good.

Where to next

The full Google Health teardown is on the site, including how many collection points fit on a single card and what its citation habits give away: bearliu.com/blog/google-health-extraction-by-design

Which of the three layers is thinnest in what you are building? Hit reply and tell me. I read everything that comes back.

Hello, I’m Bear.

I’m a product designer in Auckland, New Zealand. Most of my work is as a Fractional Design Partner, which usually means being the design lead a small team cannot yet hire full time.

Design Decisions is where I take one product apart each week and write up the decisions behind it. I make videos and record a bilingual podcast for much the same reason. I like working things out in the open.

• bearliu.com · the full teardown library, and what I do for teams

• hi@bearliu.com · the old fashioned way, and I read every reply

• youtube.com/@Bearliu · a video is worth a thousand words

• x.com/bearliu · shorter thoughts, as they happen

A client project I have been working on is about to reach the App Store. It is a fitness product that a startup team has been building for a while, and I have taken more from it than I expected to.

Most of my work before this was with large teams. A startup is a different shape entirely. There are fewer people, so there are fewer places for a decision to hide, and anything you choose to build lands on someone’s plate that same week. You feel the cost of a yes much faster.

Most teams can tell you who their product is for. Far fewer can tell you who it is not for, and say those people out loud.

Linear can. That turns out to be a large part of how it reached more than $100 million in annual recurring revenue without spending much on marketing.

The list of things Linear does not do

Linear supports one level of sub-issues. There is no deep task hierarchy. One of the teams I work with is genuinely unhappy about this.

The default interface has almost no decorative graphics. The mobile experience is thin, because keyboard shortcuts and hover tooltips do not translate to a touchscreen. It also refuses to stack concepts the way Jira does with Boards, Sprints, Epics, Components and Versions.

Every one of those omissions costs it a group of users. Large enterprises that need complex permissions and approval chains go to Jira. Project managers who live in nested hierarchies pick something else. People who work mainly from a phone never get the full product. A non-technical founder opens it, sees few visible features, and decides it is not serious enough.

Linear accepts that all of those people will leave.

Losing the right customers is cheaper than keeping them

That sounds like giving up revenue. It is also cutting cost.

A badly matched customer brings more than a subscription. They bring longer sales conversations, more training, more complicated support, and a stream of feature requests that matter to almost nobody else. If they only discover the mismatch after adopting the product, you have already paid to acquire and support them.

Linear’s design lets those people leave early. They open it, try a few things, and see quickly that it is not their tool. Linear loses the subscription, and avoids everything that would have come attached to it.

That is where restraint stops being a design preference and starts shaping the business. A leaner team, a simpler sales process, and growth that runs mostly on recommendations between teams that already fit.

Two notes that sharpened this

Scope creep does not announce itself. Working on someone else’s product I flag it reflexively: this changes the scope, is that the direction we agreed? Then I built my own thing with AI tools and caught myself doing exactly what I warn clients about. No single bad decision, just a quiet drift, one “while I am in here anyway” at a time. What helped was using the assistant to interrogate features rather than generate them: what problem does this solve, what does it cost in focus, does it serve the original intent.

Shipping used to be the filter. The effort of building something did the work of saying no for you. If it was not worth three weeks, it probably was not worth building. Now that the distance between a vague idea and a working thing has collapsed, that filter is gone, and you end up optimising for output instead of direction. The teams I see holding their shape are the ones where a real brief and a real deadline do the job friction used to do.

Try this on your own product

Name the customer you are prepared to lose. Not the one you have not got around to serving yet. The one you would turn away.

Most teams can describe their target customer in a sentence. Very few will say out loud who they are willing to disappoint. When nobody says it, features keep accumulating, the visual language keeps getting more neutral, the copy keeps getting broader, and eventually everyone finds the product quite good while nobody feels it was built for them.

Where to next

The full Linear teardown is on the site, including the first-run experience and why its most important feature does not appear on day one: bearliu.com/blog/linear-the-restraint-tax

Who is the customer you have decided not to serve? Hit reply and tell me. I read everything that comes back.

It turns out most of my day no longer needs that precision. Voice input handles a lot of it now, and a great deal of the mouse work is a single click rather than a careful drag. The constraint that ruled the walking pad out had quietly stopped applying.

Maybe half the day still needs a steady hand, and that half is the part I enjoy most. Worth noticing. When the tooling changes, what is left standing is usually the part that was the real work all along.

Ask a product team which features matter and most of them will say all of them. Ask the same team to rebuild from scratch and the answer gets honest very quickly.

The Browser Company gave that answer in public. Arc never broke through, and never held more than 0.1 per cent of the browser market. Dia, built by the same people, launched in June 2025, and three months later the company sold to Atlassian for $610 million. What changed between the two products is a list, and the list is the useful part.

The moving list

Arc asked a lot of a new user. Profile, Space, Folder, Easel, Boost, Command Bar, Pinned Tab. Tabs and pinned tabs needed no explanation. Almost everything else was invented, and each invention arrived with its own logic.

Every one of them had a reason to exist. Put together, they stopped being a set of features and became a new product language.

Attention is the budget here. Say someone will spend ninety minutes in their first week working out how a product behaves. Six invented concepts at ten minutes each eats most of that. By the time they reach the part that makes the product worth switching for, the patience has gone.

When the team rebuilt as Dia, they carried the Command Bar, Split View, the sidebar structure and the tab lifecycle that quietly archives what you stopped using. They left Spaces, Folders, Easel and Boost, along with several of the AI features added late to Arc.

The Command Bar is the one that matters. In Arc it had already become the single place you expressed intent: open a page, search, run a command, ask something. Dia kept it and made it the main way you reach AI. It has now survived two generations of the same team’s thinking, which is about as strong a signal as a product asset can give you.

Read the list twice

There is a second list, and most people stop before they get to it.

Around six months after launch, Dia began bringing Arc features back, starting with a sidebar mode. Some things had been cut too fast.

So a moving list is worth reading twice. What survives the rebuild tells you what a team believes is core under pressure. What comes back later tells you where users actually felt the value. The gap between those two lists is where the first judgement was too aggressive.

You can run this without a rebuild. Asking a team what is not working invites explanation and defence. Asking them to keep only half forces a ranking, and the ranking is what you were after.

Two notes that sharpened this

Most products lose people before the value arrives. The gap between someone’s first interaction and the moment they think this is worth my time is a growth variable, not a soft UX concern. Two habits quietly widen it: the feature tour, which asks for trust before giving a reason to trust, and configuration friction, which bets on willpower instead of product quality.

Arc’s ideas were not bad. The bill for learning them simply came due before the payoff did.

Subtraction is the skill. A good illustrator strips reality down to the fewest marks that carry the idea, and the deciding is where the craft lives. Early teams often have the opposite instinct: more features, more onboarding steps, tooltips explaining the tooltips. The product ends up a detailed sketch of everything the team knows rather than a clear signal of what a user needs to see right now.

Try this on your own product

If you had to rebuild tomorrow and could keep only half of what you have, which half survives?

Write that list before you look at your roadmap, so the roadmap does not answer for you. Then ask the harder second question. Of the things you would cut, which would users ask you to bring back within six months? If you cannot answer that one, you may not yet know where the value is actually felt.

Where to next

The full Dia teardown is on the site, including why a $610 million acquisition still does not settle the product-market fit question: bearliu.com/blog/dia-the-budget-transfer

If you have run your own moving list, I would like to see it. Hit reply and tell me what survived.

I just finished 100 Things Every Designer Needs to Know About People. It is old by internet standards and almost all of it still holds. Most of it is not about screens at all. It is about attention, memory, and how much a person can actually hold at once.

That turned out to be useful for this issue, which is about a product running straight into those limits.

Raycast is one of the smoothest tools on macOS. Two keystrokes carry the whole product. Enter runs the main action, Cmd+K shows everything else you could do with the thing in front of you. Learn that once and you can operate more than two thousand extensions.

Then AI arrived, and the same two keystrokes started to look like a ceiling.

What have you been reading lately? Hit reply if something has stayed with you. I am always after the next one.

Two keystrokes, and where they stop working

Open Raycast and type three letters. A list appears. Enter runs the top result, Cmd+K opens the other things you could do with it. Launching an app, finding a file, running an extension a stranger wrote, it is all the same rule.

That is why 2,500 extensions do not feel like 2,500 things to learn. You learn one grammar, and every extension after that is nearly free.

I have turned this into a check I now run on other products. What is the user’s main action? When they need more choices, what do they reach for? Does that rule cover every feature? Then go looking for the place the rule stops holding, because that place is usually the ceiling of the product’s structure.

On system tools and quick actions, Raycast passes almost perfectly. It stops holding at AI.

The command bar has one rhythm. Appear, act, disappear. You summon it, type, run something, and it is gone within seconds.

AI has a different rhythm. Persist, iterate, build up context. The first answer is a starting point. You add a file, change the tone, compare a few options, keep going from what came before.

So Raycast now has two doors. Quick AI in the command bar for a single answer, and AI Chat in its own window for a conversation. Before you ask anything, you have to decide which one you are in.

It looks like a tiny choice. It also undoes the thing Raycast was best at. The product that removed the cost of operating has quietly put one back.

Glaze is the receipt

In March, Raycast shipped Glaze, which generates native desktop apps by talking to an AI. The interesting part is not what it does. It is where they put it.

Glaze is not inside the command bar. It is a separate product, with its own engineering, its own brand and its own budget.

A standalone product costs far more than a strategy statement. When a company is willing to pay that, it is telling you something about the old product that no press release will. The team already knows the command bar cannot hold what they want AI to do.

Worth borrowing next time a company ships a new surface. Put the vision aside and ask a narrower question. What could the old product not do, that forced them to build a new one? The answer usually sits closer to the real strategy than the positioning does.

Two notes that sharpened this

The model is rarely the problem. Most poor chat experiences fail on interaction design, not intelligence. Three layers decide it: input, where an empty text box asks too much of someone who cannot yet articulate what they want; output, where plain prose is usually the wrong format; and refinement, where teams make people re-describe an edit in a sentence instead of handing them a slider or letting them click the part they want changed. AI bolted on as a feature behaves differently from AI woven into the work, and users feel that difference long before they can name it.

The window for new patterns is closing. We are in the short phase where the limits of the old interaction model are obvious and the new one has not settled. Phases like that do not last. Teams paying attention now get to shape what these interactions become, and everyone else inherits whatever the large platforms standardise first.

Try this on your own product

Three questions, in order.

What is the main action in your product, and what do people reach for when they need more than that? Does the rule still hold at the edges, or is there a feature that already needs its own window? And if there is, is that feature the one you charge for?

Raycast’s answer to the last one is uncomfortable. The free tier already covers most of what people use daily. The clearest reason to pay is AI, which is the part that fits the original design least.

Where to next

The full Raycast teardown is on the site, with the screens, the extension ecosystem numbers and what they suggest about the moat: bearliu.com/blog/raycast-the-interaction-model

If you are adding AI to something that was not designed around it, hit reply and tell me where it stopped fitting. That is the part I find most useful to hear.

It is August already, which in AI time feels like it should be next year.

What strikes me lately is how much has not moved. I started drawing again this month, something I did constantly as a teenager and then put down for years. Picking it back up, almost none of it needed relearning. The tools around it have changed completely. The thing itself has not.

That gap is what this issue is about. Some products are built to be noticed. Others are built to keep working while you forget they are there. We tend to grade both with the same ruler.

Apple Health ships on every iPhone. It sits at a 3.0 rating, and that number grades it as a product people chose. Almost nobody chose it. You bought a phone, and it was already there.

Nobody downloads Apple Health

Most of what I take apart is something people actively went and got. Apple Health is unusual. Buy an iPhone and it is already installed. Start wearing a Watch and it quietly begins collecting steps, heart rate, sleep and workouts in the background.

It sits closer to Settings or Contacts than to Fitbit. We do not open those because they are exciting. We expect them to be reliable, and to be there when we need them.

People still judge it against Fitbit and Whoop. Open Fitbit and you get a sleep score, recovery information and a suggested action for today. Open Apple Health and you get a Summary page of pinned metrics and trends, then a Browse tab covering activity, body measurements, hearing, heart, medications, nutrition, sleep, symptoms and vital signs.

The usual complaint is that there are too many categories. That is not quite the problem. Those categories run on three different logics at the same time.

Heart, respiratory and hearing are body systems. Activity, sleep and nutrition are behaviours. Symptoms, medications and vital signs are clinical records. You are being asked to hold three competing maps in your head at once.

Two scorecards

Consumer products are measured by engagement, retention and time spent. The team wants you back tomorrow, staying a little longer.

Infrastructure is measured by the opposite. We do not open cloud backup each morning to check it still works. We do not turn on a tap to admire the plumbing. Infrastructure earns its keep by being stable, trustworthy and unobtrusive, and most of the time you should barely notice it.

Apple Health was built to the second scorecard and is being graded on the first.

It has to hold more than 150 kinds of health data arriving from the iPhone, the Watch, third-party devices, fitness apps, manual entry and medical institutions, all funnelling into HealthKit on the device. That is what buys the compatibility. A hospital record, a heart-rate reading from a Watch and a weight you typed in yourself can all live in the same place.

The cost is that it cannot give you Fitbit’s tidy, composed dashboard. Most of Fitbit’s data comes from Fitbit hardware, so Fitbit gets to decide what matters and in what order it appears. Apple Health has to stay neutral. It cannot organise the whole experience around one device, one goal or one idea of wellbeing.

So the capability that makes Apple Health valuable is also what produces its most visible usability problem. Sometimes an interface is simply the structure underneath becoming visible.

Two notes that sharpened this

You are probably not the target user. I watched the new Mario film with my daughter and thought it was loud, shallow and basically plotless. IMDB agreed with me. Then I caught the mismatch: the audience is six to fourteen year olds, and very few of them leave reviews.

The people buying tickets were exhausted parents whose kid would not stop asking. Box office and critic scores have almost nothing to do with each other when your buyer is a child and your decision-maker is a tired adult. Founders in their forties building for Gen Z make the same error with their own taste.

The layer underneath stays invisible until it fails. Roughly 70 to 80 per cent of daily work already happens inside a browser, and almost nobody treats the browser as a product decision. We spend our energy choosing between apps and ignore the layer all of them run on. Infrastructure has that problem permanently. It gets noticed on the day it breaks and taken for granted every other day.

Try this on your own product

Which scorecard is your product actually built for, and which one are you being graded on? When those differ, the gap shows up in your reviews long before it shows up in your revenue.

Then the harder question. Who is leaving your reviews, and are they the same people who get the value? If they are not, you may be tuning the product for an audience that never had to live with your decisions.

Where to next

The full Apple Health teardown is on the site, including the two design cracks I do think are real and why most companies should not copy this kind of restraint: bearliu.com/blog/apple-health-infrastructure-by-design

If something you are building is being measured with the wrong scorecard, hit reply and tell me which one. I read everything that comes back.

This newsletter went quiet for a few months. The honest reason is that I could not answer a simple question about it. Who was it for, and what was it about?

I have an answer now. It is back, it is much narrower than it used to be, and it has a new name. If you subscribed to this as Bear Academy, you are in the right place.

Design Decisions is about the choices behind digital products. The question is rarely whether a product is good. It is what a team decided, what they gave up to get it, and which constraints they were working inside. The main format is the product teardown. I pick a real product, use it properly for a few weeks, and take it apart in public.

Teardowns earn that place because they are the one format where the decision is still visible. A case study shows you the outcome after the fact. A teardown lets you reason backwards from the interface to the choice that produced it, and the choice is the part you can reuse.

If you are building something early, this is written for you. Founders, designers, product managers, engineers, people working alone or in small teams. What you have in common is that you are deciding before all the answers are in.

Here is the kind of thing that turns up.

Apple asks you for almost nothing. Google asks you on every screen.

I spent three weeks wearing a Fitbit so I could study Google Health properly, with Apple Health as a control.

Most of what lands in Apple Health arrives on its own. The Watch and third-party devices write in the background, and the app rarely asks you anything at all. It does not chase feedback or check whether a recommendation helped.

Google Health does the opposite. Open it and the AI coach may comment on last night’s sleep, a recent workout or a change in your heart rate, then ask how you feel about it.

I asked mine what my resting heart rate actually meant. It pulled thirteen days of my data, showed a range of 59 to 68 beats per minute, drew a chart I could inspect day by day, and backed the explanation with external health sources. Then it asked me something back: does that overview give you the peace of mind you are looking for? When I mentioned I was taking heart medication, it carried that into the next reply. When I switched to Chinese halfway through, it followed.

As a piece of interaction design, the coach is genuinely well made. The more interesting question is why it is so eager to keep the conversation going.

My first instinct was to grade them. One of these had to be the better design. That instinct was wrong, and correcting it was the most useful thing I took from the whole exercise.

Apple’s health strategy runs on the iPhone and the Watch. It needs you to believe that years of sensitive records can sit safely inside its ecosystem, because that trust is part of what keeps you buying the hardware. Fewer questions, fewer interruptions and more on-device processing are not restraint for its own sake. They are part of the offer.

Google’s strengths were built around data and machine learning. Health data carries tighter restrictions, and Google says it does not use it for advertising. It still needs behavioural feedback to improve its products and its models. So a good coach does two jobs at once. It helps you understand your body, and it collects the kind of signal a passive tracker can never reach.

Same job, same data, opposite interfaces, and both of them right.

Try this on your own product

Take your most visible design choice. The free tier, the constant prompt, or the thing you pointedly refuse to ask users for. Read it back to how you make money. Does it hold up as a business decision, or only as taste?

Then the harder version. If a competitor copied that choice without your revenue model underneath it, what would it cost them?

What happens from here

One issue a week. One question about how a product got its shape, and one thing you can take back to whatever you are building.

Six complete teardowns are already on the site, each with the full argument and the screens attached: Apple Health, Google Health, Linear, Arc, Dia and Raycast. The two behind this issue are The Restraint of Apple Health and Why Does Google Health Keep Asking You Questions?

If something you are building runs into this, hit reply and tell me about it. I read everything that comes back.

Lately, I’ve been reflecting on a familiar feeling: the anxiety of missing out on the AI wave.

Even as someone who stays close to tech, I sometimes wonder — am I falling behind? A recent trip back to China made that feeling stronger. Surrounded by relentless hustle and pressure, it was easy to feel like everyone else was moving faster, grabbing every opportunity, while I was standing still.

But I’ve felt this before. Years ago, after moving to New Zealand and starting from scratch, I watched peers back home building companies, raising funding, making waves. That same FOMO crept in.

What I’ve learned is: this fear never fully goes away. But we can learn to live with it. Real calm doesn’t come from chasing every wave, but from finding one or two things that matter deeply — and doing them well.

Staying well, focused and grounded in a fast-moving world might just be the success that counts.

Goodies for this week

When Life Interrupts Your Projects: Lessons From Balancing Family and Building a Startup

Life doesn’t ask when you’re ready.
Sometimes it just interrupts everything.

I disappeared from YouTube for a month to take care of my dad.
That pause forced me to rethink how I work, how I create, and how I balance two worlds.

In this video, I share five lessons that helped me recalibrate.
Time as a portfolio.
Redefining progress.
Building redundancy in life.
Flexible creative rhythm.
Identity that survives disruption.

If you’re building a career while juggling real life, this might help you think differently.

Building a Website in 15 Minutes with Framer AI

I recently watched FrameSpace’s video “I made a website in 15 minutes (Framer AI Features)”, which introduces two new AI-powered functions in Framer: WireFramer and AI Components. Both features are highly practical, especially for designers who need to move quickly from concept to prototype without leaving the Framer environment.

The WireFramer tool allows users to generate a full wireframe layout from a simple text prompt. What makes it powerful is that everything happens within Framer—no exporting, importing, or switching between tools. Once the wireframe is generated, it can be edited directly: you can replace text, swap images, and adjust layout details until it forms a working prototype. For many small projects or early-stage ideas, this drastically shortens the time from concept to presentation.

The second feature, AI Components, extends this idea into interactivity. It lets users describe a desired component—such as a countdown timer—and the AI automatically builds a functional version of it. In the demo, the creator uploads an image of a clock, asks Framer to turn it into a working timer, and the system produces it within seconds. While it’s likely that the showcased examples were carefully selected and that more complex components still require manual work, the potential is evident: Framer is evolving from a web design tool into an integrated, AI-driven creation platform.

For independent designers and content creators, these tools could reshape how digital products are prototyped and shared. I plan to test these features in real projects to see how well they perform in practice and may later create a tutorial or mini-course to explore their practical impact on design workflows.

Original video:

👉 I made a website in 15 minutes (Framer AI Features) - YouTube (FrameSpace)

Can AI Be Used in Design?

Can AI Be Used in Design? Absolutely. But not in the way where you just toss in a prompt and expect magic. The real power of AI in design is in breaking things down.

Here’s a recent example. I was working on the landing page for JAM and needed to define the typography styles. After discussing with AI, I decided the fonts ( a Chinese and an English font) and the styles. Then I asked ChatGPT to generate a JSON file for those styles. I used a Figma plugin to import that as design tokens and instantly apply the styles in Figma.

With AI, the whole process took maybe 5 minutes. Without it, doing the same manually would’ve taken around 30, so time saved, a lot.

That’s how I see AI in design. It’s a tool - like a knife, scissors, or screwdriver. Use it with precision, stay focused on the task, let it do what it’s good at, and move on.

I Tried Every AI Design Tool — Here’s What I Found

I watched Paavan, a London-based designer, run a fascinating experiment in his video “I tried every AI design tool. Here are the results.” He used the same web design prompt across nearly all major AI website builders to compare how each tool performs. The outcome confirms what many of us might already suspect.

The clear winners are Lovable, V0, and Mocha — all three tools deliver relatively consistent, high-quality outputs. Lovable stands out for its speed and layout intelligence, producing pages that look like they were structured by a human designer. V0 handles component logic well, generating cleaner HTML and hierarchy. Mocha also performs solidly, balancing speed with clarity.

In contrast, other tools such as Google Stitch, Firebase Studio, and Canva fall short — either creating cluttered layouts or visually outdated designs that are far from usable.

Interestingly, Paavan didn’t test Figma or Framer, likely because they’re not full “one-click generation” systems. But the larger takeaway here is clear: no single AI tool is enough. Just like with large language models, designers will increasingly need to combine tools — one for generation, another for refinement — to achieve reliable results.

For designers like us, that’s actually exciting. It means our role is shifting from “using tools” to “orchestrating intelligent workflows.”

Original video:

👉 I tried every AI design tool. Here are the results. - YouTube (Paavan — Designer in London)

When should you start promoting your product?

Here’s the short answer: not at launch, but when it’s ready.

Before you pour time or money into growth, ask yourself:

1. Is the core product stable?

If key features are still buggy or missing, fix that first.

2. Is there early product–market fit?

Not perfect, but are users coming back? Giving feedback? Sharing it? That’s a green light.

3. Do you have real acquisition channels?

Website, socials, YouTube, podcast, newsletter — something that brings people in without always paying for ads.

4. Does onboarding actually work?

Can new users understand your product and reach value quickly? If not, fix the funnel before filling it.

Promotion works when the product’s ready to keep the attention you earn.

Not earlier.

The newsletter is sponsored by JAM

Learning English isn’t about memorising words—it’s about speaking out loud.

JAM is a one-minute speaking practice app: pick a random topic, talk for 60 seconds, and get instant AI feedback on pronunciation, grammar, and fluency. Just one minute a day takes you from “too shy to speak” to “ready to express yourself.”

Special for newsletter readers: claim 1 month free membership (worth $5) and start your 30-day speaking challenge. One minute a day—see how fluent you can become.

👉 Check here to get a free month trial: jamtalk.co

Hello, I’m Bear—a product designer, UX mentor and an award‑winning bilingual podcast host, currently living in Auckland, New Zealand. I enjoy sharing insights from my work, life, and study, helping all of us grow together.

Bear Academy Newsletter is my weekly email packed with thoughts on technology, design, and productivity—featuring book breakdowns, learning tips, and career reflections. Subscribe for free at bear.academy

💬 Contact

• Youtube.com/@Bearliu - A video is worth a thousand words

• bear@beartalking.com - The old fashion email way

• LinkedIn.com/in/bearliu - My professional life

• Beartalking.com - all my posts, in English and Chinese

• https://twitter.com/bearbig - Majorly I post in Chinese