[HN Gopher] Practical UX for startups surviving without a designer
___________________________________________________________________
Practical UX for startups surviving without a designer
Author : tb8424
Score : 366 points
Date : 2025-03-12 22:32 UTC (1 days ago)
(HTM) web link (www.tibinotes.com)
(TXT) w3m dump (www.tibinotes.com)
| dave_sid wrote:
| 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.
| jbs789 wrote:
| 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...
| yapyap wrote:
| 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.
| dave_sid wrote:
| There may be a reason for it, but best to understand what
| that reason is before applying the same approach.
| nsxwolf wrote:
| My favorite cargo cult thing today is that when you're logged
| out you can't find the login link anymore, just "Sign up".
| dunham wrote:
| Yeah this one is really frustrating.
| Ensorceled wrote:
| 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.
| mekoka wrote:
| 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.
| danenania wrote:
| 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.
| mamcx wrote:
| > 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.
| asoneth wrote:
| > 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?
| levlaz wrote:
| This is good practical advice
| robwwilliams wrote:
| 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 ......
| theendisney wrote:
| 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.
| stared wrote:
| 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.
| sebastiennight wrote:
| 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.
| tb8424 wrote:
| I echo on the "The Design of Everyday Things" making you
| perpetually dissatisfied.
|
| Thanks for the second rec, I'll give it a go
| alphazard wrote:
| 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.
| staplers wrote:
| 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".
| caseyohara wrote:
| > 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
| re-thc wrote:
| > 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.
| noduerme wrote:
| 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.
| JoeyJoJoJr wrote:
| 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.
| re-thc wrote:
| > 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.
| LoganDark wrote:
| 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.
| noduerme wrote:
| 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.
| hnthrow90348765 wrote:
| Make them learn coding instead of adding yet another
| responsibility onto developers.
| whstl wrote:
| 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.
| danielmarkbruce wrote:
| 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.
| hombre_fatal wrote:
| 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.
| sizzle wrote:
| 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.
| breadwinner wrote:
| 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!
| potatoman22 wrote:
| I'll have to use this, thanks for sharing. Isn't it problematic
| since Gemini isn't representative of a real user, though?
| willsmith72 wrote:
| Definitely a huge trap to replace real user insights with
| anything else.
|
| But this looks like a nice level 0 of testing
| CaffeineLD50 wrote:
| 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.
| gffrd wrote:
| 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.
| cpeterso wrote:
| 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/
| Tepix wrote:
| More consistent? That's not a given with LLMs unless you
| set the temperature to 0.
| CaffeineLD50 wrote:
| Very clever. Reminds me of using Alexa to test your
| pronunciation of foreign words. If Alexa has no idea you
| probably said it wrong.
| dustbunny wrote:
| 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?
| perardi wrote:
| 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.
| sebastiennight wrote:
| 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.
| osigurdson wrote:
| 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.
| codr7 wrote:
| 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.
| cryptozeus wrote:
| 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.
| atomicnature wrote:
| 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%
| hliyan wrote:
| 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.
| 998244353 wrote:
| > 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.
| hliyan wrote:
| 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.
| arkh wrote:
| 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.
| dylan604 wrote:
| > 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.
| whstl wrote:
| 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.
| dylan604 wrote:
| 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.
| whstl wrote:
| 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.
| dylan604 wrote:
| TFA is about _not_ having a designer. If you have a bad
| designer, then fix that glitch.
| whstl wrote:
| 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.
| andrepd wrote:
| > Visually appealing, sure.
|
| It's not even.
| whstl wrote:
| 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.
| rojcyk wrote:
| 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.
| sokratus wrote:
| > 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.
| conductr wrote:
| 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)
| nostrademons wrote:
| 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.
| hinkley wrote:
| 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.
| conductr wrote:
| 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
| DidYaWipe wrote:
| 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.
| arkh wrote:
| > 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.
| loeber wrote:
| 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
| troupo wrote:
| Not just web design. Design, period. Here's what Apple is
| producing these days:
| https://x.com/dmitriid/status/1899392713323147633
| dlivingston wrote:
| 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.
| psadri wrote:
| 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.
| su8898 wrote:
| 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).
| nostrademons wrote:
| 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.
| Kwpolska wrote:
| 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.
| guappa wrote:
| 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.
| hliyan wrote:
| 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.
| dmix wrote:
| 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.
| savolai wrote:
| "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.
| swesour wrote:
| > 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.
| edu wrote:
| 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.
| rich_sasha wrote:
| 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.
| eviks wrote:
| > 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
| dacryn wrote:
| 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.
| eviks wrote:
| 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
| nextts wrote:
| 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.
| masfuerte wrote:
| 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?
| intrasight wrote:
| > backward compatible to the Stone Age
|
| Like Emacs. And myself ;)
| mfld wrote:
| > 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.
| dchest wrote:
| 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...
| SecretDreams wrote:
| > 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!
| asoneth wrote:
| > 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)
| throwaway24124 wrote:
| 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.
| asoneth wrote:
| > 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.
| gedy wrote:
| 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.
| MetaWhirledPeas wrote:
| 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.
| myth2018 wrote:
| 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.
| DidYaWipe wrote:
| 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.
| seanwilson wrote:
| > 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).
| wvbdmp wrote:
| > 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.
| seanwilson wrote:
| 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.
| LoganDark wrote:
| > 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.
| squeedles wrote:
| 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
| robertlagrant wrote:
| > 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.
| bewo001 wrote:
| 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)
| CalRobert wrote:
| I desperately miss keyboard mnemonics.
| harrison_clarke wrote:
| 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)
| hakaneskici wrote:
| 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.
| kccqzy wrote:
| 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.
| jayd16 wrote:
| 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.
| mbar84 wrote:
| 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.
| jmathai wrote:
| 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
| Tepix wrote:
| As a quick alternative, why not use a freelancer?
| conductr wrote:
| Dribbble is a great resource IME
| tb8424 wrote:
| 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.
| sebastiennight wrote:
| 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.
| h4ny wrote:
| 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.
| karhuton wrote:
| 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.)
| noduerme wrote:
| 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.
| nextts wrote:
| Would you call that role "customer success"?
| karhuton wrote:
| 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.
| mediumsmart wrote:
| It takes a designing engineer to startup a touch minefield that
| _User X_ practically cannot survive without triggering a popup.
| kskjfjfkdkska wrote:
| > 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
| looperhacks wrote:
| 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
| erinaceousjones wrote:
| 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..?
| Ensorceled wrote:
| > 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.
| patja wrote:
| 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.
| Ensorceled wrote:
| 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.
| seanwilson wrote:
| > 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.
| ZoomZoomZoom wrote:
| 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.
| nextts wrote:
| 5-10x? Are you sure?
| ZoomZoomZoom wrote:
| 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.
| dmje wrote:
| 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.
| nextts wrote:
| 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 :)
| devops000 wrote:
| Practical UI from Tailwind is a very good guide for this.
| darkstarsys wrote:
| 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...
| rchaud wrote:
| ...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?
| CharlieDigital wrote:
| That was a lot of words to say "Jakob's Law"[0]
| "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."
|
| [0] https://lawsofux.com/jakobs-law/
| rchaud wrote:
| 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.
| CharlieDigital wrote:
| > 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.
| rchaud wrote:
| 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.
| CharlieDigital wrote:
| 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.
| rchaud wrote:
| 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")
| ChicagoDave wrote:
| 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.
| whartung wrote:
| 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.
| svilen_dobrev wrote:
| 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
| nbzso wrote:
| 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.
| robertlagrant wrote:
| > 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.
| StevenNunez wrote:
| Were em-dashes this popular before LLMs?
| majoe wrote:
| 1qq
| cmgriffing wrote:
| > 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?
___________________________________________________________________
(page generated 2025-03-13 23:01 UTC)