Meaghan Choi

Their words

in terms of like full functionality, things can be a little bit simpler than they are right now. And not every idea is good or necessary. Sometimes adding it is worse.

Their words

Just because it can build and just because it can be a function doesn't mean it needs to be. It adds a lot of product bloat. It makes it very complex.

Their words

Knowing what should be fixed and what should be adaptive or dynamic is a really important decision for you as a designer to make as you're designing these features because I think often people will assume that everything should be customized because it can. I'm very much of the opinion that a lot of people don't want everything to be customized.

Their words

we're still going to need a lot of fixed interfaces. So there's two concepts now that UI can fall into. There's fixed and then there's like adaptive or like non-deterministic is kind of and I think there's just so much that needs to be reliably stable that you don't want to relearn and you don't want to be dynamic like a login screen, billing settings

Their words

invest in like how you define your quality and how you uplevel it and then share that as a workflow that anyone on your team can use and don't do it to stop them. Although it is important to know when to stop and hold the bar, but try and do it in a way that like is additive and is teaching and guiding rather than stopping.

Their words

I don't think and it never has been historically only design's responsibility to mean quality the most successful organizations feel like it's owned by everybody

Their words

I tend to find the more we can share responsibility of what we think quality looks like in our product and not be the gatekeepers but educate and kind of delegate around us so that both our engineers and product partners feel that quality is something that they own and drive too.

Their words

that experimentation of mental models doesn't require that high of craft and it's better done actually in speed in the open in iteration as opposed to spending a lot of time polishing something that's actually the wrong full wrong shape

Their words

sometimes knowing when it needs that craft and polish or knowing when just the shape of it is actually what you're trying to test is really important. And so you might launch something or test something that looks terrible, but what you're actually testing is the underlying mental model of the shape of product. And I don't think it's worth polishing that thing actually because it might not even make sense.

Their words

Those are the really important pieces that we spend a lot of time thinking on that we won't offload because it's about the user model relationship and behavior and like these design polish pieces or some of these updated ones are like really easy ones to offload.

Their words

The UI part of itself is extremely simple because in my goal, we're trying not to invent new UI. We want it to feel so natural that it just becomes intrinsically part of your workflow.

Their words

I think it's really important that you feel a little bit of warmth from these tools. You don't want to be super super detached from them.

Their words

keyboard shortcuts are massive. I would say like there are power tools like Figma and other places where they do consider keyboard heavier but like the primary way you interact with a terminal is keyboard shortcuts.

Their words

the invisible thinking that goes behind building a product. That's one that I think I expect and hire for at Anthropic and I think has been the long unsung hero of product designers everywhere is like the mental model, the interaction model, like the base primitives that compose how you think about what you're interacting with.

Their words

Because you're serving developers, they have very specific expectations with the CLI actually that you want it to be extraordinarily information dense. Like you would show more in a CLI than you would ever probably show in like a guey, like a graphical interface, because there's no such thing as progressive disclosure.

Their words

you might be asking Claude to do execution when you you should actually be asking Claude to do the early thinking. The execution is wrong. Like the shape of the execution is incorrect. And Claude is not good today at telling you if your idea is wrong, it'll just execute on the thing that you ask it to do.

Their words

it doesn't have to be all of your time. And so knowing when to use these tools for execution and offload and knowing when you need to go deep and do the thinky work is a skill set. And I think that's one that I see people doing wrong.