[DrewADesign]

Overall, the development world does not intuitively understand the difficulty of creating good interfaces (for people that aren’t developers.) In dev work, the complexity is obvious, and that makes it easy for outsiders to understand— they look at the code we’re writing and say “wow you can read that?!” I think that can give developers a mistaken impression that other peoples work is far less complex than it is. With interface design, everybody knows what a button does and what a text field is for, and developers know more than most about the tools used to create interfaces, so the language seems simple. The problems you need to solve with that language are complex and while failure is obvious, success is much more nebulous and user-specific. So much of what good interfaces convey to users is implied rather than expressed, and that’s a tricky task.

[makeitdouble]

> creating good interfaces (for people that aren’t developers.)

This is the part where people get excited about AI. I personally think they're dead wrong on the process, but strongly empathize with that end goal.

Giving people the power to make the interfaces they need is the most enduring solution to this issue. We had attempts like HyperCard or Delphi, or Access forms. We still get Excel forms, Google forms etc.

Having tools to incrementaly try stuff without having to ask the IT department is IMHO the best way forward, and we could look at those as prototypes for more robust applications to create from there.

Now, if we could find a way to aggregate these ad hoc apps in an OSS way...

[marcus_holmes]

I have nightmare stories to tell of Access Forms from my time dealing with them in the 90's.

The usual situation is that the business department hires someone with a modicum of talent or interest in tech, who then uses Access to build an application that automates or helps with some aspect of the department's work. They then leave (in a couple of cases these people were just interns) and the IT department is then called in to fix everything when it inevitably goes wrong. We're faced with a bunch of beginner spaghetti code [0], utterly terrible schema, no documentation, no spec, no structure, and tasked with fixing it urgently. This monster is now business-critical because in the three months it's been running the rest of the department has forgotten how to do the process the old way, and that process is time-critical.

Spinning up a proper project to replace this application isn't feasible in the short term, because there are processes around creating software in the organisation, for very good reasons learned painfully from old mistakes, and there just isn't time to go through that. We have to fix what we can and get it working immediately. And, of course, these fixes cause havoc with the project planning of all our other projects because they're unpredictable, urgent, and high priority. This delays all the other projects and helps to give IT a reputation as taking too long and not delivering on our promised schedules.

So yeah, what appears to be the best solution from a non-IT perspective is a long, long way from the best solution from an IT perspective.

[0] and other messes; in one case the code refused to work unless a field in the application had the author's name in it, for no other reason than vanity, and they'd obfuscated the code that checked for that. Took me a couple of hours to work out wtf they'd done and pull it all out.

[nradov]

Of course this is ultimately the IT department's own fault for not responding quickly enough to legitimate business requirements. They need to actively look for ways to help rather than processing tickets.

[marcus_holmes]

Yeah, this is always the response. But it's wildly impractical - there are only so many developer hours available. The budget is limited, so not everyone gets what they want immediately. This should be obvious.

Part of the problem is that the novices that create these applications don't consider all the edge cases and gnarly non-golden-path situations, but the experienced devs do. So the novice slaps together something that does 95% of the job with 5% of the effort, but when it goes wrong the department calls in IT to fix it, and that means doing the rest of the 95% of the effort. The result is that IT is seen as being slow and bureaucratic, when in fact they're just doing the fecking job properly.

[nradov]

In most organizations the problem is lack of urgency rather than lack of developer hours. The developers sit in isolated siloes rather than going out and directly engaging with business units. This is mostly a management problem but there are plenty of individual developers who wait to be told what to do rather than actively seeking out better solutions for business problems.

[marcus_holmes]

This usually comes back to maker time vs manager time.

If you want a developer to write good code quickly, put them in an isolated silo and don't disturb them.

If you want a developer to engage with the business units more, be prepared for their productivity to drop sharply.

As with all things in tech, it's a trade-off.

[scott_w]

> In most organizations the problem is lack of urgency rather than lack of developer hours.

I disagree: it's a business prioritisation issue (not necessarily a problem). Ultimately, a lot of the processes are there because the wider business (rightly) wants IT to work on the highest impact issues. A random process that 3 people suffer from probably isn't the highest impact for the business as a whole.

Also, because it's not high impact, it makes sense that an intern is co-opted to make life easier (also as a learning experience), however it also causes the issues OP highlighted.

The problem is solvable, I think, but it's not easily solvable!

[listenallyall]

> wildly impractical - there are only so many developer hours available

Which is a huge reason that learning a RAD (rapid application development - emphasis on rapid) tool is a pretty useful skill.

[bccdee]

What makes it rapid is taking shortcuts. There's no silver bullet for increasing speed while preserving maintainability and extensibility. Prioritizing speed is exactly the problem described in the post you're responding to.

[RobotToaster]

Which is ultimately the c-suite's fault for not requiring that and allocating a budget for it.

[nradov]

Nah. It's usually a culture and organizational structure problem, not a budget problem.

[chasd00]

This has been my experience. Usually a department gets nowhere for months dealing with IT and then goes shopping for consultants. I make my living bringing things online for directors and other biz leadership who just couldn’t get IT off their ass.

[ozim]

Downside is that it quickly turns to idea people coming over directly to dev team pushing BS ideas and requiring work to be done on that ASAP.

You need a structure if you have org of 100+ employees. If it is smaller than that I don’t believe you get dev department.

[loki-ai]

more often than not it’s the development team that skips engaging with users, putting in minimal effort to understand their real needs.

most of these teams only wants a straightforward spec, shut themselves off from distractions, just to emerge weeks or months later with something that completely misses the business case. and yet, they will find ways to point fingers at the product owner, project manager, or client for the disaster.

[marcus_holmes]

I have met the occasional person like this, sure. But only ever in really large organisations where they can hide, and only a minority.

The huge majority of devs want to understand the business and develop high quality software for it.

In one business I worked for, the devs knew more about the actual working of the business than most of the non-IT staff. One of the devs I worked with was routinely pulled into high-level strategy meetings because of his encyclopaedic knowledge of the details of the business.

[TeMPOraL]

The mistake is in trying to understand the business case. There is nothing to understand! The business case is the aggregate of what people actually do. There is no proper procedure that's actually followed at the ground level. Workflows are emergent and in constant flux. In this environment, the role of a dev should not be to build internal products, but to deliver internal hacks and ad-hoc solutios, maintain them, modify on the fly, and keep it all documented.

I.e. done right, it should be not just possible but completely natural for a random team lead in the mail room to call IT and ask, "hey, we need a yellow highlighter in the sheet for packages that Steve from ACME Shipping needs to pick on extra evening run, can you add it?", and the answer should be "sure!" and they should have the new feature within an hour.

Yes, YOLO development straight on prod is acceptable. It's what everyone else is doing all the time, in every aspect of the business. It's time for developers to stop insisting they're special and normal rules don't apply to them.

[skydhash]

It would be nice if the computers could be that nice to work. It’s a completely dumb machine that needs everything spelled out. Humans are very flexible. To get flexibility out of a computer require great effort.

The main reason you want a computer is cheap emulation (cad, daw,…) or fast (and reliable) automation. Both requires great deal of specifications to get right.

[bccdee]

The thing about that is that you can only ever YOLO the superficial layers of your architecture, and only ever in certain ways. Having a YOLOable system requires deliberate and considered architectural choices deeper down.

[HeyLaughingBoy]

An hour is a stretch, but otherwise, yeah.

[savolai]

And yet, even ”knowing about the working of the business” is different from actually understanding user needs at UI level, which involves a lot more variables.

The single most valuable tool is user testing. However it really takes quite a few rounds of actually creating a design and seeing how wrong you saw the other person’s capabilities, to grok how powerful user testing is in revealing your own biases.

And it’s not hard at all at core. The most important lesson really is a bit of humility. Actually shutting up and observing what real users do when not intervened.

Shameless plug, my intro to user testing: https://savolai.net/ux/the-why-and-the-how-usability-testing...

[swader999]

This legit triggered me. I'm thirty years in now and only two failed projects. My first paid work was an access project for a small business and it failed and I didn't get paid. Luckily I kept trying.

[GTP]

> Spinning up a proper project to replace this application isn't feasible in the short term, because there are processes around creating software in the organisation, for very good reasons learned painfully from old mistakes, and there just isn't time to go through that.

I assume those processes weren't applied when deciding to use this application, why? Was there a loophole because it was done by an intern?

[dspillett]

Simple things, or even complex prototypes, get created in office apps because the office apps are their, have the flexibility, and you don't need to get IT to install something new (or allow you to), or convince finance to let you pay for something new, or convince compliance/security/other than the something new is safe anyway, etc. Also in a larger company, once the discussion of developing or buying something comes up lots of other potential stakeholders might raise their heads above the parapet and want to get involved (“Could our dept use this too?”, “We would need it to do Y as well as X…”, “That sounds useful, but it should be us doing it instead”, etc.), and suddenly the quick PoC that has been barely started has become a series of interminable meetings.

The loophole is that if you have Office or similar you have a variety of development environment, IT/compliance/finance aren't caring what files you produce with the applications you have, and no one else is paying attention initially either, but would have a say (and a procedure for you to follow) if you wanted to bring in or create a new application. The usual process is bypassed.

This is more commonly associated with Excel, but it applies to Access too (less so than it used to, but there are still plenty people out there who rely on it daily).

Once the demo/prototype/PoC is there it is a lot easier to “fix up” that than spin up a project in anything else, or get something else in that is already available, for the same reasons as why it was done in Excel/Access in the first place plus the added momentum: the job is already at least part way done, using something else would be a more complete restart so you need to justify that time as well as any other costs and risks.

[Note: other office suites exist and have spreadsheets & simple DBs with similar capabilities, or at least a useful subset of them, of course, but MS Office's Excel & Access are, for better or worse, fairly ubiquitous]

[rob74]

Well, if someone (especially an intern) who is not in the IT department decides to write an application, it's pretty obvious that they are not familiar with (and therefore won't follow) the processes of the IT department. That's the problem with these more "democratic" development environments: if something is beginner-friendly, beginners will use it...

[jyounker]

Another point of view is that the IT department isn't meeting the users' needs, and that they're bypassing IT because they just want to get their work done.

[GTP]

Yes, the intern will not follow the procedure, and likely isn't even technically required to do so. But, before the application becomes a tool actually used inside the company, there should be some quality control done.

[listenallyall]

Think of the management structure which arranges, and is satisfied with, tedious, repetitive, manual paper-pushing processes - such that an INTERN can immediately see the efficiency benefits that would come with automation, and doesn't just suggest doing so, but actually builds a program (in limited intern timeframe), that is so helpful it's quickly picked up by multiple employees.

Then think again of those managers getting paid manager salaries who couldn't figure this out themselves - or worse, the ones who want to shut it all down because he didn't "follow the procedure" (the procedure of not doing anything useful???)

[makeitdouble]

> The usual situation is that the business department hires someone with a modicum of talent or interest in tech

This reminds me of the "just walk confidently to their office and ask for a job to get one!" advice. This sounded bullshit to me until I got to stay with some parts of a previous company, where the hiring process wasn't that far really.

That's also the kind of companies where contracts and vendor choices will be negociated on golf courses and the CEO's buddies could as well be running the company it would be the same.

I feel for you.

[listenallyall]

Imagine taking a shit on a technology platform which made it easy for interns with zero experience to successfully automate key aspects of business processes!

Love the assumption "when it inevitably goes wrong." In real life, many of these applications work perfectly for years and assist employees tremendously. The program doesnt fail, but the business changes - new products, locations, marketing, payment types, inventory systems, tons of potential things.

And yes, after the original author is gone, nobody is left to update the program. Of course, a lot of programmers or IT folks probably could update it, but ew, why learn and write Access when we can create a new React app with microservices-based backend including Postgres in the cloud and spin up a Kubernetes cluster to run it.

[pjmlp]

Delphi and Access are pretty much still around, even if they are seldom reason of a HN front page post.

[finghin]

It’s also about keeping things simple, hierarchical, and very predictable. These do not go hand in hand with the feature creep of collaborative FOSS projects, as others point out here.

[hombre_fatal]

Good point. A good interface usually demands a unified end-to-end vision, and that usually comes from one person who has sat down to mull it over and make a bunch of good executive decisions.

And then you need to implement that, which is never an easy task, and maintain the eternal vigilance to both adhere to the vision but also fit future changes into that vision (or vice versa).

All of that is already hard to do when you're trying to build something. Only harder in a highly collaborative voluntary project where it's difficult or maybe even impossible to take that sort of ownership.

[LtWorf]

> Overall, the development world does not intuitively understand the difficulty of creating good interfaces

Nor can the design world, for that matter. They think that making slightly darker gray text on gray background using a tiny font and leaving loads of empty space is peak design. Meanwhile my father cannot use most websites because of this.

[DrewADesign]

The dozens of people I know that design interfaces professionally can probably recite more of the WCAG by heart than some of the people that created them. You’re assuming that things you think “look designed” were made by designers rather than people playing with the CSS in a template they found trying to make things “look designed.” You’re almost certainly mistaken.

[eviks]

> can probably recite more of the WCAG by heart than some of the people that created them

That's part of the problem, they'll defend their poorly visible choice by lawyering "but this meets the minimal recommended guideline of 2.7.9"

[DrewADesign]

Find a validator and try to make a text color selection that meets wcag guidelines which doesn’t have contrast high enough to read it perfectly easily. The criteria are not ambiguous and they’re not scraping the visibility barrier.

[pseudalopex]

No. I worked with designers who designed low contrast and low density interfaces. I read articles written by designers. I used products of companies like Apple.

[DrewADesign]

Examples? Are they interface designers? Are they qualified? The existence of shitty designers is no more an impeachment of any design field or designers as the existence of shitty developers is an impeachment of development or developers.

[LtWorf]

I think at this point the existence of good designers is what needs proof.

[DrewADesign]

Edgy.

[hn_acc1]

As I age, this x1000. Even simple slack app on my windows laptop - clicking in the overview scroll bar is NOT "move down a page". It seems to be "the longer you click, the further it moves" or something equally disgusting. Usually, I dock my laptop and use an external mouse with wheel, and it's easy to do what I want. With a touchpad? Forget it.. I'm clicking 20x to get it to move to the top - IF I can hit the 5-pixel-wide scrollbar. There's no easy way to increase scrollbar size anymore either..

It's like dark patterns are the ONLY pattern these days.. WTF did we go wrong?

[BobbyTables2]

Indeed.

Win95 was peak UI design.

I don’t understand modern trends.

[LtWorf]

I created localslackirc to keep using IRC and not have to deal with slack :D

[fragmede]

With a touchpad? Use two fingers to scroll (also works horizontally). Who's managing to hit a tiny scrollbar that disappears with a touchpad‽

[mjevans]

They just aren't as good at detecting real physical contact as a nice physical mouse is at responding to movement and pressure.

[fragmede]

I mean, maybe but the question wasn't what is the superior general pointing device (trackball ftw if you ask me) though, but how to scroll using a trackpad without tearing your hair out.

[BobbyTables2]

What pisses me off is that the “brutalist” style in the 1990s was arguably perfect. Having standardized persistent menus, meaningful compact toolbars was nice.

Then the world threw away the menus, adopted an idiotic “ribbon” that uses more screen real estate. Unsatisfied, we dumbed down desktop apps to look like mobile apps, even though input technology remains different.

Websites also decided to avoid blue underlined text for links and be as nonstandard as possible.

Frankly, developers did UI better before UI designers went off the deep end.

[zeroc8]

The brutalist style also meant that I didn't need a UI designer for my applications. With Delphi I was able to create great apps in a matter of days. And users loved them, because they were so snappy and well thought out. Nowadays it seems I need a UI designer to accomplish just about anything. And the resulting apps might look better but are worse when you are actually trying to accomplish work using them.

[DrewADesign]

Actual interface designers communicate functionality and state through an interface. If your designer is designing interfaces that look good but are less functional for the intended user base, you’ve hired a graphic designer that claims to be an interface designer. It’s not a problem you can generalize to design or designers any more than someone can generalize that web developers suck because the ones they hire to build a serious web app are really Wordpress plugin hacks that don’t even realize they aren’t web developers.

[sjamaan]

I was ranting exactly the same just yesterday. Nowadays UI designers seem to have forgotten all about affordances. Back in the day you had drop shadows below buttons to indicate that they could be pressed, big chunky scrollbars with two lines on the handle to indicate "grippiness" etc.

A few days ago I had trouble charging an electric rental car. When plugging it in, it kept saying "charging scheduled" on the dash, but I couldn't find out how to disable that and make it charge right away. The manual seemed to indicate it could only be done with an app (ugh, disgusting). Went back to the rental company, they made it charge and showed me a video of the screen where to do that. I asked "but how on earth do you get to that screen?". Turned out you could fucking swipe the tablet display to get to a different screen! There was absolutely no indication that this was possible, and the screen even implied that it was modal because there were icons at the bottom which changed the display of the screen.

So you had: zero affordances, modal design on a specific tab, and the different modes showed different tabs at the top, further leading me to believe that this was all there was.

[LtWorf]

I've had long discussions at work with our designer, who thinks that people on desktop computers should perform swipe actions with the mouse rather than the UI reacting to mouse scroll events.

99% of the users are not using the mobile version.

[DrewADesign]

Get a new designer. You have hired a graphic designer that thinks they’re an interface designer. They’re wrong.

[dhosek]

In the 90s I did a tech writing gig documenting some custom software a company had built for them by one of the big consultancy agencies. It was a bit of a nightmare as the functionality was arranged in a way that reflected the underlying architecture of the program rather than the users’ workflows. Although I suppose if they’d written the software well, I wouldn’t have had as many billable hours writing documentation.

[sublinear]

> reflected the underlying architecture of the program rather than the users’ workflows

Is this an inherently bad thing if the software architecture is closely aligned with the problem it solves?

Maybe it's the architecture that was bad. Of course there are implementation details the user shouldn't care about and it's only sane to hide those. I'm curious how/why a user workflow would not be obviously composed of architectural features to even a casual user. Is it that the user interface was too granular or something else?

I find that just naming things according to the behavior a layperson would expect can make all the difference. I say all this because it's equally confusing when the developer hides way too much. Those developers seem to lack experience outside their own domain and overcomplicate what could have just been named better.

[DrewADesign]

Developers often don’t think it’s a bad thing because that’s how we think about software. Regular users think about applications as tools to solve a problem. Being confronted by implementation details is no problem for people with the base knowledge to understand why things are like that, but without that knowledge, it’s just a confusing mess.

[StrauXX]

If you ever spens time with the low level SAP GUIs, then yes, you will find out why that's definetly a bad thing. Software should reflect users processes. The code below is just an implementation detail and should never impact the design of the interfaces.

[ozgrakkurt]

IMO they just don’t care enough. They want people to use it but it is not the end of world if it stays niche

[max51]

>Overall, the development world does not intuitively understand the difficulty of creating good interfaces

I think it's because they are not using the product they are designing. A lot of problems you typically see in modern UIs would have been fixed before release if the people writing it were forced to use it daily for their job.

For example, dropdown menus with 95 elements and no search/filter function that are too small and only allow you to see 3 lines at a time.

[DrewADesign]

There’s a real difference in usage style between developers and most other users. Having the background knowledge to understand what’s going on behind the curtain makes it easy to deal with things like interactive visual complexity, tons of data and moving parts at the same timetime, implementation warts, etc.

[hilong2]

One thing I still struggle with is writing interfaces for complex use cases in an intuitive and simple manner that minimizes required movements and context switching.

Are there any good resources for developing good UX for necessarily complex use cases?

[tastyfreeze]

I am writing scheduling software for an uncommon use case.

The best method I have found is to use the interface and fix the parts that annoy me. After decades of games and internet I think we all know what good interfaces feel like. Smooth and seamless to get a particular job done. If it doesn't feel good to use it is going to cause problems with users.

Thats said. I see the software they use on the sales side. People will learn complexity if they have to.

[DrewADesign]

Honestly, it’s a really deep topic — for a while I majored in interface/interaction design in school— and getting good at it is like getting good at writing. It’s not like amateurs can’t write solid stories, but they probably don’t really understand the decisions they’re making and the factors involved, and success usually involves accidentally being influenced by the right combination of things at the right time.

The toughest hurdle to overcome as a developer is not thinking about the gui as a thin client for the application, because to the user, the gui is the application. Developers intuitively keep state in their head and know what to look for in a complex field of information, and often get frustrated when not everything is visible all at once. Regular users are quite different— think about what problems people use your software to solve, think about the process they’d use to solve them, and break it down into a few primary phases or steps, and then consider everything they’d want to know or be able to do in each of those steps. Then, figure out how you’re going to give focus to those things… this could be as drastic as each step having its own screen, or as subtle as putting the cursor in a different field.

Visually grouping things, by itself, is a whole thing. Important things to consider that are conceptually simple but difficult to really master are informational hierarchy and how to convey that through visual hierarchy, gestalt, implied lines, type hierarchy, thematic grouping (all buttons that initiate a certain type of action, for example, might have rounded corners.)

You want to communicate the state of whatever process, what’s required to move forward and how the user can make that happen, and avoid unintentionally communicating things that are unhelpful. For example, putting a bunch of buttons on the same vertical axis might look nice, but it could imply a relationship that doesn’t exist. That sort of thing.

A book that helps get you into the designing mindset even if it isn’t directly related to interface design is Don Norman’s The Design of Everyday Things. People criticize it like it’s an academic tome — don’t take it so seriously. It shows a way of critically thinking about things from the users perspective, and that’s the most important part of design.

[angiolillo]

> any good resources for developing good UX for necessarily complex use cases?

For teasing apart complex workflows I'd suggest Holtzblatt and Beyer's Contextual Design book, I taught a user-centered research and design class many years ago and used that as our textbook, hopefully it still holds up.

For organizing complex applications I like to start with affinity diagrams, card sorts, and collaborative whiteboard sessions. And of course once you have a working prototype, spend as much time as possible quietly watching people interact with your software.

[DrewADesign]

I haven’t read that book. Thanks for the rec

[zahlman]

> I think that can give developers a mistaken impression that other peoples work is far less complex than it is.

Not at all. Talented human artists still impress me as doing the same level of deep "wizardry" that programmers are stereotyped with.

[DrewADesign]

That might be the case for you, but something doesn’t need to be universally true for it to be true enough to matter. Find any thread about AI art around here and check out how many people have open contempt for artists’ skills. I remember the t-shirts I saw a few sys admins wearing in the nineties that said “stop bothering me or I’ll replace you with a short shell script.” In the decades I worked in tech, I never saw that attitude wane. I saw a thread here within the past year or two where one guy said he couldn’t take medical doctors and auto mechanics seriously because they lacked the superior troubleshooting skills of a software developer. Seriously. That’s obviously not everybody, but it’s deeefinitely a thing.

[lukan]

I believe it comes from low self esteem initially. Then finding their way into computers, where they then indeed have higher skills than average and maybe indeed observed that the job of some people could be automated by a shell script. So ... lots of ungrounded ego suddenly, but in their new guru ego state, they extrapolated from such isolated cases to everywhere.

I also remember the hostility of my informal universities IT chat groups. Newbs were rather insulted for not knowing basic stuff, instead of helping them. A truly confident person does not feel the need to do that. (and it was amazing having a couple of those persons writing very helpful responses in the middle of all the insulting garbage)

[RobotToaster]

> Find any thread about AI art around here and check out how many people have open contempt for artists’ skills.

I don't think that's entirely true, what I usually see is people that think AI art is just as good as many artists.

You can be impressed by something and still think a machine can do it just as well. People that can do complex mental arithmetic are impressive, even if that skill is mostly obsolete by calculators.

[cenamus]

Trust me, there are enough people here that believe that.

Other engineering disciplines are simpler because you can only have complexity in three dimensions. While in software complexitiy would be everywhere.

Crazy to believe that

[analog31]

There are many more than three "dimensions" if I may use the term loosely, in software or hardware engineering.

Cost, safety, interaction between subsystems (developed by different engineering disciplines), tolerances, supply chain, manufacturing, reliability, the laws of physics, possibly chemistry and environmental interactions, regulatory, investor forgiveness, etc.

Traditional engineering also doesn't have the option of throwing arbitrary levels of complexity at a problem, which means working within tight constraints.

I'm not an engineer myself, but a scientist working for a company that makes measurement equipment. It wouldn't be fair for me to say that any engineering discipline is more challenging, since I'm in none of them. I've observed engineering projects for roughly 3 decades.

[cenamus]

I think the poster literally meant x, y and z in terms of dimension

[swader999]

The top three are typically quality, budget and time. Usually a compromise is needed on one of these. You could replace quality with features in SW dev.

[nradov]

Scope is more of a dimension than quality. In theory it might be possible to accept lower quality in order to cut the budget or accelerate the time but in practice that doesn't seem to work. Any significant reduction in quality usually causes the project to grind to a halt after the prototype stage. You just can't build any new features when everything is broken.