Rami Alhamad

Writing · Thu Mar 12 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Design for Builders Who Arent Designers

Good designers are not people who "make things pretty." They think through edge cases, empty states, hierarchy, interaction costs, accessibility, emotional tone, responsiveness, and all the little moments where a product either earns trust or leaks it. They notice when a butto...

Design for Builders Who Aren't Designers

A practical workflow for product people who need to make better design decisions without pretending design is easy

May 2026

First, the disclaimer: mad respect to designers.

Good designers are not people who "make things pretty." They think through edge cases, empty states, hierarchy, interaction costs, accessibility, emotional tone, responsiveness, and all the little moments where a product either earns trust or leaks it. They notice when a button feels too eager. They notice when a screen has three primary actions pretending to be one. They notice when the state model is confused before anyone has written the state model down.

I think design is one of the parts of product building that will be least automated.

Not because AI will be bad at producing interfaces. It is already getting good at that. The reason is that good design is judgment applied to context. It is taste, tradeoffs, taste again, then a thousand tiny decisions that only make sense when you understand the user, the product, the constraints, and the behavior you are trying to encourage.

That said, most builders do not have a designer available for every feature. Founders, PMs, engineers, and product-minded operators often have to make design decisions themselves. You still need to ship. You still need the screen to make sense. You still need to know when something feels off and how to improve it.

This is the workflow I am using.

It does not make you a designer. It makes you less helpless.

Step 1: Cultivate Taste Before You Touch the Tool

Taste is not magic. It is pattern recognition.

The hard part is that you cannot skip the input layer. If every meal tastes like boiled potatoes to you, you are going to have a hard time cooking something good. Design works the same way. If every interface looks basically fine to you, you will not know what to ask for, what to reject, or what to refine.

So before opening Claude Code, Codex, Figma, or your codebase, spend time looking at good products.

Not as a tourist. As a builder.

Open apps you admire and ask:

  • Why is this screen arranged this way?
  • What is the primary action?
  • What is being de-emphasized?
  • What happens when there is no data?
  • What happens when there is too much data?
  • How much text is on the screen?
  • Where does the interface feel calm?
  • Where does it create urgency?
  • What did they choose not to show?

Mobbin is great for this. If you are working on consumer mobile, spend time looking through screenshots from real apps. Search by category. Look at onboarding, paywalls, settings screens, dashboards, search, profile pages, empty states, and checkout flows. You start to see the grammar of modern interfaces.

The App Store is useful too. Not just the featured apps. Search the category you are building in and look at screenshots from the top 20 products. Screenshots are not the full product, but they tell you what teams think is worth showing. You get a fast read on the category's visual language.

You are building a palate.

Eventually, things start to bother you. A header feels too heavy. A CTA is in the wrong place. A card has too much border. A screen looks expensive but says nothing. That discomfort is useful. It means your eye is starting to work.

Step 2: Use AI to Clarify the Product, Not Decorate It

The first AI pass should not be "make this beautiful."

That is usually where things go wrong. The model reaches for gradients, oversized cards, fake dashboards, purple-blue hero sections, generic icons, and a lot of visual confidence that has no relationship to the product problem.

The better first ask is product thinking:

I am building this feature. Help me think through the user states, edge cases, information hierarchy, and main flows. Do not design the UI yet. Focus on what the screen needs to communicate and what actions the user needs to take.

This is where models are extremely useful. They can enumerate states you forgot:

  • First-time user
  • Returning user
  • Empty state
  • Loading state
  • Partial data
  • Error state
  • Permission denied
  • Offline
  • Overloaded data
  • Success state
  • Upgrade/paywall state
  • Conflicting user intent

Designers are good at this because they know a screen is not a screenshot. A screen is a system of states. Product people and engineers often underweight this. We imagine the happy path, design the happy path, and then wonder why the shipped product feels brittle.

So start with the system.

Ask the model to write a state inventory. Ask it to identify the primary and secondary actions. Ask it what should be hidden until needed. Ask it what the user might misunderstand. Ask it where trust is gained or lost.

Only after that should you ask for interface concepts.

Step 3: Render Layouts Before You Chase Visual Polish

Once the product shape is clearer, I like asking the model to render HTML and CSS concepts.

The instruction that matters:

Focus on layout, hierarchy, and interaction structure. Do not focus on visual styling yet. Keep colors and decoration restrained. I want to evaluate whether the screen makes sense before polishing it.

This keeps the model from hiding weak product structure under visual noise.

At this stage, I want to answer basic questions:

  • Does the screen have an obvious center of gravity?
  • Can I understand it in three seconds?
  • Is the primary action clear?
  • Is the secondary action truly secondary?
  • Does the layout still work with ugly real data?
  • Does the empty state feel useful?
  • Is the density appropriate for the job?
  • Does anything feel decorative instead of functional?

For web products, this can be a simple local HTML file or a route in the app. For mobile products, I often still start with HTML because it is fast. The point is not platform fidelity. The point is seeing the information architecture on a screen instead of in a paragraph.

This is also where you should bring your reference set back in. Put your rough concept next to the Mobbin screenshots or App Store screenshots you saved. You are not copying them. You are calibrating.

Does your screen feel like it belongs in the same category? Does it have the same density? The same restraint? The same clarity? If not, why?

Sometimes the answer is that your product should feel different. Fine. But make that a decision, not an accident.

Step 4: Build a Design Lab Inside the Product

For mobile apps, I have become a big believer in creating a test section inside the app.

Not a production feature. A design lab.

A hidden route, debug menu, or internal-only screen where you can render high-fidelity versions of the feature with fixture data. You want to see the interface in the actual app shell, with the real navigation, real type system, real spacing constraints, and real platform behavior.

This is where the design starts getting serious.

Have the model create multiple variants:

  • Compact vs. spacious
  • Card-based vs. list-based
  • Summary-first vs. action-first
  • Icon-heavy vs. text-heavy
  • Single primary CTA vs. split actions
  • Inline controls vs. bottom sheet controls
  • Minimal empty state vs. guided empty state

Then make the variables live.

Add toggles. Add sliders. Add segmented controls. Let yourself adjust spacing, density, type scale, card treatment, button placement, chart height, icon visibility, copy length, and data volume without rebuilding the app every time.

This sounds like extra work. It saves time.

Most design feedback is vague because the feedback loop is too slow. "Can we try making it tighter?" becomes a ticket. "What if the button moved up?" becomes a branch. By the time you see the alternative, you have forgotten the comparison.

Live controls make taste interactive.

You can sit with the screen and tune it:

  • Too much border.
  • Less padding.
  • More contrast on the secondary label.
  • Header is too tall.
  • CTA is competing with the content.
  • Empty state needs one concrete action.
  • The dense version is better, but only if the labels are shorter.

This is the part that feels most like cooking. You are seasoning. You are tasting. You are adjusting. You are learning what the product wants to be.

Step 5: Move From Variants to a Point of View

At some point, you need to stop generating options.

This is where taste becomes decision-making. A useful design process does not produce ten equal possibilities. It helps you develop a point of view.

For each variant, ask:

  • What behavior does this encourage?
  • What does it make easier?
  • What does it make harder?
  • What kind of user does it privilege?
  • What does it make the product feel like?

Design is never neutral.

A dense interface says, "You are here to work." A spacious interface says, "Slow down and understand." A prominent CTA says, "Do this now." A buried CTA says, "This is available if you need it." A chart says, "The trend matters." A checklist says, "Completion matters."

Pick the version that matches the product's intent.

Then implement that version fully. Not as a sketch. Not as a vibe. Include the real states:

  • Loading
  • Empty
  • Error
  • Success
  • Long text
  • Short text
  • New user
  • Power user
  • Small screen
  • Large screen

If you skip these, you did not finish the design. You made the poster for the design.

The Prompt Pattern I Keep Reusing

Here is the rough sequence I keep coming back to:

1. Product structure

Help me think through this feature as a product system. List the user states, edge cases, primary actions, secondary actions, and information hierarchy. Do not design the UI yet.

2. Layout concepts

Create three HTML/CSS layout concepts for this screen. Focus on structure, hierarchy, and clarity. Keep visual styling minimal. Use realistic data and include empty, loading, and error states.

3. Reference calibration

Compare this concept against the design language of apps like [examples]. What feels inconsistent with that category? What should be denser, calmer, clearer, or more restrained?

4. High-fidelity lab

Build this as an internal test view in the app with fixture data. Add controls that let me toggle density, spacing, CTA placement, card treatment, text length, and data volume live.

5. Final implementation

Take the selected variant and implement it in the production flow. Preserve the decisions from the design lab. Include all major states and keep the implementation consistent with the existing design system.

The key is that the model is not the designer. It is the collaborator that lets you externalize options quickly enough to use your judgment.

What Non-Designers Usually Get Wrong

The biggest mistake is treating design as surface area.

Colors. Shadows. Rounded corners. Gradients. Icons. Animation.

Those matter, but they are late-stage decisions. If the hierarchy is wrong, polish makes it worse. If the screen has no clear primary action, a prettier button will not save it. If the product state is confused, a better card layout just makes the confusion more expensive.

The second mistake is asking AI for final design too early.

Models are eager. They will give you something that looks complete. That completeness is dangerous because it can trick you into skipping the thinking. The output has shadows and typography, so it feels like a decision has been made. But often the actual product questions are still unresolved.

The third mistake is not looking at enough real products.

You cannot prompt your way into taste from a cold start. You need references. You need opinions. You need to know what good looks like in the category you are building for. AI can accelerate your iteration, but it cannot replace your responsibility to notice.

Where Designers Still Matter

A strong designer does this entire process faster and better.

They know which references matter. They know which patterns are stale. They can feel when a layout is fighting the user's mental model. They understand the difference between novelty and clarity. They can make a product feel inevitable instead of assembled.

So this is not an argument that founders or PMs should stop working with designers.

It is an argument that product people should raise their design floor.

The better your taste, the better your collaboration with designers becomes. You give clearer feedback. You recognize stronger work. You stop asking for random changes because you can name what is actually wrong. You understand that "make it pop" is not direction. You can participate in the design conversation without reducing it to preference.

And when there is no designer in the room, you can still ship something thoughtful.

The Takeaway

Design for non-designers starts with respect.

Respect for the craft. Respect for the user. Respect for the fact that an interface is not a decoration layer on top of a product. It is the product, expressed as decisions.

The workflow is simple:

  1. Build taste by studying real products.
  2. Use AI to map the product system before designing the UI.
  3. Render rough layouts to evaluate hierarchy.
  4. Create a design lab where you can tune variables live.
  5. Choose a direction and implement every state.

AI makes this process dramatically faster. It lets a builder explore more options, test more states, and close the gap between intention and implementation.

But the final judgment is still yours.

That is the part worth cultivating.

Building Alma, an AI nutrition coach with the tagline "Eat well, feel well." alma.food

Related