Words.

WIP: Program creation flow

Dialing in the layout in Figma 👆 after exploring the flow with Cursor 👇

Working on this object map to help clarify the system. But in my experience, stakeholders' eyes glaze over with these types of artifacts. They typically don't understand it until they see it in a UI.

This is why I find most “design process” diagrams frustrating. There’s a narrative that no pixels should be pushed or code written until there’s a perfectly defined problem. But making things is a huge part of defining a problem.

Original post

Decided to ditch Arc as my default because it feels bad to keep investing time into a browser that's no longer being developed. Forgot about this insane dark pattern of gating features when it's not the default.

Designing with AI can feel like collaborating with a co-worker. I can give it rough ideas and see what it generates.

This UI needs work, but it only took 15 seconds, allowing for quick iterations. It's a different direction than I imagined, but I’ll incorporate some of these ideas.

Working in Cursor here. So it has the broader context of the flow.

AI code editors aren't just "spicy autocomplete" for devs. It can be a great partner for generating ideas.

Designing in the browser is back!

And it can totally go sideways and be dumb and infuriating. But I think the benefits outweigh the negatives.

Dynamic menu labels - "Replace Emma" instead of "Replace Employee"

These are the kinds of details that are very difficult (sometimes impossible) to achieve in figma, but are pretty trivial in code (via Cursor).

Sure, I could create one menu interaction that shows it in figma. But there's a world of difference in being able to click anywhere and have the menu open with the right content.

(hover states don't show up in screenshots - so the menu icon isn't shown here.)

This is the key to unlocking Cursor in the design workflow. Give up on trying to create production-ready code. Just build something that works to communicate the intended functionality.

The code is just documentation for how the prototype works. Devs can translate to the right implementation. Plus, they'll get to feel smug about how bad the AI code is 🙃

My 2 cents is don't use an existing codebase. It's tempting so you can build from existing UIs. But it adds a ton of technical overhead and dependencies that you don't want for a design workflow.

I spin up a new project in Cursor for each new feature and tell it I'm building a front-end prototype so it keeps the technical complexity to a minimum.

I'm just trying to build something that works. I'll hand it to the engineers to figure out the actual implementation details 😄

Building a fully functional front-end prototype in Cursor and putting it in front of customers for feedback increases the quality of feedback by an order of magnitude over figma with a few happy paths wired up.

And the kicker is that it might take less time to build a fully functional prototype than a barely functional figma.

it's so much easier to spin up decent mock data in cursor than having to type everything out in figma. it helps prevent the bias towards only using clean looking data in mocks.

lol...i basically told Cursor to "make it pop" - and it's not bad

a little more iteration and i think we've got something

going from list to grid took about 10 seconds.

working this way drops the cost of iteration much closer to zero.

the only thing i kind of miss from figma is being able to look at options side by side.

a few prompt iterations to get some small animations going. this is the last 15% that often gets skipped because it takes so long to do everything else.

I'm realizing how much I subconsciously avoid interactions with animation because it's so laborious to prototype in figma. I find myself experimenting and exploring way more in Cursor composer because it's (usually) easy to make changes.

And there's code to hand to the devs to show them how to implement it. Now they can't tell me it's too hard 😄

Polishing a UI in the browser with Cursor composer is so much more satisfying than pushing pixels in Figma.

The argument for wireframes in the design process is usually that it's the fastest way to explore many different ideas. I'm not sure that's true anymore.

I can create a Claude artifact or Cursor prototype with about the same level of effort as writing this post.

And I can iterate through several ideas with more realistic fidelity in a just a few minutes.

Prototyping with Claude is great...until it isn't. Sometimes I get stuck in loops where it starts to forget what it's doing and I'm just clicking the "Try fixing with Claude" button until I hit my rate limit 😞

WIP: Staff member work schedule

https://paulstamatiou.com/the-startup-designer

I'm fairly technically inclined (for a designer), but one of the blockers for me getting into the codebase is dealing with dev environment errors.

Cursor removes most of that blocker for me. It usually gives me the command I need to run to fix dependency problems.

AI isn't a panacea. I still need humans to fix stuff sometimes. I will take the advice to "consult with your team" here.

I could potentially muddle through and figure out how to fix it. But there's a good chance that'll take me an hour or two. And simply pairing with a dev will probably resolve it in 5-10 minutes.

I've really been liking Claude Artifacts for knocking out simple prototypes. Prototyping anything with mild logic complexity is a PITA in Figma. Here's a quick example.