Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

> If I had to generalize the struggle between design & engineering, they felt they couldn’t meet the requirements given to them in a reasonable amount of time unless “mobile” and “desktop” were scoped separately.

If I had to guess, they think the amount of people who would actually use something that falls outside of the standard desktop/mobile/tablet presets is very low and not worth the amount of extra effort it would take to implement.

In other words, this is one of those things the boss says they want but realistically it's way down the list of real world priorities and if nobody does it, nobody gets in trouble for not doing it, so it wasn't actually important in the first place. Whereas if something's wrong on the desktop or mobile designs, they'll hear about it and hear about it quickly, so they know that IS important.



sort by: page size:

> I’m curious if others have successfully gotten teams of designers and engineers to stop worrying about mobile/tablet/desktop first and instead think in terms of an infinite number of viewport configurations

Sadly, no, despite my best efforts across multiple teams I've led in the last few years.

If someone manages to crack this, I'll hail them as a hero.


> Isn’t this because everything today is designed to be mobile first?

Yes, that's an enormous part of the problem. Mobile and desktop are two entirely different worlds, and you can't have one interface that can deal with both and do so well.

I think it's a disgrace that desktop UI has been made worse because of the existence of smartphones and tablets.


>> It actually is very hard to design a responsive UX that can handle anything from the smallest smartphone up to ultrawide monitors.

Sure I'll agree it's hard, but don't web designers do their work on desktop machines? It seems like even if they are primarily targeting mobile, they must see the results on desktop right? There have to be some known strategies for dealing with it, and they must be aware of the problems. Right?


> Mobile first often made the experience suck for desktops.

I’d have to argue that poor design work in general is the cause for this. “Mobile first” never meant to neglect the desktop experience - designers who do that are just poor designers to begin with.


> Also they didn't consider themselves to be unique and special snowflakes that needed non-standard widgets and theming.

Ugh, this hurts my soul. I've worked with way too many designers who simply had to use their own icons and menus and scroll bars and drop-downs and on and on. Yea, let's throw out the person-centuries of interaction design research that the OS vendor put into the standard controls so that you, 3 years out of design school, can impose your "improved" version of them.


> While I was reorganizing my phone, I had a sudden realization: Settings are typically seen as the result of design failure. The thinking goes that as designers, our goal is to create product experiences that don’t require any adjustments by the user. Consequently, offering customization options is interpreted as a failure to make firm product decisions.

I wonder if the author has ever considered how much users hate when things arbitrarily change as designers try to figure out what the One True Product Experience should be. (Or, more likely, try to optimize some metric management is unhappy about.)


> What's even more rare is a UX designer that also thinks about these things, who are worth a million bucks.

Tell me about it. I've been struggling for years to get our designers to think of their designs as more than pixels on a screen. I'm really tired of having to be the accessibility police, or explain that small viewports and mobile devices aren't synonymous for the nth time.


> It's not that hard.

It actually is very hard to design a responsive UX that can handle anything from the smallest smartphone up to ultrawide monitors.


> you have a lot of design consequences / unintentional visual limitations

Would you mind elaborating on what you think those limitations are?

I feel like it’s easy to say ‘nah we don’t do responsive’ instead of figuring out a way do just do it. I can’t come up with a single example that I couldn’t translate from mobile to desktop in some way.


> The real problem are mobile operating system.

I think it's deeper than that; I think the problem is mobile devices. The OS has to somehow paper-over the fact that there's no mouse, and that everything has to be done with finger-stabs on a 3"x5" screen. That doesn't work with the traditional desktop widgets, so a variety of OS-level widgets and Javascripty plugins is layered on top. But (a) they're not consistent with one-another, and (b) they're not consistent with the desktop metaphor (which isn't going to go away).

Basically, I don't think a phone is suitable for user-input of any complexity. It's a device for selecting content that you then consume passively. It can't be used as a replacement for a desktop. "Mobile first" sounds all very well, but nearly all mobile-first projects have the desktop portion permanently stubbed.


> "These were already signed off/approved/whatever".

> "But... you ONLY did a wireframe of 3 screens, for iPhone 13 only, in portrait, and ... we already have to support desktop/tablet/mobile."

> "Stop deviating - we already interviewed customers!"

> "But... you don't actually show what should happen in various hover/transition states. You haven't accounted for multiple lines of text in these screens. You haven't accounted for different font sizes... etc"

> "Stop deviating".

I've worked with a lot of designers in my career. It has never gone the way your examples went.

A conversation between colleagues with context provided is enough to allow us to work through differences. Explaining that the animation they're suggesting is bespoke, requiring more work across different browsers to ensure behavior and performance is what we want is enough to move us to something more simple, for example.

What I do run into often is developers without an eye for detail, who don't understand things like white space, padding, colors, and assume they're unimportant who then are told they're not and get upset that they need to go back and fix CSS and layout.


> What seems to be lost in these “redesigns” is the why: why are you doing it? If there isn’t a list of benefits long enough to justify the cost and possible risk, well, that’s a problem.

I ask that to myself every single time I update my mac or pixel 3 phone.

The UX gets worse and worse every year, and just when you finally start to get used to it they decide to change things again.

I guess they need to keep internal teams busy 24/7. I've seen it in many companies, people keep throwing A/B tests, see what seem to improve the experience by negligible amount (most of the time their tests are skewed anyways so it doesn't really matter), then they spent millions and hundreds of man hours to move a few buttons and make a few lines of text bigger/smaller. When they deploy it the impact is either inexistent or negative, people get fired, new managers get hired, and they start again.


> so why not make designers code?

Well... I don't want to force someone to do that, but I'd really really really prefer if design people actually did code sometimes, so they understood the reality of what they're 'designing' from an implementation standpoint.

It may take you 6-8 hours to mockup something that is ... logically impossible, which someone 'signs off' on, then 40 hours for someone else to try to cobble together - pushing back is 'combative' and 'negative', etc.

You know how designers don't like people who ask for stuff that "pops" and then want more "pop"? Designers 'designing' stuff that creates practical impossibilities or gaps in state, etc. - programming folks hate that just as much as you hate 'make it pop' requests.

Hey - cool - you "designed" a form with 3 elements! The actual implementation options are 17 for that area. What should happen with 0 selected? Do we want notifications or help text?

Nice - that design looks really slick with 3 checkboxes in a pulldown, but you've sort of just invented a widget that doesn't really exist, will create accessibility nightmares, and you didn't show how this should behave on mobile/tablets.

The number of design people I've met who can actually reconcile clean design with real implementation, usability and accessibility issues addressed is very small.


> So riddle me this: Why was common the reaction of all these different requirements to suddenly pretend everyone is using a phone for everything all the time?

It's very resource intensive and challenging to design multiple interfaces is the obvious answer here. Designing a website with just a few interactions that's accessible, supports mobile and desktop screens, and works in all browsers is already challenging and time consuming enough. Asking for almost a separate interface for different screen sizes and more costs significant resources that many won't have.

> Because that's how many apps and websites now look: Like something designed for a small phone screen and navigation by thumb. I open a website on a 4K monitor with a laser-precision pointing device, and I get an information density comparable to the intergalactic void.

What websites and apps in particular? I agree lazy mobile ports exist and are bad but I'm not experiencing this often with my daily apps and websites.


> I realize that a large cohort finds desktop applications uncool today, but I'm just so frustrated with the idea that serious and powerful desktop interfaces need to crippled in order to fit into a "mobile-first" (a.k.a. "lowest-common denominator") paradigm.

Yeah, my primary issue with this sort of thing is that there is very little personal A/V content I'd feel comfortable uploading to some random server in the first place, but I agree that there are some tools better suited for the desktop and more specifically a keyboard and mouse.

The problem is that a very sizable part of the population doesn't have a desktop. It's not that they think it's uncool exactly but for a lot of people, kids especially, all they have are cell phones and tablets which were designed first and foremost for content consumption. I can't blame developers for wanting to target the needs of that audience to whatever extent they can.


> low density, with oversized buttons and excessive whitespace.

That part is mostly because of smartphones and their small touchscreens. You don't really have a choice with these fat fingers.

And for consistency purposes for multiplatform apps/webpages, desktop interfaces followed.

The unfortunate thing is that we have had smartphones for 20 years and no one could develop a paradigm with good desktop and mobile ergonomics. UIs improved massively from the 1980s to the 2000s, but from the 2000s to the 2020s, there is essentially no improvement. I understand the disruption caused by smartphones, but not the lack of progress. If anything, modern UIs are objectively worse than they were 20 years ago. Look at that mess that is Windows 11, nothing is consistent, even when you only consider what is shipped with the OS itself.


> The issue is that the changes to the desktop were made in service of a use case (that is: a full screen, mono-tasking, touch-based mode) that doesn't really seem to exist on a desktop computer, and so the changes do not improve anything for people using traditional systems.

I think that's not entirely true. The Metro design language isn't really about monotasking and wasn't really about mobile, and I think the idea of adopting as a unified cross-platform experience -- though its a pretty big break from the traditional windowing interface -- had some very good reasons and makes sense even on the desktop. The overlapping windows of the traditional desktop approach are, IMO, a pretty bad UI thing that we've all gotten used to, but something like Metro could do better...

The particular way the implementation worked out in Win 8 originally -- and this has been mitigated somewhat in Win 8.1 -- is still way too mobile focussed, and the sharp break with traditional desktop apps in seperate environments was a horrible UX choice. But I think the problem there was trying as much about pushing vendors to produce Windows Store apps and support WinRT (and, supporting Microsoft's getting yet another cut of the application money, on top of what they get selling the essential dev tools for the platform), as optimizing the UI for mobile.

I suspect that something like Metro really is the interface of the future -- even on desktop-like systems -- but it may take someone other than Microsoft to first implement it right.


> If I were to design UI, I'd design it like how aviation does cockpits.

You seem to not understand the difference between designing UI for professional use where a user has to spend countless hours learning where each button is compared to an app for general population where users have to figure things out on their own.

Try to put an average joe into a jet cockpit, he would not understand a single thing, and he should NOT. You have to emphasize the most used features and elements with bigger font or negative white space in order for people to better understand where they should start and then walk their way into deeper understanding. In a fighter jet cockpit most of the buttons have identical look and it’s impossible to get started without reading a manual.


> The problem is that since the user base is so technically inclined already, they don’t see these as problems. Or if they do, they don’t see them as being important enough.

They may not even realise that it is a potential issue. I'm a technically inclined user, and it wouldn't even occur to me to consider someone doing what Linus did there because I know because I "just know" it won't work and would gloss over it completely.

Fortunately (for everyone else) I'm not in the habit of designing UIs.

next

Legal | privacy