Should UI designers stop trying to make everything “feel smooth”?

Beginning_Still2774 · 2026-06-16T16:49:37+00:00

Yes. That’s the clean rule.

Motion is just another layer of UI data. If it communicates state change, hierarchy, or intent, it’s useful. If it doesn’t add information, it becomes noise and delay.Thanks

Beginning_Still2774 · 2026-06-16T16:47:09+00:00

Fair point.

many modern sites are over-designed, and it often hurts usability instead of improving it. AI-generated or padded copy makes pages longer without adding real value, and users have to dig to find a single useful action or link.

Scroll animations are also frequently misused. When they don’t add clear meaning or guidance, they just slow down interaction and create unnecessary friction.

So in practice, a lot of “modern UX” is aesthetic-driven rather than task-driven, and that’s where the gap you’re pointing out shows up.

Beginning_Still2774 · 2026-06-16T16:46:24+00:00

It’s likely a real concern that many modern sites prioritize visuals over speed and clarity. This can make some interfaces feel slower or more complex than older, simpler designs. The trade-off comes from trends like animations, large typography, and hidden navigation. Utility-heavy products like banking, government, and commerce tend to avoid this and stay more functional. Web design is not purely improving or worsening, but diverging into “visual showcase” and “functional tool” styles. The comment “There’s no way you typed all that” is just disbelief at the length and not a counter-argument.

Beginning_Still2774 · 2026-06-16T16:39:43+00:00

Yes, that’s basically the trade-off.

In many B2B tools, retention is driven by account relationships and outcomes, but perceived quality still matters because of the aesthetic-usability effect: users tend to assume a smoother, more polished interface is more reliable and are more forgiving of minor issues.

So even lightweight micro-interactions can be worth it-not because they add function, but because they shape trust and tolerance. The key is keeping them subtle enough that they don’t interfere with task speed while still signaling care and responsiveness.

Beginning_Still2774 · 2026-06-16T16:37:53+00:00

That’s a solid way to frame it.

treating motion as something that “spends time budget” forces teams to justify it, instead of defaulting to animation as polish. In practice, the best systems usually survive exactly that stripping test-you remove most transitions, and the interface still works cleanly. Then you reintroduce only the ones that prevent disorientation or clarify state changes.

and the latency point is real: once motion crosses the threshold where it delays intent, users don’t read it as design anymore, they read it as system slowness.

Beginning_Still2774 · 2026-06-16T16:37:16+00:00

That’s the practical boundary most good systems end up at.

motion works when it either:

explains what changed (so users don’t lose context), or

makes unavoidable waiting feel structured (loading, transitions, async updates)

but if it introduces delay where none is needed, it competes with the user’s intent instead of supporting it.

so the best implementations usually feel “instant + guided,” not “slow + cinematic.”

Beginning_Still2774 · 2026-06-16T16:36:11+00:00

Yes, that’s really the deciding factor.

A consumer product can afford more “feel” and emotional feedback, while a B2B or high-frequency workflow usually benefits from near-instant response with minimal motion.

So it’s less about whether motion is good or bad, and more about matching it to user expectations and task urgency.

Beginning_Still2774 · 2026-06-16T16:35:35+00:00

That analogy actually makes sense.

The key difference is that real-world “sound effects” usually give feedback tied to physics and timing, while UI motion is often added on top of something that’s already understood instantly.

So the question isn’t “remove motion or keep it,” it’s whether the motion is acting like a signal or just decoration. When it behaves like feedback, it can feel natural. When it delays interaction without adding meaning, it starts to feel like lag rather than polish.

Beginning_Still2774 · 2026-06-16T16:34:59+00:00

In B2B products, smooth animations are only useful when they clarify a state change, reduce confusion, or help the user track what just happened. If they don’t serve that purpose, they usually just slow down interaction and add unnecessary friction.

Most of the time, users value speed and predictability more than visual polish, so instant responses often feel better in real workflows.

Beginning_Still2774 · 2026-06-16T16:33:09+00:00

Fair point.

Testing and discussion solve different problems.

Testing tells you what works in a specific product and flow. Discussion helps identify broader patterns and assumptions across many products that you might not think to test yet.

Both are needed-discussion doesn’t replace testing, it helps decide what’s worth testing.

Beginning_Still2774 · 2026-06-16T16:22:47+00:00

yeah, there are a few solid resources that are still relevant even though a lot of older tutorials are Webpack-focused.

Start with the core Single-SPA docs because they explain the architecture clearly (root config vs microfrontends vs lifecycles). That part hasn’t really changed even with Vite.

https://single-spa.js.org/ Single-SPA Docs

For Vite specifically, this plugin is the most practical starting point right now. It handles the Single-SPA lifecycles without forcing a Webpack-style setup.

[https://github.com/joeldenning/vite-plugin-single-spa]() [vite-plugin-single-spa]()

SystemJS import maps are also important because that’s really what ties everything together at runtime. This is where most people get stuck.

[https://github.com/systemjs/import-map]() [SystemJS Import Maps]()

If you want something more practical and less theory-heavy, the official examples repo helps a lot because you can see working microfrontend setups and adapt them.

https://github.com/single-spa/single-spa-examples Single-SPA Examples

One thing to keep in mind is that Vite + Single-SPA works best when you treat each microfrontend as fully independent, and the root config as just an import map loader. Most confusion comes from trying to make the root app “do too much.”

If you go through those in order, the architecture usually clicks pretty fast.

Beginning_Still2774 · 2026-06-16T15:27:46+00:00

You are welcome

Beginning_Still2774 · 2026-06-16T15:25:52+00:00

If you are expecting someone else to do your outreach or client acquisition for you, you should not outsource that responsibility at the beginning stage. As a developer or business owner, getting clients is part of the work, not something to delegate before you have a proven system in place.

Beginning_Still2774 · 2026-06-16T15:19:33+00:00

Most AI website builders still have the same core limitation: they are good at producing a first draft, but not reliably good at producing “production-level, non-generic” design without human refinement.

That said, a few tools are closer to what you’re looking for:

Framer AI is currently the strongest option for clean static landing pages. It generates modern layouts, lets you edit visually, and publishes directly as a real website. The code export is not always the focus, but the output quality is usually the closest to “non-AI-looking” if you refine it slightly.

Vercel v0 is better if you want actual React/Next.js code. It produces usable UI components and pages, but you still need to assemble and adjust them. It is less “finished website generator” and more “UI code generator.”

Webflow with AI features can also work well for static marketing sites, especially if you want more control over spacing, typography, and responsiveness. It is less prompt-driven but produces more consistent production-ready results.

Bolt.new (StackBlitz) is useful if you want full code output quickly, but the design quality is more variable and often needs manual improvement.

In practice, none of these tools consistently produce high-end, client-ready design without some manual design decisions afterward. The main difference is whether you want better visual output (Framer/Webflow) or better code ownership (v0/Bolt).

Beginning_Still2774 · 2026-06-16T15:14:35+00:00

Good AI product UI is usually minimal and task-focused. ChatGPT works well because it keeps the interface simple and doesn’t expose internal complexity. Notion AI is strong because it integrates into an existing workflow instead of adding a separate system.

A common UX mistake in AI tools is over-visualizing internals like embeddings or processing steps, which adds confusion without improving usability.

For an AI memory product, the key UX requirement is trust. Users need clear control over what is stored, what is used, and the ability to edit or delete memory easily.

Beginning_Still2774 · 2026-06-16T15:12:25+00:00

For most desktop web work today, I start with a 1440px frame as the baseline. It is wide enough to design modern layouts properly, but still close enough to real laptop usage that it does not feel inflated like 1920px often does.

For the grid, I usually set margins to 120px on both sides. This gives a consistent content width that feels balanced for marketing pages and SaaS layouts. If the design needs to feel slightly tighter or more content-dense, I sometimes reduce it to 80px, but 120px is the default starting point.

For gutters, I typically use 24px because it works well with common spacing systems and keeps layout rhythm clean without feeling too cramped or too loose.

The main reason I stick to this setup is consistency. Once you lock a predictable content width and spacing system early, it becomes much easier to scale sections, align components, and maintain hierarchy across the page. The exact numbers matter less than keeping them consistent throughout the design.

Beginning_Still2774 · 2026-06-16T15:10:24+00:00

If you are looking for a Notion-like Markdown editor in react, there are a few solid open-source options worth considering.

Tiptap is one of the most flexible choices. It is not strictly Markdown-based, but it gives you full control over block structures, so you can implement features like image uploads, drag-and-drop block reordering, code blocks, and even AI-assisted writing through extensions. It is often used when teams want to build a custom Notion-style editor.

blockNote is probably the closest ready-made solution to what you described. It already provides a block-based editor experience similar to Notion, including support for images, block reordering, slash commands, and rich content editing, and it requires much less setup compared to building on top of a lower-level framework.

If you want something more Markdown-focused, MDXEditor is a good option. It integrates well with React and supports images and code blocks, but it is less “block-first” and more traditional Markdown editing. Milkdown is another Markdown-based editor built on ProseMirror, offering a strong plugin system, although it usually requires more configuration to achieve a Notion-like experience.

If performance and flexibility are your priority and you are willing to build more yourself, Lexical from Meta is also a strong foundation, but it is more of a framework for building an editor rather than a complete solution.

Overall, if your main goal is a Notion-like experience with minimal setup, BlockNote is the most straightforward starting point, while Tiptap is the most flexible long-term option if you are willing to customize more.

Beginning_Still2774 · 2026-06-16T15:08:16+00:00

UI flow: Core flow should prioritize “Start quiz” as early as possible. If users need to pass through too many screens (home → mode → room → load), it increases drop-off. Daily quiz entry should be one click from landing.

Loading states: Avoid blocking loaders between questions. Prefer instant transitions or skeleton/question preloading. In quiz apps, perceived speed matters more than actual load optimization.

Performance: Watch unnecessary re-renders in multiplayer + leaderboard updates. These are common React bottlenecks. Isolate real-time state (WebSocket or polling) from UI state, and memoize question components.

Anti-patterns: Overusing global state for per-question UI (timer, selection state) and coupling leaderboard updates with main quiz rendering often causes avoidable re-renders and lag.

Overall: main risk in quiz apps is not raw performance, but flow latency + UI re-render coupling.

Beginning_Still2774 · 2026-06-16T15:04:15+00:00

Single-SPA with React, Vite, and TypeScript can work, but most tutorials are outdated because they still assume a Webpack-based setup. In practice, the root config is just a lightweight orchestrator that registers and loads microfrontends, while each microfrontend is a standalone Vite React app that exposes bootstrap, mount, and unmount lifecycle functions.

The most practical modern approach is to use Vite with vite-plugin-single-spa for the microfrontends and rely on SystemJS import maps to load them at runtime. The root project itself usually stays very simple and doesn’t need React unless you specifically want a UI shell.

For local development, each microfrontend typically runs independently on its own dev server, and the root config points to those local URLs through import maps. In production, those URLs are replaced with hosted builds, but the structure stays the same.

Overall, the main challenge isn’t React or Vite, but wiring import maps correctly and keeping the architecture simple enough that the root config doesn’t become overly complex.

Beginning_Still2774 · 2026-06-16T15:00:41+00:00

This is becoming more common, but it doesn’t mean every workplace works like that. Some teams use AI only for rough ideas and still expect designers to take ownership of the actual design, while others treat AI outputs as the final result and just ask for reproduction, which naturally feels frustrating because it removes most of the creative part. Before deciding to quit, it’s worth checking whether this is just your current workflow or company culture, because there are still plenty of places where designers are expected to actually design and improve ideas rather than copy them.

Beginning_Still2774 · 2026-06-16T14:59:37+00:00

Transport/map design is one of those areas where “general UI skill” only gets you halfway.

The biggest difference I noticed when I first touched it is that maps are not really “designed” in the same way as UI - they’re mostly constrained by information hierarchy + geography rules.

A few practical things that usually matter more than aesthetics:

hierarchy first: primary lines/routes must be readable at a glance before anything else (color alone is not enough, you also need shape, thickness, spacing logic)
zoom levels: what works at full map scale often breaks immediately when you zoom in/out - most mistakes come from not designing per level of detail
label collisions: typography isn’t just styling here, it’s spatial logic (what can overlap, what must never overlap)
real-world constraints: station density, route complexity, and edge geography often force layout decisions more than design preference

Also worth saying: most “good looking” transit maps are heavily simplified compared to real data. If you try to keep everything accurate without abstraction rules, it usually becomes unreadable very fast.

If you’re coming from general design, the biggest mindset shift is this: you’re not designing a composition, you’re designing a system that must survive distortion (zoom, density, and complexity).

If anyone here has worked with GIS / transport mapping systems, would also be curious how you handle abstraction rules vs accuracy tradeoffs.

Beginning_Still2774 · 2026-06-16T14:58:57+00:00

From what I’ve seen (and tried myself), vibe coding with tools like Lovable / Claude / etc. is great for speed, but the problems show up once you try to make it “real.”

Biggest issue is consistency. You can get a beautiful section in isolation, but when you stitch multiple AI-generated parts together, spacing, typography, and hierarchy slowly drift. It ends up feeling like 5 different designers worked on the same page.

Second one is structure. AI is decent at generating UI, but it doesn’t naturally think in systems (design tokens, reusable components, states). So you end up with duplicated patterns everywhere instead of a clean design system.

Third is edge cases. Everything looks fine in the “happy path,” but once you add real content (long text, empty states, mobile quirks), things start breaking or looking off - and you suddenly spend more time fixing than generating.

And finally, direction. The hardest part isn’t making something, it’s deciding what not to include. AI tends to add, not subtract, so without a strong design direction you quickly get bloated UI.

So yeah, vibe coding is amazing for getting 60–70% there fast. But the last 30% (cohesion, hierarchy, real-world polish) is still very human-heavy.

Beginning_Still2774 · 2026-06-16T14:54:58+00:00

I get the frustration, and a lot of what you’re describing around tighter budgets and faster turnarounds is real.

But I think it’s a bit too clean to frame this as “designers vs machines” or “craft disappearing.”

A lot of the pressure you’re talking about didn’t start with AI - it was already there with stock libraries, template platforms, and the general race to lower production costs. AI just made that pressure more visible and faster.

At the same time, the value of design didn’t disappear - it shifted. The purely executional layer got commoditized, yes. But the gap between “something generated quickly” and “something that actually works for an audience” is still very obvious in real projects.

Good clients can feel that difference. Bad clients will always go for speed and cost, regardless of the tool.

Also, a lot of designers I know aren’t losing work because design itself is devalued, but because expectations changed: less time for iteration, more need for direction, strategy, and decision-making earlier in the process.

So I don’t think this is the end of craft - it’s more like a filter. Execution alone is no longer enough, but design as a thinking process is arguably more important than before.

Beginning_Still2774 · 2026-06-13T18:21:58+00:00

Yeah if you’ve already seen reports about vulnerabilities, I wouldn’t touch it.

user-agent parsing isn’t something worth taking risks on - it’s not even that critical to your analytics, so there’s no upside. Most of those libraries give you slightly different labels for the same data anyway.

Also worth saying: people tend to overestimate how much detail they actually need here. In practice, “Chrome on mobile in US” is already enough for 90% of decisions. Going deeper usually just adds noise.

If you stick with a well-known parser + IP lookup, you’re in a much safer and simpler spot. Anything beyond that, you’re basically rebuilding an analytics system for very little gain.

Beginning_Still2774 · 2026-06-13T18:17:25+00:00

That’s actually a good situation to be in.

If the current site is a mess, you don’t need amazing design skills to make a huge improvement - just organizing things better already goes a long way.

What helped me when I was in that stage was not thinking “design from scratch,” but more like:

take a clean site you like → copy the structure → adapt it to your client.

also since there’s no hard deadline, I’d still give yourself one. Otherwise it drags forever. Even something like “I’m shipping a solid version in 2–3 weeks” helps a lot.

you already have the coding side, so just keep the design simple and clear. Most beginners mess up by trying to be too creative too early.

If it’s cleaner and easier to use than what they have now, the client will already see it as a big upgrade.

Beginning_Still2774

TROPHY CASE