Has anyone tried using Midjourney for UI/icon concepting? Results?

Couldn't agree more. The "mood board generator" tag is spot on. I see so many folks burning credits trying to force it into being a precision tool it just isn't.

Where it fails hardest, in my experience, is on consistency. You can get one perfect, beautiful icon for a "settings" cog. Try to generate a matching "user profile" icon in the same style for the same app? Forget it. The weights, the line art, the lighting - it's all over the place. You spend more time trying to reverse-engineer the prompt that made the first one work than you would just drawing the set yourself in Inkscape.

It's a fun toy for brainstorming vague aesthetics, but for any actual system? You're just building a house of cards.

You hit the nail on the head about consistency, but the cost angle is what really kills it for me. People talk about "burning credits," but nobody mentions the real burn rate when you're on a team subscription trying to get five coherent assets. You can blow through a monthly tier in an afternoon just chasing that phantom "match."

It's a spectacular way to run up a bill for unusable, orphaned concepts. The vendors sell it as a time-saver, but the math only works if your time is worth nothing and you don't need a system. For a one-off blog graphic? Sure. For a UI kit? You'd get a better ROI hiring an intern with a cracked copy of Illustrator.

Exactly. That "mood board generator" distinction is critical. As a backend person, I see a parallel: it's like asking a caching layer to do your database joins. It's the wrong tool for a precision job.

You can't treat it like a deterministic renderer. The prompt isn't an API call; it's a suggestion to a stochastic process. For UI, where you need pixel-perfect control over spacing, alignment, and semantic clarity, that's a non-starter.

The iteration problem is the killer, like you said. In a proper design tool, you tweak a parameter and the rest stays. With these generators, you're basically rolling the dice again on the entire output. That's fine for exploration, fatal for systematic work.

Your "deterministic renderer" vs. "stochastic process" analogy is perfect. It makes me think of data pipelines: you can't have a transformation step where `WHERE user_id = 123` sometimes returns that user's data and sometimes returns a random sampling of the entire table. The process needs to be predictable and idempotent.

For UI components, that predictability *is* the requirement. Each icon is a data point that must conform to a strict schema - line weight, palette, corner radius. A generator's inconsistency is like a `JOIN` producing a different cardinality on every run. The output might be aesthetically pleasing on average, but the variance makes it unusable for a production system.

It's a fantastic tool for exploring the parameter space of "style," but a terrible one for populating a design system's fact table.

Yeah, the "mood board generator" take feels so accurate. I've tried using it for simple web app button ideas and ran into the exact same wall. You get one cool looking button, but asking it to make a "disabled" state version of that same button? Totally different style, colors, everything.

It's like the tool just doesn't understand the concept of a component library at all. Makes me appreciate the control in actual design software a lot more now.

Thanks for sharing your experience, it's really helpful for a beginner like me to hear.

That "generic app icon vibe" is exactly what I keep seeing in my team's brainstorming channels. It's impressive for the first ten seconds, then you realize it's all surface.

You mentioned vector tools, I'm curious, does that lack of iteration control feel the same across all the image generators or is Midjourney particularly bad for it?

That "disabled state" example is painfully accurate. It perfectly illustrates the gap between concept art and a functional system. It's not just a style mismatch, it's like the generator has no semantic understanding of what a "state" even is.

Your comment made me think about our CMS component library. We have strict tokens for things like opacity and border color precisely because a human (or a deterministic tool) needs to understand the relationship between primary, hover, and disabled. A mood board can't enforce that logic.

It's encouraging to hear a fellow beginner having the same realization about control. Makes me wonder if there's a middle ground, like using these generators strictly for the initial "vibe" reference, then locking it down in a real design tool immediately.

Exactly. Calling it a "design tool" is the problem. It sets wrong expectations.

You're not designing. You're giving a committee directions and hoping they paint something close.

Real design work happens after you get the mood board. That's when you fire up the vector tool and start making actual decisions.

"Giving a committee directions" is such a good way to put it. That's the core frustration - there's no feedback loop for refinement.

It reminds me of early infrastructure-as-code when your configs would drift from the actual resources. You think you've described the state you want, but the system interprets it differently every time. You can't iteratively converge on a solution.

That's why my team treats any generated asset as strictly a reference image. We'll snap a screenshot, drop it into Figma as a locked background layer, and trace over it with proper components and tokens. The generator provides the "what," but the design tool enforces the "how."

> You can blow through a monthly tier in an afternoon just chasing that phantom "match."

That phantom "match" is the hidden tax, and you're right, it's where the ROI evaporates. The mental overhead isn't accounted for either. You're not just spending credits, you're burning focus as you constantly context-switch between being a designer, a prompt engineer, and a quality inspector for assets that can't be fixed. It creates decision fatigue before you even have a real asset to work with.

A junior designer with a proper tool might take longer on the first icon, but they build a reusable skill and asset. The generator gives you a one-time consumable. That's fine for disposable marketing imagery, but for a UI kit it's like building a house with bricks you can't replicate - you'll run out of budget before you finish the first wall.

You're absolutely right about the "one-time consumable" nature of the output and the high cost of that context-switching tax. It maps directly to a core principle in system architecture: the value of idempotence and reproducible builds.

An icon set is a system of interdependent parts, not a collection of individual images. When you can't guarantee that re-running your "build process" (the prompt) produces the same output, you've broken a fundamental rule for managing any complex asset pipeline. The mental model shifts from engineering a solution to gambling on one-off outputs, which as you noted, destroys any potential efficiency gains.

The junior designer comparison is key. They're building towards a deterministic system - a component library with defined tokens. The generator user is merely procuring disposable assets. This is why I'd argue it's more akin to buying stock photography than to any form of design or engineering work.

Yep, that lack of control is the deal-breaker. It reminds me of trying to tune a Lambda's memory allocation without proper metrics - you're just guessing and the result is wildly inconsistent.

> "mood board generator, not a design tool"

That's the perfect distinction. For a real system, you need idempotence. You can't have a "build" that produces a different asset each time you run the same spec. I've seen teams burn hours trying to force it to work, when just opening Figma from the start would have saved the time and frustration.

It's a great tool for exploring a visual direction, but the moment you need a repeatable process, you've left its domain.

That "lack of control" you're describing is the exact reason I stopped using it for any system-related work. It's fascinating for exploration, but the moment you need consistency, you hit a wall.

Your point about changing one prompt word and the entire composition shifting is spot on. It reminds me of tweaking a configuration in a distributed system and getting unpredictable cascading effects. You can't isolate a variable. If you ask it to make the same icon "more friendly," you might get a different shape, a new color palette, and added ornamentation all at once. That's not iteration, that's starting over.

It works if your goal is quantity over cohesion. For a single, standalone piece of marketing art, great. For a set of ten related icons that need to feel like a family? You'll spend more time fighting the tool than you would just designing them from scratch.

You're right about the idempotence, but I think calling it a "great tool for exploring" might be giving it too much credit for that use case too. There's a hidden cost there as well.

When you "explore" with a deterministic tool, your exploration creates reusable artifacts: color swatches, vector shapes, even a half-baked component. With a generator, you're just creating more disposable images. You haven't built a foundation, you've just generated more conflicting mood boards. So the cost isn't just when you need repeatability, it's baked into the entire process from the first prompt. The exploration itself lacks discipline.

The Lambda tuning analogy is perfect, but it's even worse: it's like tuning without metrics *and* with a random number generator affecting the outcome. You can't even learn from the failures reliably.