To me, peak usability was 25 years ago, when most applications had a toolbar and a menu that followed a standard pattern. If you're a frequent, non-power-user, you use the toolbar (e.g. "insert row" button). If you're an infrequent non-power-user, you go through the menu (Insert > Row Above). If you're a power user, you remember the shortcuts indicated through underlined letters in menu labels (e.g. Alt, I, A).
If you want to change settings, you open the settings dialog (Tools > Settings), and it as tabs like "General", "Fonts and colors" etc.
Most people were a lot less computer literate back then, but they were able to use most applications with little help. If they really needed help, the help system was built into the application.
The goal back then was to have the user get the work done as efficiently as possible, in effect, minimizing the time the user pends on the application. Modern UX doctrine aims for the opposite goal -- to keep people "engaged" as much as possible. This might be okay for consumer apps, but maddeningly, the same doctrine gets applied to enterprise applications as well. I've literally heard non-techie employees of a Fortune 100 company ask for their legacy green screen terminals back because the new, flashy SPA was slowing them down.
>To me, peak usability was 25 years ago, when most applications had a toolbar and a menu that followed a standard pattern.
I've done different sorts of tech support since grade school and people always ask me how I got so 'good at computers', I they never believe that actually reading the menus is 90% of it and that once you learn the common ways programs are arranged and some common shortcuts you pretty much know how to use all of them.
One of the most expensive pieces of software around is a Bloomberg Terminal, with base price starting at 20k/yr/license, plus more for extra data. And the UI, when you first use it, is beyond clunky. It looks seriously like a piece of stone age technology, adapted from clay tablets. Even the styling is like 80s films about edgy hackers and their punch cards.
Except when you talk to the grey hairs, you realize that UI has never, ever changed - it is backwards compatible back to, well, stone age of computers. It is quirky, but once you learn it, you're done for life - no refreshed new looks or skins or dark modes (well, it's always in dark mode) or rewrites in Svelte or whatever. That's basically because the power user is essentially the only user that matters. They know all the arcane key bindings and weird abbreviations, and Bloomberg knows better than to mess with it.
I hated it at first but grew to love the stability of it.
Speaking as someone who has never used it but has spent some time researching it, the Bloomberg Terminal constantly undergoes UI changes, though not in a dramatic way. It's obvious if you look at screenshots throughout the time (it even had some gradients!). It has had its own "rewrites in Svelte", transitioning from a custom renderer to HTML/JavaScript.
But you're correct - they don't mess with it, they slightly and mostly invisibly improve it, and someone who learned it in 80s could use it without problems today.
> the Bloomberg Terminal constantly undergoes UI changes, though not in a dramatic way
This is correct. (Source: I worked on Bloomberg's UI change management policies.)
Despite dismissive comments from design industry folks and more modern-looking competitors, the folks who ran Bloomberg's UX team maintained a focus on customer needs and user research. There are even a few cases where function teams went back and re-implemented old "bugs" after a rewrite (e.g. in the MSG editor) because users had adapted to the old behavior. (Thankfully nothing as bad as spacebar heating https://xkcd.com/1172 though)
> and someone who learned it in 80s could use it without problems today.
That's the true dream. Like all of those old movies where the hacker or fighter pilot has to use some foreign, alien or futuristic tech and they just use it!
I worked for an insurance company for a while that was pushing their agents away from 'green screen' terminals to webapps that did most of the same stuff, the agents hated it because they had every step necessary to do quotes and such memorized and were way slower trying to navigate menus on the web.
I just watched a few minutes of someone using it, and I have a few observations.
- Uniform menus everywhere
- Every menu has an ID visible in the corner. Imagine how easy troubleshooting would be if you could just say, I'm on menu 4388 and I'm not getting the result I expect.
- Every selection has a number. Presumably you can type this in rather than mouse over to it?
- Every page has keywords you can string together for instant searching
- No transition animations
This is nice to see: a tool for getting things done, not for nudging the user in a desired direction to satisfy marketing goals.
My parents work for a company using an old system using numeric IDs for menus and screens. It's currently a web app, but it seems to share a good deal of code (and a great deal of philosophy) with the previous, older version, a TUI apparently built in Pascal.
I can confirm that those numeric IDs help A LOT in troubleshooting and documentation. And not only that: those IDs are frequently and naturally used by the users themselves when communicating between them. Needless to say, they also use the IDs to navigate the system, only touching the menus when they have to use some infrequent function.
I always mention this "case study" to UX folks who insist to dumb users down with childish interfaces.
The vast majority of the terminal interface has been rewritten more than once, but the UX framework team does a great job mimicking the prior look and feel each time. Though if you know what to look for you can spot functions that haven't been updated in a while, and even a handful that have remained unchanged since the beginning.
> no refreshed new looks or skins
Basically right, though Launchpad was completely new and PDFU COLORS <GO> provides color themes intended for folks with color-vision deficiency.
Yeah this is a good reminder that technology rewrites do NOT need to rethink the UI. I've always favored updating the technology first to enable faster incremental UI changes afterwards.
I love my UX friends but they almost universally hop on tech updates to rethink everything, and then it muddies up the customer feedback on the rewrite. Was this a tech bug introduced? Or an annoying UX change? etc.
Well, it depends on the audience of your software. Bloomberg Terminal is awesome, but has a steep learning curve. Most people who learn to use it are learning it with the specific intention of finding a job where they are paid to know how to use the Bloomberg Terminal. I agree, the UI is awesome for that, but if your startup is an app to find a dog walker or something, the vast majority of your potential users are going to be turned off by the Bloomberg Terminal interface.
Yeah but even if your app is the new Uber for dogs the goal should still be to let users accomplish their task as fast as possible and not some app engagement metric.
> you realize that UI has never, ever changed - it is backwards compatible back to, well, stone age of computers. It is quirky, but once you learn it, you're done for life
True power users could customize to remove the quirks and also be set for life, but at a better level of ergonomics. Or they could even use the best customization from one of those gray beards who cared about ergonomics more ever back in the day
And none of of the cheap criticisms of skins would change it since skins for power users are optional
You fail to grasp the value of bloomberg terminal.
The UI has in fact, evolved, but it has never changed. For example, higher DPI screen sizes, the UI is now instrumented in a web browser, no longer the the old TUI. It is fast, it is familiar, it's the same, but it evolves, if that makes sense.
If you know how to use it in company A in decade 1980, you know how to use it in company B today. That doesn't mean it hasn't improved or improved ergonomics.
It's a beautiful piece of engineering that got the basics right. Power users add whatever they need to it, modular, but it's not like Vim or VSCode where you are basically useless without a large effort when moving into a blank new updated version, let alone things like the ribbon design vs the old design in office.
It's the other way around, the value of that terminal is in the information, not whatever hated UI quirks it had been stuck with since its inception, yet people keep falling for that old logic "old+expensive = great".
> it's the same, but it evolves, if that makes sense.
it doesn't, these are the opposite.
> If you know how to use it in company A in decade 1980, you know how to use it in company B today. That doesn't mean it hasn't improved or improved ergonomics.
Neither does this: it would be just as trivial to select at company B "use config ergonomic_grey_beard_1980" and continue with all your knowledge, just without those quirks you hated in 1980 that led you to change the stable defaults to a better config.
> but it's not like Vim
And in some sense in the relevant UI area it's exactly like Vim, where many bad quirks in the default config are praised by the grey beards and new converts alike.
> moving into a blank new updated version
Why would you do that instead of using your old config???
> the ribbon design vs the old design
Neither is forcing a change like this the only alternative
I think to me that would be the appeal of Vim. VSCode implicitly promises this with its plugin approach. Using Ctrl Shift P for years is the sort of thing I like. One less thing in my way.
I'd never noticed that ctrl-shift-p was a thing. In gvim ctrl-p moves up a line but ctrl-shift-p seems to do page up. Do you know if this is documented anywhere?
It's not just about 'UX backward compatibility', it's the epitome of an expert user interface. If you don't know what you're doing it's near unusable but once you've mastered it the speed at which you can operate is incomparable to 'normal' software. It's also one of the few examples of this outside of software engineering tools.
At all times, people that are proficient at a green screen terminal application will prefer it to a web based or GUI based experience. They have muscle memory and a lot of codes memorized to switch back and forth from screen to screen extremely fast and exactly how many tabs to hit to fill out a form. It has nothing to do with SPA or whatever is currently new and flashy this has been going on for decades. The fact they have to remove their hand from keyboard to mouse pretty frequently is the biggest productivity loss, then drop down boxes and forms that aren’t very keyboard friendly and the page render times are incredibly slow in comparison.
I myself made this complaint a few times. When I was using medical erp once then again using a banking system. Both you could navigate by typing a chain of commands that would register even if you typed faster than the screens would render in the terminal. Hell, in the banking one I completely automated my job by writing an excel macro and sendkey commands to the terminal, then I sold it to the bank for a small sum after I quit (they asked me how I accomplished so much after realizing 3 people couldn’t handle my workload)
> Both you could navigate by typing a chain of commands that would register even if you typed faster than the screens would render in the terminal.
Nowadays even the login screen in Windows can not manage it anymore. Gotta wait for some animation and whatever it needs coming back from sleep mode before it starts registering keys.
You could still do this in the GUIs of 25 years ago, you'd just memorize the keyboard shortcuts and use them. They'd buffer so you could type a series of operations faster than the screen could render them, and basically every function was accessible from the keyboard. But the GUI had the advantage of discoverability - if you didn't know the keyboard shortcut, you could just work your way through the menus and find it.
While possible, the uptake/usage is very low once it requires lots of CTRL / ALT / CMD button sequences. Take something like Excel, which many users use daily for work, but most people likely only use less than a dozen common keyboard shortcuts. Practically nobody navigates the ribbon with their keyboard.
I'm in a role of Finance / Excel "super user" in my profession. There's a subculture of keyboard shortcut enthusiasts, but generally everyone is using their mouse a lot. I myself have about 20 that I use and rarely incorporate a new one into the mix, it has to be an action I perform repetitively for me to care enough to memorize seek out and learn the shortcut. I find navigating the ribbon usually requires too many keypresses and I instead have a custom quick access bar that I put everything I want access to so I don't have to toggle differing ribbons, I still use my mouse even though I know I could use my keyboard. It doesn't feel easier
But it’s true that the menu systems often made the accelerations and afterthought, and regularly used functions for some people had no shortcuts and no way to set them.
I still think a World of Warcraft style action bar, user configurable and multilayered, would work just fine for power users. You can put anything you want in position eight but most people have the same things set for 1-5.
> This might be okay for consumer apps, but maddeningly, the same doctrine gets applied to enterprise applications as well. I've literally heard non-techie employees of a Fortune 100 company ask for their legacy green screen terminals back because the new, flashy SPA was slowing them down.
Applying general design principles without taking actual use cases into account is the worst.
A common one is putting heaps of whitespace around each cells in a table. Visually appealing, sure. But unusable if I need to look at more than 8 rows at the same time.
Agreed. Most user experience work today are done by people who ironically have little experience as a user. E.g. they will design a table in Figma, make it look nice. They may even go so far as understand that this table will typically contain 2500 rows and introduce pagination and filtering by most commonly used attributes. But if they load some sample data into a functional mock system and simulate a typical user's day (e.g. they have to wade through this table multiple times per hour, while on the phone with a customer), they will immediately realize the feel good factor of white spaces, pastel colours and high contrast icons are very low priority.
You forgot one awesome feature of those SPA: once your user finally manage to get some muscle memory in, you can push a new UI redesign so get them back to square one. Because you have to give work to do to your frontend people.
> Most user experience work today are done by people who ironically have little experience as a user
So many upvotes for this. While the provided thing might technically work, if it is clunky for the users, the users will not like it. I understand those making the thing will probably never use the thing. The problem comes when those making do not listen to those using. There have been many times where I've made the thing, but then when I went to use the thing I wanted nasty things to happen to the person that made it. I've been in some very contentious UAT rounds where I was the user and the devs refused to listen to valid complaints.
The funny thing is that a lot of those problems are known during development time, by the people who have to actually "use" the product at all times during development, a.k.a. the developers.
Not sure I follow. The situations I've built appear fine during testing during development. I go to the UI, click the buttons, get the correct result. Test complete.
The type of thing I'm thinking about is when the user does that many many times in a day, but to get to the button that is on one part of the screen which is very inefficient compared to if the button was moved closer to something else so that the UX is improved. Sure, what the dev did "worked", but it might not feel clunky when you test it once or twice. That's the difference that drives most UX<=>Dev disagreements.
Dev: but it works
User: yes, but it sux using it. it can be better for us if change X, Y, Z
Dev: but it works. ticket closed
It doesn't matter if it works while everyone hates using it. I don't care what the devs think. If the user's request is reasonable, rational, and will improve the UX, stop fighting it. This situation is precisely my experience that happens when there's no designer.
I'm talking about bad designs. Grandparent mentions Figma, this is who I'm talking about.
Developers have to work on the app the whole day and they know when a design is bad for long term usage. Either by doing manual testing, or even when automating it.
UX people dictating the designs will rely on instinct even when developers complain that a design is inefficient. Or even for visual design things like excessive padding getting in the way of making the apple useable. IME, YMMV.
If you're talking about inexperienced/unemphatic developers being in charge of UX alone: well, yeah, that will happen too.
Reading about whitespace on tables infuriates me so much.
At a previous job we had an actual good designer figure out what users wanted and she found out users wanted denser information. So she designed a more compact table. It was quite smart, used the whole screen, but still looked amazing and didn't feel cramped.
Then my company released it as a library for the whole company to use and the first thing one of the product managers did was requesting margins AND frames around it, plus a lot of whitespace between cells.
Now instead of displaying around 25 items on the screen at a given time, this other system can only display around 10.
The cherry on top: it looks horrible with the frame and with the unbalanced margins.
I agree with this, so much so that I wrote a long essay about this
Modern web design has completely lost the design idioms that so much thought went into during the desktop software wave of the 90s and early 2000s. This is a great loss for usability.
With that said, the design sins it commits are pretty standard in the age of minimalist/flat UI. It looks pretty similar to Apple's current design language, just with some stylistic tweaks.
Not defending it, as some of those design decisions drive me up a wall. Is this text a button or just an input field? Can I click this image or is it static? Which directions can I swipe? Does this grey text mean it's a disabled button or placeholder text on an input field?
I am not nostalgic for the blocky, grey, in-your-face design of classic UIs like Windows 98. But sacrificing functionality and discoverability on the alter of pretty design is, unironically, bad design.
> To me, peak usability was 25 years ago, when most applications had a toolbar and a menu that followed a standard pattern.
Some things were good, but there were lots of problems too like features hidden behind right-clicks, not knowing if you had to double or single click, being required to read help/manuals to find features, too much jargon and technical language, and overuse of modals.
UIs have got incrementally better in lots of ways that really add up that I don't see people mention e.g. right-clicking and double-clicking is avoided, help is integrated into the UI where you need it, inline editing vs modals, options to edit an object appear next to it (locality) rather than you having to hunt in a menu, less technical jargon where appropriate, better onboarding, better undo/redo/autosave (which avoids clunky confirmation modals).
> Some things were good, but there were lots of problems too like features hidden behind right-clicks, not knowing if you had to double or single click, being required to read help/manuals to find features, too much jargon and technical language, and overuse of modals.
I dunno… all of these issues are still very prevalent. The one that probably disappeared the most is the right click context menu, which I would argue was actually great for discoverability. Personally, I lament its demise. Of course context menus still exist, but it used to be a pretty reliable universal convention.
Right-click is fine for power users and professional tools if there isn't a better alternative, but right-click (and long tap on mobile) is super undiscoverable because there's no indication or hint it'll do anything.
Whenever I help non-tech friends with software problems, I'm always reminded most people don't feel comfortable hunting around for functionality and for sure don't try right-clicking things on the chance it might do something.
I know what you mean, but my point is, if you have a strong convention that right click
a) never actually runs anything, so you can’t accidentally break stuff
and
b) usually shows contextually relevant actions
That makes for great discoverability, actually. Discoverabilty is mostly a measure of how confidently one can dick around without causing accidents (and being able to undo them easily).
Your point about there being to indication whether something is clickable or not applies to left clicks just as well, and this also used to be less of a problem before everyone rolled their own, usually very flat, designs. You could teach someone basic principles and they’d be widely applicable. These days you’d have to start with a full lecture on the differences between web apps and “native” apps and natively packaged web apps…
I wonder if it took the shinier, less conventional UIs to get all these “non-tech” people to use computers in the first place. A dilemma, because they would benefit from boring conventions the most.
> right-click (and long tap on mobile) is super undiscoverable because there's no indication or hint it'll do anything.
I really miss the days where it was common for tap-holding on any control to show a description of what it is. It may still be common in certain Android apps but I haven't seen it or anything like it on iOS.
> Hmm, haven't seen this. Where do you need that? What kind of description that wouldn't be obvious from looking at the control?
I most commonly see and also appreciate being able to tap-hold on icon-only buttons to learn the text label that the icon represents. I can usually guess what most icons mean, but sometimes it's not entirely obvious.
The root cause is that web browsers were designed for document delivery but are used for building application UIs. The browsers don’t offer a standard set of common application UI components, so every team builds their own leading to inconsistency and half baked implementations.
In contrast, when you build a native app, developers can draw on a standard set of OS provided UI widgets.
I think the root cause goes deeper than that, and has to do with economic incentives. Up through the 90s, the predominant business model was you sell a product, people use it to get work done, if they're happy they tell their friends and you sell more product. Starting in the 00s, the business model became you give a service away for free, get people hooked, make them so dependent upon it that they can't look away, and then either jack up prices to extort as much money from them as possible, sell advertisements so that other people can do the same, or sell their personal data so that other people can target them with sales pitches. Actually getting any work done became secondary to making the transaction happen. This applies just as much to enterprise software as consumer software, because the purchaser of enterprise software is usually some IT department, purchasing department, or executive who doesn't have to actually use the software, and they will probably move on to the next company before the consequences of their purchasing decision being useless become visible.
We are reaping the consequences of that now, where lots of transactions are happening that don't actually make anyone happy or productive.
But you can see how that would filter down into UI design. When your incentive is to make people happy and productive, you spend time studying how people actually use the product, and then optimize that so they can use the product more efficiently. When your incentive is to turn people into mindless consumers that keep coming back for more ads, you spend time studying what sort of content holds the user's attention, and then optimize that so you can work as many ads into the stream as possible without them turning away. When your incentive is to sell enterprise software, you spend time studying what sales pitches will get the budget-holder to open their company's wallets, and then optimize the sales funnel to the extent of actual product usability. Even if your users hate you, they don't get to decide whether they keep using you.
Developers always had the flexibility to create custom UI elements/colors etc even in native apps (albeit not as easily as using CSS). Even in SPAs, most UI elements follow the same style or pattern more or less (bootstrap/tailwind etc). It's the entire UI design itself that's not user friendly for enterprise/business apps (excessive padding, comically large UI elements etc).
Wouldn't say it's the root cause, but it is a major cause. I have some experience developing desktop applications using Visual C++ / MFC in the early 2000's. I still prefer that development experience to modern React/Redux SPA development.
OS widget libraries aren't always big enough to solve all problems. On the web, there are many frameworks that provide widgets for typical use cases.
But even if you have a library with hundreds of widgets, you can still make a terrible UX if you don't understand good design, and many programmers don't.
In my experience most designers don't know what UX is. They think their job is to make it look pretty. If it needs 3x more clicks to do the same thing as before so be it.
There's more consistency in UIs on the web than desktop IMO
People have less power on the web so it has more limitations, even if it lacks a number of consistent UI components baked in.Desktop apps are notorious for getting fancy. Even simple control apps from random headphones/keyboards/music gear/etc all want to reinvent the settings page and make it 'sleek' instead of usable.
And controls were demarcated as controls, not disguised as plan text or a decoration. You could tell if a function was activated by looking at the outline of the button; if the "bevel" shadowing went inward, the button was depressed and the function was on.
"Flat" design is simply derelict design. Fortunately there has been some backlash and we might be returning to legitimate GUIs.
Good old times :) I miss F1 help, which was usually very good and contextual. On a Settings dialog? Press F1 to view help just for that dialog - offline, instant.
For me, Norton Commander specifically, among other TUIs, was very influential in shaping my keyboard shortcut preferences. I used to rely heavily on Function keys; both for lightning fast file management, and also for code navigation and debugging.
One definite UX improvement over the past 25 years have been command menus. In the most simple implementation, press Ctrl+P start typing to filter a list of commands down and hit enter.
True. The UI of the applications from the late 90s to the early 2000s was way better than it is now - especially when you compare it to what is there in the web apps now.
Besides keyboard shortcuts, the following capabilities haven't really been implemented in web apps:
- Context menus
- Macros and the ability to record macros and create your own shortcuts to these macros.
- Terminal prompts built into applications such as in Autodesk - in some senses similar to the REPL in Clojure but built into the application
those menus started to slip a long time ago. they got larger, less organized, and got lazier about mentioning the keyboard shortcut. the new MS paint does a good blend of that style and a newer look
the current text editor trend of having a "command palette" is pretty nice. it's got a hard job to do, with the sheer number of commands and extensibility to add more, but search is pretty good for discoverability (as long as people name/tag/describe the commands well)
Exactly the reason I still write most of my code in emacs. I’ll use visual studio when I need to do GUI work, but I feel like I’m at a casino with a thousand flashing lights all vying for my attention. I also find swapping back and forth between keyboard and mouse to be a slowdown. I know some of the VS keyboard shortcuts but find many of them to be more convoluted than emacs (and I won’t even comment on the VS faux emacs bindings!)
Luckily I spend a lot of time building libraries, where I can keep my hands on the keyboard and focus on the problems I am trying to solve
Ok well a lot of that UX depends on hover states and right clicks that don't exist for touch screens. Key bindings? What keys?
That's the major reason we dont have the same toolbars. We can be cynical about engagement and free software but try to make a mobile app the old way. You can't.
Yes, uxers have to balance business and user needs. That is the power dynamic of business we live in, it’s not typically the driving force of actual uxers themselves.
At the core the ethos of the human centered design (HCD) is being an advocate for the needs of actual users. Being seen as the ”enemy” on HN feels demoralizing, as a person that sits on both sides of the fence.
I feel gladness about seeing the truth of my experience about this. I would like there to be more camaraderie between uxers and developers, and of course it being a more common scenario to be able to drive a genuinely shared vision also with business leadership.
If you have a source for ”modern ux doctrine”, i’d love to hear about it to have an actual discourse.
The UX designer doesn’t have absolute authority. Typically, they need approval from PMs and other stakeholders, which is where the need for compromise comes in.
> Modern UX doctrine aims for the opposite goal -- to keep people "engaged" as much as possible.
In many larger orgs, usually design doesn’t work in isolation. Some of these goals like engagement, retention come from senior leaders of different functions. The design proposals are evaluated and signed off against these goals.
However, when these designs and flows appear on platforms like Mobbin, they often lack context about their design rationale. This can create a network effect where other designers replicate similar designs for their own experiences without fully understanding the underlying reasoning.
The problem here is the fact that the expected cost of software has become zero. 25 years ago most productivity apps would charge money. There might be a free trial but you need to pay for it. These days most expect software to be free of charge. A lot of the regression in software quality and usability can be traced back to this.
> This might be okay for consumer apps, but maddeningly, the same doctrine gets applied to enterprise applications as well
I think this is a great point. I was consulting with a customer and their key goal in a complex system that had a time-sensitive user workflow was "minimise clicks".
I said to them that that makes sense, but saving 0.5s on a click every two hours is not as impactful as (insert example of a change that would speed up the workflow by 10 minutes every two hours).
And it's as you say: they come from the consumer world, where minimising clicks keeps customers involved. But it's not the only thing to consider.
The most obvious change that happens after hiring a graphic designer is that the app/website stops looking like shit, and adopts a pleasing color palette and set of fonts. There is real value in this, and the median graphic designer definitely chooses these better than the median engineer.
But UX is a broader umbrella which encompasses interaction flows at the large end, and single function widgets at the small end. For whatever reason, the median human is very bad at predicting the overall UX of a system. It's rare that you have someone who can look at a spec for a system they've never seen before and accurately predict what will be easy to use vs. hard to use. Graphic designers are not meaningfully better at this vs. engineers either, it's just uncommon.
For that reason, UX is usually developed by copying existing solutions, or using the guess and check method to try out novel things. It's very difficult to create good UX by design because evaluating the system by imagination is much harder than with an implementation. Contrast this to backend system design where entire categories of error can be predicted and avoided through basic principles and reasoning.
Where this can go wrong is when you think that you can hire for something which is actually rare in the talent pool. If you have a graphic designer or engineer who has demonstrated an excellent gut feel for UX, then that's incredibly valuable. But you can't wait around to find such a person, or pretend that you will be able to hire someone like that.
> It's very difficult to create good UX by design because evaluating the system by imagination is much harder than with an implementation.
This is precisely why it’s a tragedy that the roles in software development have become so compartmentalized. It wasn’t that long ago that the same person designing an interface was also responsible for developing it. Or that design and development were one and the same, part of the same process.
These days, many “UX designers”, “UI designers”, and “product designers” have never written a line of code. Some even have an allergic response to the very idea of coding. That’s fine, but naturally it means there’s a wide gap in understanding between design and implementation. This leads to the UI equivalent of the dreaded Architecture Astronaut[1]—so disconnected from the reality of how software works and is built that they design absurd interfaces that look great in Figma but fail miserably when put into practice.
In my experience, the closer you are to the implementation—and by this I mean the more involved you are in the actual coding—the tighter the feedback loop on the quality of the user experience. It affords the sanding and polishing required for a great UI with a great experience. Some of the very best interfaces that I’ve seen and used, both in terms of quality user experience and visual design, were designed and built by those rare engineers that happen to have outstanding intuition and taste for great design. The worst UIs I’ve used are from designers that don’t code handed over to engineers with no design taste.
To me, "UX" still feels like a relatively new term. In its modern incarnation it's not what I do, although by intent it's actually my career speciality. As a category now, it feels like a poor compromise between true design and true code/userflow. I believe the existing tools try to bridge a gap that has existed since the earliest days of web development between the designers and the code monkeys.
I'm fortunate as a solo coder to have a very tight feedback loop with my own graphic design, but I wouldn't have it any other way. I started writing code making text-based games as a kid in the 80s, then became obsessed with graphic design, went to art school, worked as a designer at a traditional ad agency which had no coders... and because of my code competency became the go-to person for making web. And later apps. So I still currently art direct designers and also write the majority of code for clients. This lets me understand the flow first and then unify the design in ways that aren't prefab or obvious, but ensure user safety and flow in a beautiful way.
I think the tools now (Figma, yes, but also the reliance on standard use cases of frameworks like React) are very limiting. They shoehorn both designers and coders into an uncomfortable middle ground that's not too different from the arguments that used to erupt between designers and the couple of devs at my ad agency in the 90s - we want it to look like THIS vs. Do you know how impossible that is? So everyone settles on a crappy solution instead of sitting down and thinking about how to make something new and better for the situation.
Honestly, Flash was so great because it allowed both sides of a team to use both sides of their brain at the same time, and cross-pollinate design with code in a way that seems hopelessly lost now, at least for normal business apps outside of game development.
There aren't so many cases where business-y or banking software needs to be beautiful, but it could at least be thought through. I look at my banks' apps and sites and slap my face at the obvious miscommunication and sheer carelessness that must have taken place between management, design, and code to produce these monstrosities.
But would I want to be on the open market, looking for new clients with my cross-disciplinary background as a "UX" person? No. What they need aren't UX people. They need art directors who can at least write some code, or (even more rare) coders who have formal design training.
I think the reason UX moved into its own realm (like "UX designer") is to create the processes to get actual UX expertise.
Without deliberate UX expertise, you're on the hook for having UI implementers (software engineers) who happen to be good at UX, and that's not a great way to go about ensuring that you have good UX because you're reliant on serendipity.
And of course once UX becomes its own prong that you're trying to optimize for, the simplest thing to do is create UX positions in your company. Which is much simpler than figuring out how to hire software engineers with UX expertise or good intuitions.
Just consider how few hiring processes involve someone clicking into your github projects and evaluating them just to see what kind of code you write. That's much harder than doing a canned leetcode or canned questions interview.
This isn't just a software thing... all of corporate america has compartmentalized and while the results in churning out widgets are actually very good, the results in practically everything else are bad bad bad. Even in finance, Warren Buffett will preach that investing is not a team sport - you need all the details in one head.
> These days, many “UX designers”, “UI designers”, and “product designers” have never written a line of code.
Same for some "architects". They just draw up random system designs that don't work for THEIR environment.
> This is precisely why it’s a tragedy that the roles in software development have become so compartmentalized.
The worse part of it all is it's not the software engineer's fault either (most of the time). HR, managers and others haven't improved over time and instead are enforcing non-software values on the engineers. It's all about ticking boxes. You get classified as a Go REST API backend engineer and somehow you can't touch React because that's not your thing.
Yet everything remotely serious built with React has gotten worse and worse... and apparently the project managers who rely in it and the coders who are used to its obviously major flaws can't think their way out of the wet paper bag that it's become, and see clear to writing a component from scratch. REST, sockets, whatever; the issue isn't how you send data over the wire, push it pull it or when. The issue is: Is what you're doing appropriate for the situation? My bank has started using something like React to show live stock prices in trashy grids. Guess what: That is a horrible idea because it's always wrong in some part of the screen. Let me reload if I have to, or else engineer something actually realtime.
They use these technologies because the recent grads who know how to use them are cheap and replaceable and the assumption is that the tech is uniform enough to make the coders hot-swappable. The product is enshittified garbage, but the managers don't care.
What is it exactly about React specifically (as apposed to Vue, HTML) that makes it flawed from a design perspective? I used to design and develop with Flash (which I very much miss) and while it was amazing for things like games, digital signage, elearning, etc, there is no way I could develop in Flash the products with the kind of complexity/responsiveness/sophistication of the web apps I am building now. Designing with hot reloading and code, live, is by far the most powerful and iterative design workflow I have ever experienced. While an inexperienced front-end developer may limit their design possibilities by only reaching for existing components, a good front end developer should be able to create bespoke components that are fit for purpose and responsive with the flexibility to rearrange and iterate.
With all that said though, there is a HUGE gap that Flash left for highly bespoke and creative products that web tech doesn’t satisfy at all.
> What is it exactly about React specifically (as apposed to Vue, HTML) that makes it flawed from a design perspective?
I'd say it's not React (not parent poster). I mean React might not be the best, but it's the least of the current problems.
React is the most widely used. You're bound to attract all sorts of people. Poor code is poor code. You'd hire React developers because it is the easiest to hire. It doesn't make it good or bad.
There's nothing really fundamentally wrong with React that makes it a terrible idea that always results in poor performance. It's shoddy development practices that can make for a bad app that uses React. If you use React well though, it's not like React makes it particularly difficult to reach a good level of performance. I typically find that React makes it easier for me to make a well-performing app, but that's just me.
I don't think it's even React itself that's the root cause the performance problems, it's using the data store badly (Redux or Mobx or even the new ones like Zustand and Valtio) that either causes components to rerender too often or causes too many components to rerender.
Having been bitten by this a few times, I'm paying a lot more attention to how my team uses it in the React app we're building from scratch right now, keeping an eye of how it's used and looking for problems before they become noticeable. I am, for example, inverting one of the common practices which I found was a cause of these performance problems:
"Atomic Design" with React splits components into different types - Atom, Molecule, Organism, Section/Template, Page. Each type of component is mainly composed of the smaller ones. It's generally suggested that Atoms and Molecules should be functional style and reusable, so not connected to the data store at all. Instead, Organism and up are the ones that manipulate data and pass things down into Molecules and Atoms to render. The problem here is that any update that triggers an Organism to rerender will also rerender all the Atoms and Molecules in it, even the ones that don't actually need to update (in the class-based component days we had shouldComponentUpdate() to avoid this, nowadays we have useMemo()/React.memo - neither of which we used with any consistency because of the extra effort).
Instead, while we do have a company-wide library of Atom-like elements we're using, the Atoms and Molecules inside the app are "smart" - they take a prop or two for configuration, then use that in combination with the data store to handle the data manipulation directly. Organism-level components then don't do any data wrangling and are just laying out what Molecules go where. This means when manipulating a Molecule, only that Molecule and any others looking at the same data need to rerender. The Organism and other Molecules in the same Organism are completely unaffected, not even trying to rerender and no need for React.memo to prevent it.
(Aside, to avoid confusion in the current app I haven't introduced the Atom/Molecule/Organism naming convention, and am instead using more semantic app-specific names for organizing components)
We still have a ways to go but we've already implemented the specific part I expected to cause the most problems here, and so far it's been great, the latency is so low it doesn't feel like a React app in the way I've come to expect, and there's much less manual manipulation of the data in the components themselves.
> I don't think it's even React itself that's the root cause the performance problems, it's using the data store badly (Redux or Mobx or even the new ones like Zustand and Valtio) that either causes components to rerender too often or causes too many components to rerender.
Like I said, it's shoddy development practices. I've seen apps that use one of those mutable object libraries (not any of the ones you listed) and just pass the objects everywhere. Whole app re-render on any state update because of how all of the state is nested inside these mutable mega-variables held by the root of the component tree. I try to chip away at the innermost components and create little havens that use immutable state as they should, but it's going to take years to redo the whole app that way, especially since refactoring isn't a priority yet.
By the way, a cool trick if a component you're using does not use `React.memo` is to memoize the element, because if React sees the exact same (reference-equal) element as the last render, it will not re-render the corresponding component tree. (Element refers to the return type of JSX expressions.) Obviously, only do this if it actually doesn't need to re-render.
Nobody is suggesting adding this responsibility to developers, but what actually happened was that developers who can design are almost forbidden from doing so, unless they are in positions of power.
Some of us have lost our voice when it comes to design.
You just perfectly laid out why it's simultaneously difficult to find a new job in UX while getting paid well once you do find a job (if you're good).
Those who understand what good UX is and how it manifests itself, value it highly, while many (even in tech) still consider it pixel-pushing and "pretty colors".
Or you know.. talk to users and understand their needs (discovery) then design solutions based off that understanding and iterate on designs with usability testing with said users until it feels like magic to them using it the first time, smooth and seamless flows across use cases with good copy and accessibility.
You share the screen with Gemini, and tell it (using your voice) what you are trying to do. Gemini will look at your UI and try to figure out how to accomplish the task, then tell you (using its voice) what to click.
If Gemini can't figure it out you have usability issues. Now you know what to fix!
A real user will be worse … but that’s kinda the point.
The most valuable thing you learn in usability/research is not if your experience works, but the way it’ll be misinterpreted, abused, and bent to do things it wasn’t designed to.
You seem to disagree. Here's an interesting study where the researchers used an OpenAI-LLM-based tool to grade student papers and by grading them 10 times in a row, they got vastly different results:
Quote: "The results reveal significant shortcomings: The tool’s numerical grades and qualitative feedback are often random and do not improve even when its suggestions are incorporated."
> If every product in your space does something the same way, there’s probably a good reason. If one company does something different, ask yourself: Is this intentional, or just a mistake?
To add to this, often you can come up with a lower friction UI idea for your specific use case (e.g. that requires less clicks) if you think hard about it, but if you stray too far from what people are used to seeing and interacting with it creates its own kind of friction, and you'll get feedback like "I found this unintuitive" or "it took me a moment to figure out how to use it". So you need to balance using familiar patterns vs new ideas.
E.g. maybe you think you can improve on the Amazon checkout experience for your own site, but by doing something different, you're tossing out the familiarity bonus you get for free. Similarly, by preferring checkboxes, radio buttons, dropdowns and text fields, over custom widgets, you get so much for free like user familiarity in reading the current state, and knowing how to change the state.
"Unintuitive" can often mean "I'm not used to this pattern" even if it might be a good pattern once people get used to it.
"Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know."
"1. Users will transfer expectations they have built around one familiar product to another that appears similar."
"2. By leveraging existing mental models, we can create superior user experiences in which the users can focus on their tasks rather than on learning new models."
"3. When making changes, minimize discord by empowering users to continue using a familiar version for a limited time."
There's an enormous difference between HCI and UX.
HCI relates to computer usability for general use cases. A CAD program is there to help you get tasks done, not waste your time, so must follow general HCI principles.
UX is watered down HCI that takes business considerations into account. Think about how Microsoft jams a Copilot button into everything, all the way down to the blinking cursor. That doesn't help users (and it is not removable), but it helps Microsoft claim it added 100+ million Copilot users.
The UX of Facebook is a huge mess, a never-ending, non-chronological scroll of dopamine slot machines. HCI considerations would posit that going back to the algo-free, chronological version would help users "get what they want" faster. But helping users complete tasks faster hurts how much FB can charge advertisers for your attention.
> The UX of Facebook is a huge mess, a never-ending, non-chronological scroll of dopamine slot machines.
This is not really relevant to the discussion of the content of the post: "do what others are doing, do what your users are already used to doing"
Whether Facebook's content is good or bad is not really relevant; the UX of FB, Twitter, LinkedIn, and almost every other social media app is remarkably similar in layout and function.
Yes, but not because of a self-proclaimed "law". The UX is similar across FB, Twitter and LinkedIN, because they all sell ads, and what you can charge for ads is reliant on how much time people are spending on the platform.
Laws in these cases are never self proclaimed; they are simply made from observations. This is not a law in a legal term; it's a law because through observation, there is a universal truth to it.
I recommend focusing on general design principles and mindset.
- Read "The Design of Everyday Things" by Donald Norman - once you understand what makes a good (or bad) door handle, you'll start seeing design patterns everywhere.
- Read "The Art of Game Design" by Jesse Schell. It discusses how to create engaging experiences, and games are particularly unforgiving. While people might tolerate an annoying tax app because they have to use it, they'll immediately abandon a game that's even slightly too frustrating, confusing, or boring.
Be warned: reading "The Design of Everyday Things" will make you incredibly frustrated at hotel doors, light switches in your house, kitchen appliances, and many other daily interactions with objects - once you realize that best practices to make them usable have existed for 40 years and designers still can't be arsed to make a restroom faucet you can understand on the first try.
Doing something because all the big companies do it also leads to cargo cult mentality. You should know exactly why you are building every little part of your system. “Oh Google used a really annoying captcha on that page, I better do that as Google knows best”.
Have some confidence and don’t assume that other bigger companies are smarter than you are, think about what you can improve. Most of what Google have to offer, they bought from smaller companies that had the confidence to do just this.
Especially when the signup form almost looks like a login form username and single password field ... then you get an error "An account with this email already exists" and STILL NO LOGIN LINK.
Big companies aren’t usually that good at design (with some notable exceptions like Apple) because they don’t really have to be. They don’t need to impress anyone or prove their credibility, and they almost by definition have a product that people have a strong need or desire for, otherwise they wouldn’t be a big company.
When you have that, it probably doesn’t make much difference if you add some extra friction to your sign up flows or your UI is a bit janky.
When you’re the new guy who no one has heard of: that’s when you need design. You need to catch people’s attention, win their trust, and make it as easy as possible for them to get to the aha moment, because any minor inconvenience can be an excuse to close the tab of yet another random app and move on.
All that to say, startups often lean heavily on design to stand out from the crowd, so if I’m looking for good design and UX to emulate, I look for startups that are still small but gaining in popularity, whether bootstrapped or seed/series A. That’s typically where you find the best practices being implemented to a high bar. Once they get too successful, complacency and other priorities start to kick in and they are no longer the best examples to follow.
> You should know exactly why you are building every little part of your system.
As a UX designer/researcher who focuses on exploring novel interfaces, if every company rethought their UI from scratch that would be great for my job security. But realistically there are good reasons why most companies default to following established UI conventions:
First, your users generally have significantly more experience using products from big companies than yours, and differences are often perceved as problems. See Jakob's law.
Second, sometimes a company that releases a novel solution does fantastically well. But more often than not it ends up being a lesson in why the convention existed in the first place. See Chesterton's fence.
Third, unless you want to make the UI a differentiating factor for your product then any time you spend iterating on novel interfaces is time you could have been spending on your company's core competencies. See... I dunno, Seth Godin, basically any startup blogger?
Understanding exactly why before applying is not bad advice. But it takes time and can quickly become impractical when you're already pressed for it (like say, a small team startup already lacking a designer). In many cases it's better to just copy the closest thing to what you aspire to become, even if you don't quite yet grasp the details of why they originally made those decisions. All that can be figured out later for your own situation.
I learned this after many attempts early in my career to copy what the MS conferences were talking about.
The thing is that what a big company do can be good (in fact MS was fine back then!) but are problems for big companies, and have issues that you don't need to copy, worse: copy without knowing. For example, microservices, horizontal scalability, massive telemetry to cover all, etc are problems yo don't want to get.
What it works much better, is to copy a small/medium player that is very well regarded. Like for example, think in panic, vlc, etc. Small/medium players that have good reputation need make more effort than big players, and are on top of the good things by necessity.
Yeah. I like to think about why something is the way it is. If they are trying to accomplish something similar to me, then copy away. But if their circumstances and objectives are different…
The article writer is talking about if many companies do it there’s probably a reason for it, with UX and as an example things like email buttons, etc.
A strong but unspoken rule when anyone gives you advice is (and I feel like not everyone knows this anymore so this bears repeating): use your critical thinking skills to decide if the advice is applicable and appropriate for your situation.
Surviving without a designer? More life thriving without one.
Honestly I think many startups at an early stage don’t need designers at all and they just want to look trendy (which admittedly is critical for consumer-focused companies that live and die on becoming trendy, but that’s not what I do).
The best designer for an early stage startup these days is someone with not awful visual/UX taste (no need for a specialist or a visual prodigy; most teams I’ve met have at least somebody who isn’t hopeless in this respect); but with a strong understanding of their target users and what they’re familiar with, so you can just copy prior art as is relevant. Much better than taking a designer who knows nothing about the space and needing to transfer your learned experience into their brain somehow.
Most startups aren’t doing anything truly novel from a UI standpoint so why reinvent the wheel? Designers become more useful when you stop having strong communication and trust in your team since it just got too big for that.
From experience I will say that you can hire a UX designer even if bootstrapped and low on cash, and that it's a very valuable investment.
Just don't hire them full time as the article seems to suggest is the only choice.
Getting a small firm to go through a design sprint with you with, e.g. designing 3 concepts, letting you run a couple of UX workshops with your potential users, then picking one of the options to flesh out into a clickable prototype, then workshop again, then final prototype, can come out within a $5k-$10k budget.
That's 100% worth cutting $5k from your front-end dev budget, and will definitely translate into way more than $5k in user retention gains within the first year.
This is what we did before coding the MVP, and we're doing it again now (at Seed stage) before shipping our biggest upgrade to the product.
Here’s some typical reasons why a startup can fail:
1) it failed to communicate and market it’s product
2) it’s product didn’t fit the user’s needs
3) it’s technology strategy made development too expensive
4) it’s product technical quality was too low
5) it’s product did not look appealing to potential new users
Developers are responsible for 3 and 4, sales and marketing for 1 and finally designers for 2 and 5.
With competent developers you can start a startup and make sure 3 and 4 never come to pass, but lack of good product designer will eventually kill it.
Here I use the broader sense of user-centered designer, which includes:
- research
- testing
- prototyping
- validation
- UI/UX design
- visual design
- …
The first four being the most important for a product market fit.
This is especially important for B2B products, because there understanding the needs of the business and their processes is key to making sure the product fits the user’s day-to-day work but the businesses’ future needs as well.
It may not be common, but you can and should use extended UCD research methods on the customer business processes itself instead of relying on PMs and sales just asking customer’s what they want. (This is often called Business Design or Service Design around here.)
My most successful client (a company I have ownership in, now) has another slot besides marketing, design and code. That is our point person for filtering, testing and verifying user experience issues. Putting a single point person in charge of that onslaught of emails, who fully understands the software, and having them run a full time bug reporting/feature request channel, I think, is indispensible. They advocate on behalf of users but also know when the requests are silly or something is user error. They know whether an issue is mainly design or mainly code. Having them in place and engaging daily with users means we can filter out 90% of the noise in the signal. But it needs to be coupled with open-mindedness to customer feedback from the earliest iterations. Whatever requests or issues come through that person must be addressed. That person should understand what they can and cannot promise customers, what is crucial vs what is fluff, and how to prioritize those requests.
Her official role is "General Manager" but in fact she was promoted from a customer service role and the position was created for her because she was so good at spending extra time off-hours writing detailed, reproducible bug reports on behalf of customers who had experienced some issue. Reproducing and screenshotting the flow and the issues herself.
This person is a 10x force multiplier by virtue of being a power-user of the software who also interacts with customers and management daily, although she has no code or design experience.
True. When the complexity of the software causes lot of usability issues in ”edge cases”, these technically capable customer connected people are really worth it.
I’ve also seen good things coming from hiring actual ex-users from potential customers that were using competitor’s products. They’d do user training, customer software configuration and development team support. Sometimes even full time.
-
But these people are good day-to-day at ironing out the details. Maybe even discovering underlying dissatisfaction with the product.
But the startup’s constant worry should be what else software is being used, how to be relevant in the future. Maybe through cutting costs in the process by co-designing new workflows to eliminate current tasks.
Executives at the client may be more intrested in finding ways to eliminate all the staff with automation in the process rather than optimizing their tools.
You’re not getting that input from the people working on the tasks now.
I have a different approach. I look for a theme on Theme Forrest which has most of the layouts and components I think I'll need and I lean on those VERY heavily. And for logos I use icons from Font Awesome or Bootstrap.
Most of the time the project doesn't take off and when it does I can hire a designer.
Some examples of both a theme based app using an icon as the logo :).
Highly recommend Ryan Singer's (original Basecamp designer) work. His blog [1] is filled with great stuff. In particular this [2] post has given me over a decade of value re: designing UI and UX flows.
If you're not hiring a designer, someone else ends up doing their job instead. Someone, whose pay is probably 5-10x higher.
You don't even need them on the team permanently, commission a design or a review of the existing one.
Perhaps I'm biased. Graphic designers are dirt cheap. From our perspective, UX crowd is full of underqualified people looking for easy tech money. I can see how it can make hiring far more complicated.
I might be exaggerating, but I know how much I and my coder friends earn.
Western companies hire much more engineers and adjacents than designers. Consequently, for designers, the income is much closer to a local median. As my perspective is one of a person currently living outside the US or western Europe, I see a huge disparity between pay grades.
For example I reckon in my country say I'm on 150k TC as a senior eng and a senior designer may be on 75k. Using USD conversion. So 2x may be normal.
10x would make me probably in the top 100 highest paid devs in the country except those who got lucky with share comp or own a chunk of the biz.
The page does not recommend them directly, but also doesn't discourage them. In fact, it requires "guidance", which IMO might as well be a strength indicator.
> Verifiers SHALL offer guidance to the subscriber to assist the user in choosing a strong password
Reading through their guidance they don't really mention anything about password strength indicators being a good or bad idea. Sure, they list out a set of rules to verify passwords by and state no OTHER arbitrary rules should be included. But that doesn't prevent you from calculating password strength based on the rules they specify ie. minimum length and complexity.
But I get that "strength" is a poor metric. It shouldn't allow "weak" passwords. It should be binary - pass or fail.
The nicest thing about strength indicators - and I reckon this is why they are copied a lot - is that they are usually real-time feedback to the user with a nice red/orange/green invalid/weak/strong indicator that updates as the user types. The best ones even go as far as show you the list of rules your password is failing to meet, again updating as you type. Much much nicer than the server-side validation form submission loop imo.
So, remove the middle concept of "weak but allowed" passwords from the strength indicator widget, I think then you get good UX that meets NIST recommendations..?
The most common reason I get, professionally, is that it "prevents scripting" ... as if hackers are both using Chrome extensions at scale but also can't figure out how to defeat javascript and html form restrictions.
I like the article because it's very similar to the workflow that I developed while working on my first project after quitting my last job. One thing that I would add to "Be Explicit About Your Goal" is that it should be about both your goal and the user's goal. Otherwise it's very easy to hit blind spots that both you, another person, or AI will miss because of bias.
A small related rant is that many large companies with a dedicated team that works on design system don't seem to actually care much about UX. It feels demoralizing because sometimes it feels like many people are just using UX to push some other agenda.
Like... sorry to be That Guy, but maybe just employ / have a team with the right people from the start?
If a designer had a tech startup with no engineers, we'd all be (rightly) sniffy about it.
Imagine this post the other way round: "Hey, designers, here's everything you need to know about engineering and devops and coding in ONE PAGE!". Think about the HN response to this - it'd go down like a ton of hot shit. And rightly so.
I used to work at an educational tech company and they would - without even breaking into a sweat - take one of their engineering team and put them in charge of marketing. Same rule applies - imagine it the other way round, a marketing person with no knowledge of engineering setting the strategy for engineering. (And yes, I know it happens, but when it does we all moan on about it, no...?!)
Long and short: a startup / product without a UX person or designer in it right from the start is likely to be a clusterfuck.
An early startup starts with jack of all trades. If you needed the full team that even a $10m company would have you are probably not a typical early startup.
The reality is marketing is a skill most people can fudge because they have done it. They have gotten jobs, dates and haggled for a free beer before.
Programming is only something freaks do so the average marketer won't code. And if they do the average coding marketer won't make resilient 99% uptime code without subtle bugs.
Hate to circlejerk but man .... programming to produce robust, correct, reliable systems that do something useful is hard. Despite what the AI bros are hot taking on X these days.
Have you ever noticed that some tradespeople do their own books but bookkeepers won't come and fix your AC unit.
Tailwind + daisyui can get you pretty far. My thinking is, if your start up takes off a real designer can remove all of the daisyui stuff and re-design with only tailwind.
Where do startups typically get their branding done? I'm assuming the VCs usually refer their cohort to the same group of branding agencies? Who are the quick and dirty ones? Do they ever hire direct freelancers? Possibly to save money?
We got our branding guide done through a 99Designs contest. Over the last few years there has been an incredible increase in how many design entries you get per dollar on that platform.
It was definitely worth it, and then we redesigned the website, and now the app based on that branding guide. 10/10 would recommend.
I’m a UX designer and developer at a healthcare fintech startup. We do all our B2C communication design and product UX/UI design in-house with a small team.
But for our B2B site…I can’t name names…one of our investors did refer us to a well-established design agency who does small and medium-scale enterprise branding and marketing. And they did great work. So yes, there are a few ringer VC design agencies out there.
But I want to point out the application that is used at the Quest Diagnostics lab. The one they use to enter your demographic, lab info, etc. The daily driver for their legion of phlebotomists, at least here in So Cal.
One word. It’s fast. Oh man is it fast. Bunches of fields, bunches of dialog boxes, looks like a Windows back office application. Prints all of the vial tracking labels. These people are trained and know what is coming when.
But, it seems to be in a web browser tab. Perhaps they’re running a RDP tab to a nearby server running some Windows based desktop app, but, again, this app flies. I’ve not seen modern app this fast.
OP here - A good freelancer gets you a long way. What I found is that during the development process, people hit edge cases and have questions... doing a lot of the discovery and thinking yourself helps you answer those questions faster.
Alternatively, if you find a freelancer within your budget that can stick with you until the feature is out of the door is a great win.
eh. For who want's to get deeper/broader view, there's a "bible" on UX.. called "Usability engineering" by Jakob Nielsen ~1993 [0].
IMO The first 2 (two) chapters are, like, mandatory - the what and the why. The rest, is mostly details - how. (but it has even how to organise random-street-user-tests and what to look for in those, etc)
Although, looking at recent 10 years of (software-or-car) UXs, i feel noone reads these anymore :/ Sadly.
One problem we have on our service (genenetwork.org) is stylistic consistency across many different pages and forms. Even one programmer can invent five different ways to close a window or pop-up. Table styles can be annoying diverse.
Great try this and see how far it goes ! None of this matters if u don’t find pmf and u don’t need a designer for this. Totally disagree with this. Article started great but then niched out too small with login flows. No startup is reinventing this.
AI is not designing good? How? The tech bros hate artistic minded people.
They hate design because it is the engine of growth and change. Tech bros like sameness and libraries. They love "design patterns".
But change is inevitable and design is not in the colors, fonts, whitespace.
Design is human centered practice for solving not only functional tasks but emotional. And for this there is no Tailwind, React, AI solution, or design patterns template.
PS: I am a designer and frontend engineer with 20+ years practice with my own company and plethora of delivered solutions for my clients. The divide between engineers and designers is the most persistent thing that I have seen in my life.
> Design is human centered practice for solving not only functional tasks but emotional
Having worked around design and UX people for a long time, I'd say there are plenty of design people who are practical and don't talk about emotional tasks.
So they are missing a lot. And this is the core of the problem. Emotions are practical. They are a part of human experience. You cannot approach design process as a framework documentation or recipe. Moving with current trends of double diamonds or whatever tools are fashionable. You have to be a generalist first and tap not only to the tech stack or quantitive approach, but also into a psychology and culture.
>Emotions are inseparable from how we humans think, choose, and act. In Emotional Design, cognitive scientist Don Norman shows how the principles of human psychology apply to the invention and design of new technologies and products.
To me, peak usability was 25 years ago, when most applications had a toolbar and a menu that followed a standard pattern. If you're a frequent, non-power-user, you use the toolbar (e.g. "insert row" button). If you're an infrequent non-power-user, you go through the menu (Insert > Row Above). If you're a power user, you remember the shortcuts indicated through underlined letters in menu labels (e.g. Alt, I, A).
If you want to change settings, you open the settings dialog (Tools > Settings), and it as tabs like "General", "Fonts and colors" etc.
Most people were a lot less computer literate back then, but they were able to use most applications with little help. If they really needed help, the help system was built into the application.
The goal back then was to have the user get the work done as efficiently as possible, in effect, minimizing the time the user pends on the application. Modern UX doctrine aims for the opposite goal -- to keep people "engaged" as much as possible. This might be okay for consumer apps, but maddeningly, the same doctrine gets applied to enterprise applications as well. I've literally heard non-techie employees of a Fortune 100 company ask for their legacy green screen terminals back because the new, flashy SPA was slowing them down.
>To me, peak usability was 25 years ago, when most applications had a toolbar and a menu that followed a standard pattern.
I've done different sorts of tech support since grade school and people always ask me how I got so 'good at computers', I they never believe that actually reading the menus is 90% of it and that once you learn the common ways programs are arranged and some common shortcuts you pretty much know how to use all of them.
One of the most expensive pieces of software around is a Bloomberg Terminal, with base price starting at 20k/yr/license, plus more for extra data. And the UI, when you first use it, is beyond clunky. It looks seriously like a piece of stone age technology, adapted from clay tablets. Even the styling is like 80s films about edgy hackers and their punch cards.
Except when you talk to the grey hairs, you realize that UI has never, ever changed - it is backwards compatible back to, well, stone age of computers. It is quirky, but once you learn it, you're done for life - no refreshed new looks or skins or dark modes (well, it's always in dark mode) or rewrites in Svelte or whatever. That's basically because the power user is essentially the only user that matters. They know all the arcane key bindings and weird abbreviations, and Bloomberg knows better than to mess with it.
I hated it at first but grew to love the stability of it.
Speaking as someone who has never used it but has spent some time researching it, the Bloomberg Terminal constantly undergoes UI changes, though not in a dramatic way. It's obvious if you look at screenshots throughout the time (it even had some gradients!). It has had its own "rewrites in Svelte", transitioning from a custom renderer to HTML/JavaScript.
But you're correct - they don't mess with it, they slightly and mostly invisibly improve it, and someone who learned it in 80s could use it without problems today.
https://www.youtube.com/watch?v=uqehwCWKVVw
https://www.bloomberg.com/ux/2017/11/10/relaunching-launchpa...
https://www.bloomberg.com/company/stories/how-bloomberg-term...
https://www.bloomberg.com/company/stories/designing-the-term...
> the Bloomberg Terminal constantly undergoes UI changes, though not in a dramatic way
This is correct. (Source: I worked on Bloomberg's UI change management policies.)
Despite dismissive comments from design industry folks and more modern-looking competitors, the folks who ran Bloomberg's UX team maintained a focus on customer needs and user research. There are even a few cases where function teams went back and re-implemented old "bugs" after a rewrite (e.g. in the MSG editor) because users had adapted to the old behavior. (Thankfully nothing as bad as spacebar heating https://xkcd.com/1172 though)
> and someone who learned it in 80s could use it without problems today.
That's the true dream. Like all of those old movies where the hacker or fighter pilot has to use some foreign, alien or futuristic tech and they just use it!
I worked for an insurance company for a while that was pushing their agents away from 'green screen' terminals to webapps that did most of the same stuff, the agents hated it because they had every step necessary to do quotes and such memorized and were way slower trying to navigate menus on the web.
I just watched a few minutes of someone using it, and I have a few observations.
- Uniform menus everywhere
- Every menu has an ID visible in the corner. Imagine how easy troubleshooting would be if you could just say, I'm on menu 4388 and I'm not getting the result I expect.
- Every selection has a number. Presumably you can type this in rather than mouse over to it?
- Every page has keywords you can string together for instant searching
- No transition animations
This is nice to see: a tool for getting things done, not for nudging the user in a desired direction to satisfy marketing goals.
My parents work for a company using an old system using numeric IDs for menus and screens. It's currently a web app, but it seems to share a good deal of code (and a great deal of philosophy) with the previous, older version, a TUI apparently built in Pascal.
I can confirm that those numeric IDs help A LOT in troubleshooting and documentation. And not only that: those IDs are frequently and naturally used by the users themselves when communicating between them. Needless to say, they also use the IDs to navigate the system, only touching the menus when they have to use some infrequent function.
I always mention this "case study" to UX folks who insist to dumb users down with childish interfaces.
> no ... rewrites in Svelte or whatever
The vast majority of the terminal interface has been rewritten more than once, but the UX framework team does a great job mimicking the prior look and feel each time. Though if you know what to look for you can spot functions that haven't been updated in a while, and even a handful that have remained unchanged since the beginning.
> no refreshed new looks or skins
Basically right, though Launchpad was completely new and PDFU COLORS <GO> provides color themes intended for folks with color-vision deficiency.
Yeah this is a good reminder that technology rewrites do NOT need to rethink the UI. I've always favored updating the technology first to enable faster incremental UI changes afterwards.
I love my UX friends but they almost universally hop on tech updates to rethink everything, and then it muddies up the customer feedback on the rewrite. Was this a tech bug introduced? Or an annoying UX change? etc.
Well, it depends on the audience of your software. Bloomberg Terminal is awesome, but has a steep learning curve. Most people who learn to use it are learning it with the specific intention of finding a job where they are paid to know how to use the Bloomberg Terminal. I agree, the UI is awesome for that, but if your startup is an app to find a dog walker or something, the vast majority of your potential users are going to be turned off by the Bloomberg Terminal interface.
Yeah but even if your app is the new Uber for dogs the goal should still be to let users accomplish their task as fast as possible and not some app engagement metric.
> you realize that UI has never, ever changed - it is backwards compatible back to, well, stone age of computers. It is quirky, but once you learn it, you're done for life
True power users could customize to remove the quirks and also be set for life, but at a better level of ergonomics. Or they could even use the best customization from one of those gray beards who cared about ergonomics more ever back in the day
And none of of the cheap criticisms of skins would change it since skins for power users are optional
You fail to grasp the value of bloomberg terminal.
The UI has in fact, evolved, but it has never changed. For example, higher DPI screen sizes, the UI is now instrumented in a web browser, no longer the the old TUI. It is fast, it is familiar, it's the same, but it evolves, if that makes sense.
If you know how to use it in company A in decade 1980, you know how to use it in company B today. That doesn't mean it hasn't improved or improved ergonomics.
It's a beautiful piece of engineering that got the basics right. Power users add whatever they need to it, modular, but it's not like Vim or VSCode where you are basically useless without a large effort when moving into a blank new updated version, let alone things like the ribbon design vs the old design in office.
It's the other way around, the value of that terminal is in the information, not whatever hated UI quirks it had been stuck with since its inception, yet people keep falling for that old logic "old+expensive = great".
> it's the same, but it evolves, if that makes sense.
it doesn't, these are the opposite.
> If you know how to use it in company A in decade 1980, you know how to use it in company B today. That doesn't mean it hasn't improved or improved ergonomics.
Neither does this: it would be just as trivial to select at company B "use config ergonomic_grey_beard_1980" and continue with all your knowledge, just without those quirks you hated in 1980 that led you to change the stable defaults to a better config.
> but it's not like Vim
And in some sense in the relevant UI area it's exactly like Vim, where many bad quirks in the default config are praised by the grey beards and new converts alike.
> moving into a blank new updated version
Why would you do that instead of using your old config???
> the ribbon design vs the old design
Neither is forcing a change like this the only alternative
I think to me that would be the appeal of Vim. VSCode implicitly promises this with its plugin approach. Using Ctrl Shift P for years is the sort of thing I like. One less thing in my way.
I'd never noticed that ctrl-shift-p was a thing. In gvim ctrl-p moves up a line but ctrl-shift-p seems to do page up. Do you know if this is documented anywhere?
It's not just about 'UX backward compatibility', it's the epitome of an expert user interface. If you don't know what you're doing it's near unusable but once you've mastered it the speed at which you can operate is incomparable to 'normal' software. It's also one of the few examples of this outside of software engineering tools.
> well, it's always in dark mode
So it's no TUI app that can accommodate changes to the terminal emulators color profile? I am a bit disappointed.
> backward compatible to the Stone Age
Like Emacs. And myself ;)
At all times, people that are proficient at a green screen terminal application will prefer it to a web based or GUI based experience. They have muscle memory and a lot of codes memorized to switch back and forth from screen to screen extremely fast and exactly how many tabs to hit to fill out a form. It has nothing to do with SPA or whatever is currently new and flashy this has been going on for decades. The fact they have to remove their hand from keyboard to mouse pretty frequently is the biggest productivity loss, then drop down boxes and forms that aren’t very keyboard friendly and the page render times are incredibly slow in comparison.
I myself made this complaint a few times. When I was using medical erp once then again using a banking system. Both you could navigate by typing a chain of commands that would register even if you typed faster than the screens would render in the terminal. Hell, in the banking one I completely automated my job by writing an excel macro and sendkey commands to the terminal, then I sold it to the bank for a small sum after I quit (they asked me how I accomplished so much after realizing 3 people couldn’t handle my workload)
> Both you could navigate by typing a chain of commands that would register even if you typed faster than the screens would render in the terminal.
Nowadays even the login screen in Windows can not manage it anymore. Gotta wait for some animation and whatever it needs coming back from sleep mode before it starts registering keys.
You could still do this in the GUIs of 25 years ago, you'd just memorize the keyboard shortcuts and use them. They'd buffer so you could type a series of operations faster than the screen could render them, and basically every function was accessible from the keyboard. But the GUI had the advantage of discoverability - if you didn't know the keyboard shortcut, you could just work your way through the menus and find it.
While possible, the uptake/usage is very low once it requires lots of CTRL / ALT / CMD button sequences. Take something like Excel, which many users use daily for work, but most people likely only use less than a dozen common keyboard shortcuts. Practically nobody navigates the ribbon with their keyboard.
I'm in a role of Finance / Excel "super user" in my profession. There's a subculture of keyboard shortcut enthusiasts, but generally everyone is using their mouse a lot. I myself have about 20 that I use and rarely incorporate a new one into the mix, it has to be an action I perform repetitively for me to care enough to memorize seek out and learn the shortcut. I find navigating the ribbon usually requires too many keypresses and I instead have a custom quick access bar that I put everything I want access to so I don't have to toggle differing ribbons, I still use my mouse even though I know I could use my keyboard. It doesn't feel easier
But it’s true that the menu systems often made the accelerations and afterthought, and regularly used functions for some people had no shortcuts and no way to set them.
I still think a World of Warcraft style action bar, user configurable and multilayered, would work just fine for power users. You can put anything you want in position eight but most people have the same things set for 1-5.
That's funny. I automated a lot of my tech-writing job in the '90s with expansive macros written in WordBasic. What a great product.
> This might be okay for consumer apps, but maddeningly, the same doctrine gets applied to enterprise applications as well. I've literally heard non-techie employees of a Fortune 100 company ask for their legacy green screen terminals back because the new, flashy SPA was slowing them down.
Applying general design principles without taking actual use cases into account is the worst.
A common one is putting heaps of whitespace around each cells in a table. Visually appealing, sure. But unusable if I need to look at more than 8 rows at the same time.
Agreed. Most user experience work today are done by people who ironically have little experience as a user. E.g. they will design a table in Figma, make it look nice. They may even go so far as understand that this table will typically contain 2500 rows and introduce pagination and filtering by most commonly used attributes. But if they load some sample data into a functional mock system and simulate a typical user's day (e.g. they have to wade through this table multiple times per hour, while on the phone with a customer), they will immediately realize the feel good factor of white spaces, pastel colours and high contrast icons are very low priority.
You forgot one awesome feature of those SPA: once your user finally manage to get some muscle memory in, you can push a new UI redesign so get them back to square one. Because you have to give work to do to your frontend people.
> Most user experience work today are done by people who ironically have little experience as a user
So many upvotes for this. While the provided thing might technically work, if it is clunky for the users, the users will not like it. I understand those making the thing will probably never use the thing. The problem comes when those making do not listen to those using. There have been many times where I've made the thing, but then when I went to use the thing I wanted nasty things to happen to the person that made it. I've been in some very contentious UAT rounds where I was the user and the devs refused to listen to valid complaints.
The funny thing is that a lot of those problems are known during development time, by the people who have to actually "use" the product at all times during development, a.k.a. the developers.
Not sure I follow. The situations I've built appear fine during testing during development. I go to the UI, click the buttons, get the correct result. Test complete.
The type of thing I'm thinking about is when the user does that many many times in a day, but to get to the button that is on one part of the screen which is very inefficient compared to if the button was moved closer to something else so that the UX is improved. Sure, what the dev did "worked", but it might not feel clunky when you test it once or twice. That's the difference that drives most UX<=>Dev disagreements.
Dev: but it works
User: yes, but it sux using it. it can be better for us if change X, Y, Z
Dev: but it works. ticket closed
It doesn't matter if it works while everyone hates using it. I don't care what the devs think. If the user's request is reasonable, rational, and will improve the UX, stop fighting it. This situation is precisely my experience that happens when there's no designer.
I'm talking about bad designs. Grandparent mentions Figma, this is who I'm talking about.
Developers have to work on the app the whole day and they know when a design is bad for long term usage. Either by doing manual testing, or even when automating it.
UX people dictating the designs will rely on instinct even when developers complain that a design is inefficient. Or even for visual design things like excessive padding getting in the way of making the apple useable. IME, YMMV.
If you're talking about inexperienced/unemphatic developers being in charge of UX alone: well, yeah, that will happen too.
TFA is about not having a designer. If you have a bad designer, then fix that glitch.
Once again: grandparent post says "e.g. they will design a table in Figma, make it look nice", so I was answering in that context.
Reading about whitespace on tables infuriates me so much.
At a previous job we had an actual good designer figure out what users wanted and she found out users wanted denser information. So she designed a more compact table. It was quite smart, used the whole screen, but still looked amazing and didn't feel cramped.
Then my company released it as a library for the whole company to use and the first thing one of the product managers did was requesting margins AND frames around it, plus a lot of whitespace between cells.
Now instead of displaying around 25 items on the screen at a given time, this other system can only display around 10.
The cherry on top: it looks horrible with the frame and with the unbalanced margins.
I worked on a couple of internal frameworks as a designer and thats exactly what happened to our frameworks.
Throwing away all the research and optimization out of the window for one unnecessary “we really need this” scenario.
> Visually appealing, sure.
It's not even.
I agree with this, so much so that I wrote a long essay about this
Modern web design has completely lost the design idioms that so much thought went into during the desktop software wave of the 90s and early 2000s. This is a great loss for usability.
https://loeber.substack.com/p/4-bring-back-idiomatic-design
Not just web design. Design, period. Here's what Apple is producing these days: https://x.com/dmitriid/status/1899392713323147633
That is most likely what their iOS & macOS design language will be going forward: https://www.macrumors.com/2025/03/10/ios-19-visionos-redesig...
With that said, the design sins it commits are pretty standard in the age of minimalist/flat UI. It looks pretty similar to Apple's current design language, just with some stylistic tweaks.
Not defending it, as some of those design decisions drive me up a wall. Is this text a button or just an input field? Can I click this image or is it static? Which directions can I swipe? Does this grey text mean it's a disabled button or placeholder text on an input field?
I am not nostalgic for the blocky, grey, in-your-face design of classic UIs like Windows 98. But sacrificing functionality and discoverability on the alter of pretty design is, unironically, bad design.
> But sacrificing functionality and discoverability on the alter of pretty design is, unironically, bad design.
The irony is that it's not even pretty a lot of the time :)
> To me, peak usability was 25 years ago, when most applications had a toolbar and a menu that followed a standard pattern.
Some things were good, but there were lots of problems too like features hidden behind right-clicks, not knowing if you had to double or single click, being required to read help/manuals to find features, too much jargon and technical language, and overuse of modals.
UIs have got incrementally better in lots of ways that really add up that I don't see people mention e.g. right-clicking and double-clicking is avoided, help is integrated into the UI where you need it, inline editing vs modals, options to edit an object appear next to it (locality) rather than you having to hunt in a menu, less technical jargon where appropriate, better onboarding, better undo/redo/autosave (which avoids clunky confirmation modals).
> Some things were good, but there were lots of problems too like features hidden behind right-clicks, not knowing if you had to double or single click, being required to read help/manuals to find features, too much jargon and technical language, and overuse of modals.
I dunno… all of these issues are still very prevalent. The one that probably disappeared the most is the right click context menu, which I would argue was actually great for discoverability. Personally, I lament its demise. Of course context menus still exist, but it used to be a pretty reliable universal convention.
Right-click is fine for power users and professional tools if there isn't a better alternative, but right-click (and long tap on mobile) is super undiscoverable because there's no indication or hint it'll do anything.
Whenever I help non-tech friends with software problems, I'm always reminded most people don't feel comfortable hunting around for functionality and for sure don't try right-clicking things on the chance it might do something.
I know what you mean, but my point is, if you have a strong convention that right click
a) never actually runs anything, so you can’t accidentally break stuff
and
b) usually shows contextually relevant actions
That makes for great discoverability, actually. Discoverabilty is mostly a measure of how confidently one can dick around without causing accidents (and being able to undo them easily).
Your point about there being to indication whether something is clickable or not applies to left clicks just as well, and this also used to be less of a problem before everyone rolled their own, usually very flat, designs. You could teach someone basic principles and they’d be widely applicable. These days you’d have to start with a full lecture on the differences between web apps and “native” apps and natively packaged web apps…
I wonder if it took the shinier, less conventional UIs to get all these “non-tech” people to use computers in the first place. A dilemma, because they would benefit from boring conventions the most.
> right-click (and long tap on mobile) is super undiscoverable because there's no indication or hint it'll do anything.
I really miss the days where it was common for tap-holding on any control to show a description of what it is. It may still be common in certain Android apps but I haven't seen it or anything like it on iOS.
> tap-holding on any control to show a description of what it is.
Hmm, haven't seen this. Where do you need that? What kind of description that wouldn't be obvious from looking at the control?
> Hmm, haven't seen this. Where do you need that? What kind of description that wouldn't be obvious from looking at the control?
I most commonly see and also appreciate being able to tap-hold on icon-only buttons to learn the text label that the icon represents. I can usually guess what most icons mean, but sometimes it's not entirely obvious.
The root cause is that web browsers were designed for document delivery but are used for building application UIs. The browsers don’t offer a standard set of common application UI components, so every team builds their own leading to inconsistency and half baked implementations.
In contrast, when you build a native app, developers can draw on a standard set of OS provided UI widgets.
I think the root cause goes deeper than that, and has to do with economic incentives. Up through the 90s, the predominant business model was you sell a product, people use it to get work done, if they're happy they tell their friends and you sell more product. Starting in the 00s, the business model became you give a service away for free, get people hooked, make them so dependent upon it that they can't look away, and then either jack up prices to extort as much money from them as possible, sell advertisements so that other people can do the same, or sell their personal data so that other people can target them with sales pitches. Actually getting any work done became secondary to making the transaction happen. This applies just as much to enterprise software as consumer software, because the purchaser of enterprise software is usually some IT department, purchasing department, or executive who doesn't have to actually use the software, and they will probably move on to the next company before the consequences of their purchasing decision being useless become visible.
We are reaping the consequences of that now, where lots of transactions are happening that don't actually make anyone happy or productive.
But you can see how that would filter down into UI design. When your incentive is to make people happy and productive, you spend time studying how people actually use the product, and then optimize that so they can use the product more efficiently. When your incentive is to turn people into mindless consumers that keep coming back for more ads, you spend time studying what sort of content holds the user's attention, and then optimize that so you can work as many ads into the stream as possible without them turning away. When your incentive is to sell enterprise software, you spend time studying what sales pitches will get the budget-holder to open their company's wallets, and then optimize the sales funnel to the extent of actual product usability. Even if your users hate you, they don't get to decide whether they keep using you.
Developers always had the flexibility to create custom UI elements/colors etc even in native apps (albeit not as easily as using CSS). Even in SPAs, most UI elements follow the same style or pattern more or less (bootstrap/tailwind etc). It's the entire UI design itself that's not user friendly for enterprise/business apps (excessive padding, comically large UI elements etc).
Wouldn't say it's the root cause, but it is a major cause. I have some experience developing desktop applications using Visual C++ / MFC in the early 2000's. I still prefer that development experience to modern React/Redux SPA development.
OS widget libraries aren't always big enough to solve all problems. On the web, there are many frameworks that provide widgets for typical use cases.
But even if you have a library with hundreds of widgets, you can still make a terrible UX if you don't understand good design, and many programmers don't.
In my experience most designers don't know what UX is. They think their job is to make it look pretty. If it needs 3x more clicks to do the same thing as before so be it.
There's more consistency in UIs on the web than desktop IMO
People have less power on the web so it has more limitations, even if it lacks a number of consistent UI components baked in.Desktop apps are notorious for getting fancy. Even simple control apps from random headphones/keyboards/music gear/etc all want to reinvent the settings page and make it 'sleek' instead of usable.
And controls were demarcated as controls, not disguised as plan text or a decoration. You could tell if a function was activated by looking at the outline of the button; if the "bevel" shadowing went inward, the button was depressed and the function was on.
"Flat" design is simply derelict design. Fortunately there has been some backlash and we might be returning to legitimate GUIs.
Good old times :) I miss F1 help, which was usually very good and contextual. On a Settings dialog? Press F1 to view help just for that dialog - offline, instant.
For me, Norton Commander specifically, among other TUIs, was very influential in shaping my keyboard shortcut preferences. I used to rely heavily on Function keys; both for lightning fast file management, and also for code navigation and debugging.
One definite UX improvement over the past 25 years have been command menus. In the most simple implementation, press Ctrl+P start typing to filter a list of commands down and hit enter.
True. The UI of the applications from the late 90s to the early 2000s was way better than it is now - especially when you compare it to what is there in the web apps now.
Besides keyboard shortcuts, the following capabilities haven't really been implemented in web apps:
- Context menus
- Macros and the ability to record macros and create your own shortcuts to these macros.
- Terminal prompts built into applications such as in Autodesk - in some senses similar to the REPL in Clojure but built into the application
those menus started to slip a long time ago. they got larger, less organized, and got lazier about mentioning the keyboard shortcut. the new MS paint does a good blend of that style and a newer look
the current text editor trend of having a "command palette" is pretty nice. it's got a hard job to do, with the sheer number of commands and extensibility to add more, but search is pretty good for discoverability (as long as people name/tag/describe the commands well)
Exactly the reason I still write most of my code in emacs. I’ll use visual studio when I need to do GUI work, but I feel like I’m at a casino with a thousand flashing lights all vying for my attention. I also find swapping back and forth between keyboard and mouse to be a slowdown. I know some of the VS keyboard shortcuts but find many of them to be more convoluted than emacs (and I won’t even comment on the VS faux emacs bindings!)
Luckily I spend a lot of time building libraries, where I can keep my hands on the keyboard and focus on the problems I am trying to solve
Ok well a lot of that UX depends on hover states and right clicks that don't exist for touch screens. Key bindings? What keys?
That's the major reason we dont have the same toolbars. We can be cynical about engagement and free software but try to make a mobile app the old way. You can't.
”Modern ux” can be a very political term on HN.
Yes, uxers have to balance business and user needs. That is the power dynamic of business we live in, it’s not typically the driving force of actual uxers themselves.
At the core the ethos of the human centered design (HCD) is being an advocate for the needs of actual users. Being seen as the ”enemy” on HN feels demoralizing, as a person that sits on both sides of the fence.
I feel gladness about seeing the truth of my experience about this. I would like there to be more camaraderie between uxers and developers, and of course it being a more common scenario to be able to drive a genuinely shared vision also with business leadership.
If you have a source for ”modern ux doctrine”, i’d love to hear about it to have an actual discourse.
> uxers have to balance business and user needs.
What does this mean? It seems that compromising the UX for a "business need" is just lazy user experience design.
The UX designer doesn’t have absolute authority. Typically, they need approval from PMs and other stakeholders, which is where the need for compromise comes in.
> Modern UX doctrine aims for the opposite goal -- to keep people "engaged" as much as possible.
In many larger orgs, usually design doesn’t work in isolation. Some of these goals like engagement, retention come from senior leaders of different functions. The design proposals are evaluated and signed off against these goals.
However, when these designs and flows appear on platforms like Mobbin, they often lack context about their design rationale. This can create a network effect where other designers replicate similar designs for their own experiences without fully understanding the underlying reasoning.
The problem here is the fact that the expected cost of software has become zero. 25 years ago most productivity apps would charge money. There might be a free trial but you need to pay for it. These days most expect software to be free of charge. A lot of the regression in software quality and usability can be traced back to this.
Are there any Bloomberg Emulators or similar to mess around in? Essentially the equivalent of Lemmy to Reddit.
I desperately miss keyboard mnemonics.
yes, IBM's CUA wasn't that bad. 'F1' for help is one remnant of this.
(https://en.wikipedia.org/wiki/IBM_Common_User_Access)
> This might be okay for consumer apps, but maddeningly, the same doctrine gets applied to enterprise applications as well
I think this is a great point. I was consulting with a customer and their key goal in a complex system that had a time-sensitive user workflow was "minimise clicks".
I said to them that that makes sense, but saving 0.5s on a click every two hours is not as impactful as (insert example of a change that would speed up the workflow by 10 minutes every two hours).
And it's as you say: they come from the consumer world, where minimising clicks keeps customers involved. But it's not the only thing to consider.
The most obvious change that happens after hiring a graphic designer is that the app/website stops looking like shit, and adopts a pleasing color palette and set of fonts. There is real value in this, and the median graphic designer definitely chooses these better than the median engineer.
But UX is a broader umbrella which encompasses interaction flows at the large end, and single function widgets at the small end. For whatever reason, the median human is very bad at predicting the overall UX of a system. It's rare that you have someone who can look at a spec for a system they've never seen before and accurately predict what will be easy to use vs. hard to use. Graphic designers are not meaningfully better at this vs. engineers either, it's just uncommon.
For that reason, UX is usually developed by copying existing solutions, or using the guess and check method to try out novel things. It's very difficult to create good UX by design because evaluating the system by imagination is much harder than with an implementation. Contrast this to backend system design where entire categories of error can be predicted and avoided through basic principles and reasoning.
Where this can go wrong is when you think that you can hire for something which is actually rare in the talent pool. If you have a graphic designer or engineer who has demonstrated an excellent gut feel for UX, then that's incredibly valuable. But you can't wait around to find such a person, or pretend that you will be able to hire someone like that.
> It's very difficult to create good UX by design because evaluating the system by imagination is much harder than with an implementation.
This is precisely why it’s a tragedy that the roles in software development have become so compartmentalized. It wasn’t that long ago that the same person designing an interface was also responsible for developing it. Or that design and development were one and the same, part of the same process.
These days, many “UX designers”, “UI designers”, and “product designers” have never written a line of code. Some even have an allergic response to the very idea of coding. That’s fine, but naturally it means there’s a wide gap in understanding between design and implementation. This leads to the UI equivalent of the dreaded Architecture Astronaut[1]—so disconnected from the reality of how software works and is built that they design absurd interfaces that look great in Figma but fail miserably when put into practice.
In my experience, the closer you are to the implementation—and by this I mean the more involved you are in the actual coding—the tighter the feedback loop on the quality of the user experience. It affords the sanding and polishing required for a great UI with a great experience. Some of the very best interfaces that I’ve seen and used, both in terms of quality user experience and visual design, were designed and built by those rare engineers that happen to have outstanding intuition and taste for great design. The worst UIs I’ve used are from designers that don’t code handed over to engineers with no design taste.
[1] https://en.wikipedia.org/wiki/Architecture_astronaut
This is a really great comment.
To me, "UX" still feels like a relatively new term. In its modern incarnation it's not what I do, although by intent it's actually my career speciality. As a category now, it feels like a poor compromise between true design and true code/userflow. I believe the existing tools try to bridge a gap that has existed since the earliest days of web development between the designers and the code monkeys.
I'm fortunate as a solo coder to have a very tight feedback loop with my own graphic design, but I wouldn't have it any other way. I started writing code making text-based games as a kid in the 80s, then became obsessed with graphic design, went to art school, worked as a designer at a traditional ad agency which had no coders... and because of my code competency became the go-to person for making web. And later apps. So I still currently art direct designers and also write the majority of code for clients. This lets me understand the flow first and then unify the design in ways that aren't prefab or obvious, but ensure user safety and flow in a beautiful way.
I think the tools now (Figma, yes, but also the reliance on standard use cases of frameworks like React) are very limiting. They shoehorn both designers and coders into an uncomfortable middle ground that's not too different from the arguments that used to erupt between designers and the couple of devs at my ad agency in the 90s - we want it to look like THIS vs. Do you know how impossible that is? So everyone settles on a crappy solution instead of sitting down and thinking about how to make something new and better for the situation.
Honestly, Flash was so great because it allowed both sides of a team to use both sides of their brain at the same time, and cross-pollinate design with code in a way that seems hopelessly lost now, at least for normal business apps outside of game development.
There aren't so many cases where business-y or banking software needs to be beautiful, but it could at least be thought through. I look at my banks' apps and sites and slap my face at the obvious miscommunication and sheer carelessness that must have taken place between management, design, and code to produce these monstrosities.
But would I want to be on the open market, looking for new clients with my cross-disciplinary background as a "UX" person? No. What they need aren't UX people. They need art directors who can at least write some code, or (even more rare) coders who have formal design training.
I think the reason UX moved into its own realm (like "UX designer") is to create the processes to get actual UX expertise.
Without deliberate UX expertise, you're on the hook for having UI implementers (software engineers) who happen to be good at UX, and that's not a great way to go about ensuring that you have good UX because you're reliant on serendipity.
And of course once UX becomes its own prong that you're trying to optimize for, the simplest thing to do is create UX positions in your company. Which is much simpler than figuring out how to hire software engineers with UX expertise or good intuitions.
Just consider how few hiring processes involve someone clicking into your github projects and evaluating them just to see what kind of code you write. That's much harder than doing a canned leetcode or canned questions interview.
This isn't just a software thing... all of corporate america has compartmentalized and while the results in churning out widgets are actually very good, the results in practically everything else are bad bad bad. Even in finance, Warren Buffett will preach that investing is not a team sport - you need all the details in one head.
> These days, many “UX designers”, “UI designers”, and “product designers” have never written a line of code.
Same for some "architects". They just draw up random system designs that don't work for THEIR environment.
> This is precisely why it’s a tragedy that the roles in software development have become so compartmentalized.
The worse part of it all is it's not the software engineer's fault either (most of the time). HR, managers and others haven't improved over time and instead are enforcing non-software values on the engineers. It's all about ticking boxes. You get classified as a Go REST API backend engineer and somehow you can't touch React because that's not your thing.
Yet everything remotely serious built with React has gotten worse and worse... and apparently the project managers who rely in it and the coders who are used to its obviously major flaws can't think their way out of the wet paper bag that it's become, and see clear to writing a component from scratch. REST, sockets, whatever; the issue isn't how you send data over the wire, push it pull it or when. The issue is: Is what you're doing appropriate for the situation? My bank has started using something like React to show live stock prices in trashy grids. Guess what: That is a horrible idea because it's always wrong in some part of the screen. Let me reload if I have to, or else engineer something actually realtime.
They use these technologies because the recent grads who know how to use them are cheap and replaceable and the assumption is that the tech is uniform enough to make the coders hot-swappable. The product is enshittified garbage, but the managers don't care.
What is it exactly about React specifically (as apposed to Vue, HTML) that makes it flawed from a design perspective? I used to design and develop with Flash (which I very much miss) and while it was amazing for things like games, digital signage, elearning, etc, there is no way I could develop in Flash the products with the kind of complexity/responsiveness/sophistication of the web apps I am building now. Designing with hot reloading and code, live, is by far the most powerful and iterative design workflow I have ever experienced. While an inexperienced front-end developer may limit their design possibilities by only reaching for existing components, a good front end developer should be able to create bespoke components that are fit for purpose and responsive with the flexibility to rearrange and iterate.
With all that said though, there is a HUGE gap that Flash left for highly bespoke and creative products that web tech doesn’t satisfy at all.
> What is it exactly about React specifically (as apposed to Vue, HTML) that makes it flawed from a design perspective?
I'd say it's not React (not parent poster). I mean React might not be the best, but it's the least of the current problems.
React is the most widely used. You're bound to attract all sorts of people. Poor code is poor code. You'd hire React developers because it is the easiest to hire. It doesn't make it good or bad.
There's nothing really fundamentally wrong with React that makes it a terrible idea that always results in poor performance. It's shoddy development practices that can make for a bad app that uses React. If you use React well though, it's not like React makes it particularly difficult to reach a good level of performance. I typically find that React makes it easier for me to make a well-performing app, but that's just me.
I don't think it's even React itself that's the root cause the performance problems, it's using the data store badly (Redux or Mobx or even the new ones like Zustand and Valtio) that either causes components to rerender too often or causes too many components to rerender.
Having been bitten by this a few times, I'm paying a lot more attention to how my team uses it in the React app we're building from scratch right now, keeping an eye of how it's used and looking for problems before they become noticeable. I am, for example, inverting one of the common practices which I found was a cause of these performance problems:
"Atomic Design" with React splits components into different types - Atom, Molecule, Organism, Section/Template, Page. Each type of component is mainly composed of the smaller ones. It's generally suggested that Atoms and Molecules should be functional style and reusable, so not connected to the data store at all. Instead, Organism and up are the ones that manipulate data and pass things down into Molecules and Atoms to render. The problem here is that any update that triggers an Organism to rerender will also rerender all the Atoms and Molecules in it, even the ones that don't actually need to update (in the class-based component days we had shouldComponentUpdate() to avoid this, nowadays we have useMemo()/React.memo - neither of which we used with any consistency because of the extra effort).
Instead, while we do have a company-wide library of Atom-like elements we're using, the Atoms and Molecules inside the app are "smart" - they take a prop or two for configuration, then use that in combination with the data store to handle the data manipulation directly. Organism-level components then don't do any data wrangling and are just laying out what Molecules go where. This means when manipulating a Molecule, only that Molecule and any others looking at the same data need to rerender. The Organism and other Molecules in the same Organism are completely unaffected, not even trying to rerender and no need for React.memo to prevent it.
(Aside, to avoid confusion in the current app I haven't introduced the Atom/Molecule/Organism naming convention, and am instead using more semantic app-specific names for organizing components)
We still have a ways to go but we've already implemented the specific part I expected to cause the most problems here, and so far it's been great, the latency is so low it doesn't feel like a React app in the way I've come to expect, and there's much less manual manipulation of the data in the components themselves.
> I don't think it's even React itself that's the root cause the performance problems, it's using the data store badly (Redux or Mobx or even the new ones like Zustand and Valtio) that either causes components to rerender too often or causes too many components to rerender.
Like I said, it's shoddy development practices. I've seen apps that use one of those mutable object libraries (not any of the ones you listed) and just pass the objects everywhere. Whole app re-render on any state update because of how all of the state is nested inside these mutable mega-variables held by the root of the component tree. I try to chip away at the innermost components and create little havens that use immutable state as they should, but it's going to take years to redo the whole app that way, especially since refactoring isn't a priority yet.
By the way, a cool trick if a component you're using does not use `React.memo` is to memoize the element, because if React sees the exact same (reference-equal) element as the last render, it will not re-render the corresponding component tree. (Element refers to the return type of JSX expressions.) Obviously, only do this if it actually doesn't need to re-render.
Make them learn coding instead of adding yet another responsibility onto developers.
Nobody is suggesting adding this responsibility to developers, but what actually happened was that developers who can design are almost forbidden from doing so, unless they are in positions of power.
Some of us have lost our voice when it comes to design.
You just perfectly laid out why it's simultaneously difficult to find a new job in UX while getting paid well once you do find a job (if you're good).
Those who understand what good UX is and how it manifests itself, value it highly, while many (even in tech) still consider it pixel-pushing and "pretty colors".
Or you know.. talk to users and understand their needs (discovery) then design solutions based off that understanding and iterate on designs with usability testing with said users until it feels like magic to them using it the first time, smooth and seamless flows across use cases with good copy and accessibility.
Here's the best tool for finding usability issues: https://aistudio.google.com/live
You share the screen with Gemini, and tell it (using your voice) what you are trying to do. Gemini will look at your UI and try to figure out how to accomplish the task, then tell you (using its voice) what to click.
If Gemini can't figure it out you have usability issues. Now you know what to fix!
I'll have to use this, thanks for sharing. Isn't it problematic since Gemini isn't representative of a real user, though?
Definitely a huge trap to replace real user insights with anything else.
But this looks like a nice level 0 of testing
A real user might be worse. A program is less flexible (maybe) and more consistent (definitely) than a meat space CBL.
The goal is not realism but a kind of ready made "you must be this tall to ride the rollercoaster" threshold.
Discovering edge cases with dodgy human users has its value, but that's a different value.
A real user will be worse … but that’s kinda the point.
The most valuable thing you learn in usability/research is not if your experience works, but the way it’ll be misinterpreted, abused, and bent to do things it wasn’t designed to.
Enter "Drunk User Testing". Host a happy hour event and give some buzzed users some scenarios to test.
https://www.newyorker.com/magazine/2018/04/30/an-open-bar-fo...
https://uxpamagazine.org/boozeability/
More consistent? That's not a given with LLMs unless you set the temperature to 0.
You are right. LLMs are totally random and useless.
Thanks for playing.
You seem to disagree. Here's an interesting study where the researchers used an OpenAI-LLM-based tool to grade student papers and by grading them 10 times in a row, they got vastly different results:
https://rainermuehlhoff.de/en/fobizz-AI-grading-assistant-te...
Quote: "The results reveal significant shortcomings: The tool’s numerical grades and qualitative feedback are often random and do not improve even when its suggestions are incorporated."
Very clever. Reminds me of using Alexa to test your pronunciation of foreign words. If Alexa has no idea you probably said it wrong.
> If every product in your space does something the same way, there’s probably a good reason. If one company does something different, ask yourself: Is this intentional, or just a mistake?
To add to this, often you can come up with a lower friction UI idea for your specific use case (e.g. that requires less clicks) if you think hard about it, but if you stray too far from what people are used to seeing and interacting with it creates its own kind of friction, and you'll get feedback like "I found this unintuitive" or "it took me a moment to figure out how to use it". So you need to balance using familiar patterns vs new ideas.
E.g. maybe you think you can improve on the Amazon checkout experience for your own site, but by doing something different, you're tossing out the familiarity bonus you get for free. Similarly, by preferring checkboxes, radio buttons, dropdowns and text fields, over custom widgets, you get so much for free like user familiarity in reading the current state, and knowing how to change the state.
"Unintuitive" can often mean "I'm not used to this pattern" even if it might be a good pattern once people get used to it.
That was a lot of words to say "Jakob's Law"[0]
[0] https://lawsofux.com/jakobs-law/There's an enormous difference between HCI and UX.
HCI relates to computer usability for general use cases. A CAD program is there to help you get tasks done, not waste your time, so must follow general HCI principles.
UX is watered down HCI that takes business considerations into account. Think about how Microsoft jams a Copilot button into everything, all the way down to the blinking cursor. That doesn't help users (and it is not removable), but it helps Microsoft claim it added 100+ million Copilot users.
The UX of Facebook is a huge mess, a never-ending, non-chronological scroll of dopamine slot machines. HCI considerations would posit that going back to the algo-free, chronological version would help users "get what they want" faster. But helping users complete tasks faster hurts how much FB can charge advertisers for your attention.
Whether Facebook's content is good or bad is not really relevant; the UX of FB, Twitter, LinkedIn, and almost every other social media app is remarkably similar in layout and function.
Yes, but not because of a self-proclaimed "law". The UX is similar across FB, Twitter and LinkedIN, because they all sell ads, and what you can charge for ads is reliant on how much time people are spending on the platform.
Laws in these cases are never self proclaimed; they are simply made from observations. This is not a law in a legal term; it's a law because through observation, there is a universal truth to it.
I knew it as “The principle of least astonishment”.
I recommend focusing on general design principles and mindset.
- Read "The Design of Everyday Things" by Donald Norman - once you understand what makes a good (or bad) door handle, you'll start seeing design patterns everywhere.
- Read "The Art of Game Design" by Jesse Schell. It discusses how to create engaging experiences, and games are particularly unforgiving. While people might tolerate an annoying tax app because they have to use it, they'll immediately abandon a game that's even slightly too frustrating, confusing, or boring.
Be warned: reading "The Design of Everyday Things" will make you incredibly frustrated at hotel doors, light switches in your house, kitchen appliances, and many other daily interactions with objects - once you realize that best practices to make them usable have existed for 40 years and designers still can't be arsed to make a restroom faucet you can understand on the first try.
I echo on the "The Design of Everyday Things" making you perpetually dissatisfied.
Thanks for the second rec, I'll give it a go
Doing something because all the big companies do it also leads to cargo cult mentality. You should know exactly why you are building every little part of your system. “Oh Google used a really annoying captcha on that page, I better do that as Google knows best”.
Have some confidence and don’t assume that other bigger companies are smarter than you are, think about what you can improve. Most of what Google have to offer, they bought from smaller companies that had the confidence to do just this.
My favorite cargo cult thing today is that when you’re logged out you can’t find the login link anymore, just “Sign up”.
Especially when the signup form almost looks like a login form username and single password field ... then you get an error "An account with this email already exists" and STILL NO LOGIN LINK.
Yeah this one is really frustrating.
Text entry fields that don’t look like text entry fields.
Big companies aren’t usually that good at design (with some notable exceptions like Apple) because they don’t really have to be. They don’t need to impress anyone or prove their credibility, and they almost by definition have a product that people have a strong need or desire for, otherwise they wouldn’t be a big company.
When you have that, it probably doesn’t make much difference if you add some extra friction to your sign up flows or your UI is a bit janky.
When you’re the new guy who no one has heard of: that’s when you need design. You need to catch people’s attention, win their trust, and make it as easy as possible for them to get to the aha moment, because any minor inconvenience can be an excuse to close the tab of yet another random app and move on.
All that to say, startups often lean heavily on design to stand out from the crowd, so if I’m looking for good design and UX to emulate, I look for startups that are still small but gaining in popularity, whether bootstrapped or seed/series A. That’s typically where you find the best practices being implemented to a high bar. Once they get too successful, complacency and other priorities start to kick in and they are no longer the best examples to follow.
> You should know exactly why you are building every little part of your system.
As a UX designer/researcher who focuses on exploring novel interfaces, if every company rethought their UI from scratch that would be great for my job security. But realistically there are good reasons why most companies default to following established UI conventions:
First, your users generally have significantly more experience using products from big companies than yours, and differences are often perceved as problems. See Jakob's law.
Second, sometimes a company that releases a novel solution does fantastically well. But more often than not it ends up being a lesson in why the convention existed in the first place. See Chesterton's fence.
Third, unless you want to make the UI a differentiating factor for your product then any time you spend iterating on novel interfaces is time you could have been spending on your company's core competencies. See... I dunno, Seth Godin, basically any startup blogger?
Understanding exactly why before applying is not bad advice. But it takes time and can quickly become impractical when you're already pressed for it (like say, a small team startup already lacking a designer). In many cases it's better to just copy the closest thing to what you aspire to become, even if you don't quite yet grasp the details of why they originally made those decisions. All that can be figured out later for your own situation.
> Doing something because all the big companies
I learned this after many attempts early in my career to copy what the MS conferences were talking about.
The thing is that what a big company do can be good (in fact MS was fine back then!) but are problems for big companies, and have issues that you don't need to copy, worse: copy without knowing. For example, microservices, horizontal scalability, massive telemetry to cover all, etc are problems yo don't want to get.
What it works much better, is to copy a small/medium player that is very well regarded. Like for example, think in panic, vlc, etc. Small/medium players that have good reputation need make more effort than big players, and are on top of the good things by necessity.
Yeah. I like to think about why something is the way it is. If they are trying to accomplish something similar to me, then copy away. But if their circumstances and objectives are different…
The article writer is talking about if many companies do it there’s probably a reason for it, with UX and as an example things like email buttons, etc.
A strong but unspoken rule when anyone gives you advice is (and I feel like not everyone knows this anymore so this bears repeating): use your critical thinking skills to decide if the advice is applicable and appropriate for your situation.
There may be a reason for it, but best to understand what that reason is before applying the same approach.
Surviving without a designer? More life thriving without one.
Honestly I think many startups at an early stage don’t need designers at all and they just want to look trendy (which admittedly is critical for consumer-focused companies that live and die on becoming trendy, but that’s not what I do).
The best designer for an early stage startup these days is someone with not awful visual/UX taste (no need for a specialist or a visual prodigy; most teams I’ve met have at least somebody who isn’t hopeless in this respect); but with a strong understanding of their target users and what they’re familiar with, so you can just copy prior art as is relevant. Much better than taking a designer who knows nothing about the space and needing to transfer your learned experience into their brain somehow.
Most startups aren’t doing anything truly novel from a UI standpoint so why reinvent the wheel? Designers become more useful when you stop having strong communication and trust in your team since it just got too big for that.
From experience I will say that you can hire a UX designer even if bootstrapped and low on cash, and that it's a very valuable investment.
Just don't hire them full time as the article seems to suggest is the only choice.
Getting a small firm to go through a design sprint with you with, e.g. designing 3 concepts, letting you run a couple of UX workshops with your potential users, then picking one of the options to flesh out into a clickable prototype, then workshop again, then final prototype, can come out within a $5k-$10k budget.
That's 100% worth cutting $5k from your front-end dev budget, and will definitely translate into way more than $5k in user retention gains within the first year.
This is what we did before coding the MVP, and we're doing it again now (at Seed stage) before shipping our biggest upgrade to the product.
> Use AI to spot blind spots
> Tools like ChatGPT can highlight UX issues you might miss. It’s a quick sanity check—not perfect, but better than guessing.
> Tools like ChatGPT can highlight UX issues you might miss. It’s not perfect, but it’s better than guessing. Some prompts to try:
Was this an intentional joke?
Can't remember last time I worked with a dedicated designer, someone who actually knew anything worth knowing about UX.
Devops seem to be going down the same path, it's like they expect coders to do it while the code is compiling.
Next up seems to be coders.
And I get it, hiring professionals is very inconvenient.
We need a part 2 for this, the stage after you've picked up a bag of VC money:
1) Add an AI chatbot to every screen, add "AI-powered" to the homepage headline
2) On the pricing page, title the top tier as "Call our Sales Team"
3) Make buttons with undesirable actions hard to see and click ("Cancel Plan")
Here’s some typical reasons why a startup can fail:
1) it failed to communicate and market it’s product
2) it’s product didn’t fit the user’s needs
3) it’s technology strategy made development too expensive
4) it’s product technical quality was too low
5) it’s product did not look appealing to potential new users
Developers are responsible for 3 and 4, sales and marketing for 1 and finally designers for 2 and 5.
With competent developers you can start a startup and make sure 3 and 4 never come to pass, but lack of good product designer will eventually kill it.
Here I use the broader sense of user-centered designer, which includes:
- research
- testing
- prototyping
- validation
- UI/UX design
- visual design
- …
The first four being the most important for a product market fit.
This is especially important for B2B products, because there understanding the needs of the business and their processes is key to making sure the product fits the user’s day-to-day work but the businesses’ future needs as well.
It may not be common, but you can and should use extended UCD research methods on the customer business processes itself instead of relying on PMs and sales just asking customer’s what they want. (This is often called Business Design or Service Design around here.)
My most successful client (a company I have ownership in, now) has another slot besides marketing, design and code. That is our point person for filtering, testing and verifying user experience issues. Putting a single point person in charge of that onslaught of emails, who fully understands the software, and having them run a full time bug reporting/feature request channel, I think, is indispensible. They advocate on behalf of users but also know when the requests are silly or something is user error. They know whether an issue is mainly design or mainly code. Having them in place and engaging daily with users means we can filter out 90% of the noise in the signal. But it needs to be coupled with open-mindedness to customer feedback from the earliest iterations. Whatever requests or issues come through that person must be addressed. That person should understand what they can and cannot promise customers, what is crucial vs what is fluff, and how to prioritize those requests.
Her official role is "General Manager" but in fact she was promoted from a customer service role and the position was created for her because she was so good at spending extra time off-hours writing detailed, reproducible bug reports on behalf of customers who had experienced some issue. Reproducing and screenshotting the flow and the issues herself.
This person is a 10x force multiplier by virtue of being a power-user of the software who also interacts with customers and management daily, although she has no code or design experience.
True. When the complexity of the software causes lot of usability issues in ”edge cases”, these technically capable customer connected people are really worth it.
I’ve also seen good things coming from hiring actual ex-users from potential customers that were using competitor’s products. They’d do user training, customer software configuration and development team support. Sometimes even full time.
-
But these people are good day-to-day at ironing out the details. Maybe even discovering underlying dissatisfaction with the product.
But the startup’s constant worry should be what else software is being used, how to be relevant in the future. Maybe through cutting costs in the process by co-designing new workflows to eliminate current tasks.
Executives at the client may be more intrested in finding ways to eliminate all the staff with automation in the process rather than optimizing their tools.
You’re not getting that input from the people working on the tasks now.
Would you call that role "customer success"?
I have a different approach. I look for a theme on Theme Forrest which has most of the layouts and components I think I'll need and I lean on those VERY heavily. And for logos I use icons from Font Awesome or Bootstrap.
Most of the time the project doesn't take off and when it does I can hire a designer.
Some examples of both a theme based app using an icon as the logo :).
[1] https://getpreppy.app
[2] https://withlattice.com
Highly recommend Ryan Singer's (original Basecamp designer) work. His blog [1] is filled with great stuff. In particular this [2] post has given me over a decade of value re: designing UI and UX flows.
[1] https://ryansinger.co
[2] https://www.ryansinger.co/thinking-of-interfaces-as-sets-of-...
If you're not hiring a designer, someone else ends up doing their job instead. Someone, whose pay is probably 5-10x higher.
You don't even need them on the team permanently, commission a design or a review of the existing one.
Perhaps I'm biased. Graphic designers are dirt cheap. From our perspective, UX crowd is full of underqualified people looking for easy tech money. I can see how it can make hiring far more complicated.
5-10x? Are you sure?
I might be exaggerating, but I know how much I and my coder friends earn.
Western companies hire much more engineers and adjacents than designers. Consequently, for designers, the income is much closer to a local median. As my perspective is one of a person currently living outside the US or western Europe, I see a huge disparity between pay grades.
For example I reckon in my country say I'm on 150k TC as a senior eng and a senior designer may be on 75k. Using USD conversion. So 2x may be normal. 10x would make me probably in the top 100 highest paid devs in the country except those who got lucky with share comp or own a chunk of the biz.
> Common patterns—like password strength indicators—usually exist for good reasons.
NIST does not recommend password strength indicators. Make sure the form is compatible with password managers.
https://pages.nist.gov/800-63-4/sp800-63b.html#password
The page does not recommend them directly, but also doesn't discourage them. In fact, it requires "guidance", which IMO might as well be a strength indicator.
> Verifiers SHALL offer guidance to the subscriber to assist the user in choosing a strong password
Reading through their guidance they don't really mention anything about password strength indicators being a good or bad idea. Sure, they list out a set of rules to verify passwords by and state no OTHER arbitrary rules should be included. But that doesn't prevent you from calculating password strength based on the rules they specify ie. minimum length and complexity.
But I get that "strength" is a poor metric. It shouldn't allow "weak" passwords. It should be binary - pass or fail.
The nicest thing about strength indicators - and I reckon this is why they are copied a lot - is that they are usually real-time feedback to the user with a nice red/orange/green invalid/weak/strong indicator that updates as the user types. The best ones even go as far as show you the list of rules your password is failing to meet, again updating as you type. Much much nicer than the server-side validation form submission loop imo.
So, remove the middle concept of "weak but allowed" passwords from the strength indicator widget, I think then you get good UX that meets NIST recommendations..?
> Make sure the form is compatible with password managers.
The number of sites that go out of their way to prevent password managers, well any "paste" mechanisms, is still annoying but are becoming fewer.
Bank account numbers for ACH payments seem to be the final frontier. As if asking me to type 16 numbers correctly is better than pasting it.
The most common reason I get, professionally, is that it "prevents scripting" ... as if hackers are both using Chrome extensions at scale but also can't figure out how to defeat javascript and html form restrictions.
I like the article because it's very similar to the workflow that I developed while working on my first project after quitting my last job. One thing that I would add to "Be Explicit About Your Goal" is that it should be about both your goal and the user's goal. Otherwise it's very easy to hit blind spots that both you, another person, or AI will miss because of bias.
A small related rant is that many large companies with a dedicated team that works on design system don't seem to actually care much about UX. It feels demoralizing because sometimes it feels like many people are just using UX to push some other agenda.
Design must flow from customer demand/desires.
And 90% of design is just "correctly assigning priority" to elements and actions.
If you know what is important (and what is less important) you use...
- white space (more whitespacce = more important)
- dimension (larger = more important)
- contrast (higher = more distinct)
- color (brighter = more important)
... to practically implement the decided priority.
How to validate you have implemented priority correctly?
Just ask a few people what do they see first, second, third, etc in a page.
If you designed it right - their eyes will see things exactly in the order you expected them to.
In short - "design is guiding user's senses in the most prioritized manner to the user in achieving their goals"
In our startup - we call this the "PNDCC" system (priority, negative space, dimension, contrast, color).
There are a few more tricks to make it even more powerful - but as I said - just getting these right puts you in the top 10%
Like... sorry to be That Guy, but maybe just employ / have a team with the right people from the start?
If a designer had a tech startup with no engineers, we'd all be (rightly) sniffy about it.
Imagine this post the other way round: "Hey, designers, here's everything you need to know about engineering and devops and coding in ONE PAGE!". Think about the HN response to this - it'd go down like a ton of hot shit. And rightly so.
I used to work at an educational tech company and they would - without even breaking into a sweat - take one of their engineering team and put them in charge of marketing. Same rule applies - imagine it the other way round, a marketing person with no knowledge of engineering setting the strategy for engineering. (And yes, I know it happens, but when it does we all moan on about it, no...?!)
Long and short: a startup / product without a UX person or designer in it right from the start is likely to be a clusterfuck.
An early startup starts with jack of all trades. If you needed the full team that even a $10m company would have you are probably not a typical early startup.
The reality is marketing is a skill most people can fudge because they have done it. They have gotten jobs, dates and haggled for a free beer before.
Programming is only something freaks do so the average marketer won't code. And if they do the average coding marketer won't make resilient 99% uptime code without subtle bugs.
Hate to circlejerk but man .... programming to produce robust, correct, reliable systems that do something useful is hard. Despite what the AI bros are hot taking on X these days.
Have you ever noticed that some tradespeople do their own books but bookkeepers won't come and fix your AC unit.
Anyway rant over :)
Tailwind + daisyui can get you pretty far. My thinking is, if your start up takes off a real designer can remove all of the daisyui stuff and re-design with only tailwind.
My startup is a non-standard domain targeting the iPad.
Our need for a designer with functional knowledge and creativity is very high.
I’ve muddled through with iterative designs of my own, but this challenge has delayed our beta.
Designers don’t work for equity where nearly every other kind of talent will.
This is a real blocker for startups.
Where do startups typically get their branding done? I'm assuming the VCs usually refer their cohort to the same group of branding agencies? Who are the quick and dirty ones? Do they ever hire direct freelancers? Possibly to save money?
We got our branding guide done through a 99Designs contest. Over the last few years there has been an incredible increase in how many design entries you get per dollar on that platform.
It was definitely worth it, and then we redesigned the website, and now the app based on that branding guide. 10/10 would recommend.
I’m a UX designer and developer at a healthcare fintech startup. We do all our B2C communication design and product UX/UI design in-house with a small team.
But for our B2B site…I can’t name names…one of our investors did refer us to a well-established design agency who does small and medium-scale enterprise branding and marketing. And they did great work. So yes, there are a few ringer VC design agencies out there.
I’m hardly a UI, well, anything.
But I want to point out the application that is used at the Quest Diagnostics lab. The one they use to enter your demographic, lab info, etc. The daily driver for their legion of phlebotomists, at least here in So Cal.
One word. It’s fast. Oh man is it fast. Bunches of fields, bunches of dialog boxes, looks like a Windows back office application. Prints all of the vial tracking labels. These people are trained and know what is coming when.
But, it seems to be in a web browser tab. Perhaps they’re running a RDP tab to a nearby server running some Windows based desktop app, but, again, this app flies. I’ve not seen modern app this fast.
I’d love to know how they are pulling it off.
It takes a designing engineer to startup a touch minefield that User X practically cannot survive without triggering a popup.
As a quick alternative, why not use a freelancer?
OP here - A good freelancer gets you a long way. What I found is that during the development process, people hit edge cases and have questions... doing a lot of the discovery and thinking yourself helps you answer those questions faster.
Alternatively, if you find a freelancer within your budget that can stick with you until the feature is out of the door is a great win.
Dribbble is a great resource IME
Practical UI from Tailwind is a very good guide for this.
Were em-dashes this popular before LLMs?
Or, just hire a good UX designer. Seriously, nobody would think about "practical coding for startups surviving without a programmer."
() Well, with AI coding... who knows...
...or designers could just learn some HTML/CSS/JS instead of using half-measures like Figma that need a FE developer handoff step.
See how that works?
eh. For who want's to get deeper/broader view, there's a "bible" on UX.. called "Usability engineering" by Jakob Nielsen ~1993 [0].
IMO The first 2 (two) chapters are, like, mandatory - the what and the why. The rest, is mostly details - how. (but it has even how to organise random-street-user-tests and what to look for in those, etc)
Although, looking at recent 10 years of (software-or-car) UXs, i feel noone reads these anymore :/ Sadly.
[0] http://www.amazon.com/Usability-Engineering-Interactive-Tech...
http://en.wikipedia.org/wiki/Usability_Engineering
This is good practical advice
One problem we have on our service (genenetwork.org) is stylistic consistency across many different pages and forms. Even one programmer can invent five different ways to close a window or pop-up. Table styles can be annoying diverse.
A style guide is the obvious solution but ……
I turn this into a design one time. Everything had a different Color scheme too. It was oddly usable with the colors setting the mindset.
It depends a lot who the audience is.
1qq
Great try this and see how far it goes ! None of this matters if u don’t find pmf and u don’t need a designer for this. Totally disagree with this. Article started great but then niched out too small with login flows. No startup is reinventing this.
AI is not designing good? How? The tech bros hate artistic minded people.
They hate design because it is the engine of growth and change. Tech bros like sameness and libraries. They love "design patterns".
But change is inevitable and design is not in the colors, fonts, whitespace.
Design is human centered practice for solving not only functional tasks but emotional. And for this there is no Tailwind, React, AI solution, or design patterns template.
PS: I am a designer and frontend engineer with 20+ years practice with my own company and plethora of delivered solutions for my clients. The divide between engineers and designers is the most persistent thing that I have seen in my life.
It is beyond my understanding.
> Design is human centered practice for solving not only functional tasks but emotional
Having worked around design and UX people for a long time, I'd say there are plenty of design people who are practical and don't talk about emotional tasks.
So they are missing a lot. And this is the core of the problem. Emotions are practical. They are a part of human experience. You cannot approach design process as a framework documentation or recipe. Moving with current trends of double diamonds or whatever tools are fashionable. You have to be a generalist first and tap not only to the tech stack or quantitive approach, but also into a psychology and culture.
>Emotions are inseparable from how we humans think, choose, and act. In Emotional Design, cognitive scientist Don Norman shows how the principles of human psychology apply to the invention and design of new technologies and products.
https://shorturl.at/EKhRu