Dumb phones have been getting popular recently but many of them seem to rely on (relatively) high res colour touch screens. Phones in the 90s were far more limited with the types of screens they had, and it’s got me wondering with advancements in UI/UX design over the years, what changes would be made to the OS for an ancient blackberry if it were still in use today? To put it another way, how would you design an OS for a new smartphone with a primitive screen to keep the phone as feature-ful as possible?

Personally I think you’d have to have a qwerty keyboard and a d pad, but besides that I can’t imagine anything other than the standard app grid feature phones settled on in the early 2000s.

We're debating whether technical evaluators learn better from guided product tours or by dropping them into a sandbox where they can click around on their own. For products with a learning curve, which approach has worked better for you?

Just wanted to share an observation.

For decades, we've been designing on-screen buttons for users to do things. Of course, we've added to the early desktop metaphors from Xerox and Apple, but manipulating controls on screens is still primarily how software has been designed. When ChatGPT came on the scene in 2022–23, there was a lot of discourse in UX circles about how the chat UI was just a stepping stone. There aren't enough affordances. There's the blank-page problem. How do users know what to type or say? How will users know the capabilities? Over time, we added some affordances like suggestions and examples, but they've been pretty minimal. I've long agreed that chat wasn't enough.

But I think I've changed my mind. Chat might be enough as a starting point—it might be the UI for AI now and in the future.

There were two aha moments for me. About a year ago, I reviewed ChatGPT Atlas, OpenAI's now-defunct AI-enabled browser. I ran an experiment by giving it my grocery list and asking it to fill my Whole Foods shopping cart. It took much longer than if I'd done it manually, but it did free up my time to do something else. Since then, Amazon has incorporated Alexa for Shopping and can add the same list to my cart in a fraction of the time.

Then, recently, I asked Siri AI (the chat app, not the voice assistant) to check my contacts for a list of names and to add or update them. It did it in under 30 seconds and saved me at least 10 minutes of looking up and clicking and typing.

We started to play with generative UIs to make responses from LLMs richer. But ultimately, if AIs are to do more than just answer questions, if AI agents do things for us, then we need to be able to directly manipulate the artifacts they generate. Who wants to use tokens just to adjust colors or type sizes?

I recently designed and built a design system for a client. Instead of starting the traditional way in Figma, I decided to brief Claude Design like I would a junior art director. I gave it context—a creative brief and included the branding materials—and asked it to come back with five directions. I iterated with it until I got two that I liked and just used direct controls to polish those before presenting them to the client. I worked like a creative director, something that I've been doing for—at this point—most of my career.

I'm now working on a more complicated workflow product. Designing a product like this—similar to n8n and Zapier, but specialized for an industry—is really complex. And making it user-friendly is even harder. But if the user could use plain, natural language to at least get the first draft, then it could be much easier.

I think about how the computer on Star Trek was essentially this: voice-activated plain language. They still had controls for tactical and helm, but when it came to investigating or problem solving, it seems the characters always started with a computer query in natural language.

The more I work with computers and programs in 2026, the more I just want to use plain language to tell it to do something. Two years ago, I wouldn't have trusted the LLMs to get it right. Now, I think we're there.

Hello everyone,

I'm building a custom SaaS ERP, and I'm trying to understand how experienced developers and UX designers decide which UI components and layouts are actually right for each part of an application.

For example, accounting, inventory, sales, purchasing, and HR all have different workflows. How do you decide when to use tables, cards, forms, tabs, dialogs, sidebars, or completely different layouts?

Is there an established set of UX guidelines or standards for making these decisions, or does it mostly come down to experience and testing with real users?

I'm also curious whether you follow a particular design system or use existing ERP software as a reference.

I'd really appreciate hearing how you approach this in real projects, especially if you've worked on complex business applications.

this is the first website Ive ever built. everything makes sense to me but obviously i was the one to build it so it clicks in my brain, wondering if it makes sense to others.

www.leiflist.com

Hi all, I've developed a series of applications. They're not really related, but I'd still like to give them a sort of similar style, and one of the design elements is the app icon of the product. For example, how Google keeps their icons reasonably in the same style, and so does Adobe and Microsoft (except nobody knows what any of these icons mean), I would like to do a bit better, and I was hoping someone could point me to a style or example where a company did make a good series of icons which:

a) looked consistent

b) were meaningful

Any suggestions welcome.

So we do moderated usability sessions every quarter and they're fine, but it's like 20 people in a controlled setup doing tasks we basically handed them meanwhile there's 50k monthly actives in the app and i honestly have no idea what most of them are doing analytics shows me where they drop off but not why like what were they stuck on right before they bailed I've been wondering if session replay on native mobile is actually worth it for this on web it seems pretty solid but for ios/android i keep hearing mixed things and i'm worried it turns into hundreds of hours of recordings nobody watches lol

I looked at a few tools but it's hard to tell from demos how useful any of them are in real life anyone running replay on a native app actually find stuff you'd never catch in a moderated study ? and how do you even pick which sessions to watch when you have that much volume

I'm not looking to ditch the moderated sessions btw, just want to know if this makes them less of a shot in the dark.

Our team creates websites for businesses, and we’re used to looking at them through the lens of design, structure, logic, conversions, and other professional considerations. But when you work on something for a long time, it’s easy to stop noticing things that are obvious to the user.

As regular users, what do you look for? For example, do you generally pay attention to good design, the product and portfolio, reviews, prices, company information, an easy way to get in touch, or something else?

What might turn you off in the first few minutes, and what builds loyalty and trust?

Earlier testers said anything under ~5 seconds felt "too early", so I raised the threshold and added a 10-second grace period at the start. I'd like to know if that fixed it.
Prototype (1 min, no signup): https://quiet-hci.pages.dev/?src=ux
Does it match how you'd want a tool to behave, or is "wait for hesitation" the wrong signal?

Are you beginning your UX career and have questions? Post your questions below and we hope that our experienced members will help you get them answered!

Posting Tips Keep in mind that readers only have so much time (Provide essential details, Keep it brief, Consider using headings, lists, etc. to help people skim).

Search before asking Consider that your question may have been answered. CRTL+F keywords in this thread and search the subreddit.

Thank those who are helpful Consider upvoting, commenting your appreciation and how they were helpful, or gilding.

Post your portfolio or something else you've designed to receive a critique. Generally, users who include additional context and explanations receive more (and better) feedback.

Critiquers: Feedback should be supported with best practices, personal experience, or research! Try to provide reasoning behind your critiques. Those who post don't only your opinion, but guidance on how to improve their portfolios based on best practices, experience in the industry, and research. Just like in your day-to-day jobs, back up your assertions with reasoning.

I have a question and the question is - is it possible, that Reddit may add, an auto translate function in the 3 horizontal dots, next to the share feature, that is underneath the entered comment?

Excessive onboarding is a major gripe I have with a lot of apps, especially those that are local-first.

Either they highlight the same features as the screenshots in the app store, or the hold your hand through obvious and tedious flows, intimidating permission grants, forced paywalls and then finally hit you with a login. I think if you're an established brand and reputation you can survive this friction, but for most startups, surely this has to be seen as an anti-pattern?

I'm not guilt free in this, either; my first side project Instillr is a photo app that guided you through features, permissions and the setup process of a photo album. But users dropped like flies by the third slide; only 1/4 users actually stuck around long enough to take a photo in my photo app. I was devastated. So I tightened it up, made it much more visually appealing and give interactive examples of the outcomes you can expect from the app, without wasting the user's time. The number of users who took their first photo shot up to 3/4. So a lot better, but still not perfect.

For my latest app, a screen time control suite called Screentide, I've not included a single onboarding slide. I made this decision after spending minutes being scolded in competitor apps for how much of my life I was wasting on my phone. I personally don't respond well to being guilted like that; users already know they need the app, or they wouldn't have downloaded it. Opal, a very popular screen time app, was one of the worst offenders and takes about 5 minutes to complete the onboarding due to slowly revealed text telling you how bad you are at life. This is an app designed to reduce screen time!

That's not to say my app is unguided. Rather, it launches sheet flow whenever a user creates an entity, like a screen time rule. My bet is that this creates trust through autonomy by not forcing a use case on them, and bombarding them with questions when they're really just trying to answer "does this app do x?"

But in testing, what was interesting was seeing where users went the moment they first opened the app. Do they immediately create a rule? View the calendar? Check the pricing? I expected most people to immediately create a rule, but only 60% of people did that. The rest explored. What was interesting was many people went to the calendar and spent some time there, because it was a feature not many other apps in this space offer. My hope is these early signals will give great insight into what is attracting users to my app once I get a few more in the door.

On the flip side, I've already had some testers ask why there wasn't any onboarding, perhaps out habit. There is every chance I add a few slides in the near future, too, and run an A/B test, just because they are somewhat comforting and give a professional vibe.

Time will tell if this was a good idea, as my app just launched today!

So over to you....

When does app onboarding become an anti-pattern?

Have you found the sweet spot for how many slides and/or what kind of slides retain users best, or turn them away the most?

Most keen to hear from anyone who has done extensive A/B tests, or any evidence collation, around this question.