Practical UX for startups surviving without a designer (opens in new tab)

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.

> 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.

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)

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

> 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).

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.

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.

>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.

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.

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

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)

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.

> 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.

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

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.

> 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

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".

> and adopts a pleasing color palette and set of fonts

This is an unfortunate side-effect of confusing apps with web pages. No one hired a designer to pick the fonts and colors for Windows 95, because that was up to the OS ad user.

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.

I'll have to use this, thanks for sharing. Isn't it problematic since Gemini isn't representative of a real user, though?

Very clever. Reminds me of using Alexa to test your pronunciation of foreign words. If Alexa has no idea you probably said it wrong.

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.

I knew it as “The principle of least astonishment”.

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

My favorite cargo cult thing today is that when you’re logged out you can’t find the login link anymore, just “Sign up”.

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.

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.

> 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?

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.

> 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…

Can you share the firm you worked with?

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.

As a non designer this is the same approach I take

5-10x? Are you sure?

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.

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 :)

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.

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

...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?

> 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.

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 ……