Hacker News Reader

The issue is that step 2 is wrong. Step 1 is to make a design, step 2 is to test it. Make a paper prototype and have your customer simulate working with it. If you feel fancy make a pretty prototype in Figma.

If you have a good designer and cooperative costumer you can even combine step 1 and 2 with a whiteboard prototype. Ask the customer what a common task is. Draw the interface the whiteboard and ask the consumer where they would click or interact, then draw the next UI state, and so on.

After a couple rounds of iterating that way you can start writing actual code. You will still need a couple iterations once people can try the actual software but you will have a much better starting point

> The issue is that step 2 is wrong ... step 2 is to test it.

But of course the best and only real way to test it is to test the real thing...so build it. Back to step 2. :-/

Recurring theme in pre-press: get the texts, get everybody to proof-read the texts, get customer sign off, do on-screen proofs of the layout, everyone signs off, do print-proofs, do proof-printer proofs, do a press-run. Everybody signs off. Print run of 120000 copies. Typo in first sentence on first page, present all the way back.

My idea is to make building real things about as cheap as creating a click-dummy or paper prototype. How's the old saying? "The merely difficult we do immediately, the actually impossible might take a while" ;-)

I think these kind of tasks where many people are asked to review but nobody owns it are the problem. One assumes others reviewed it and then they might review them superficially.

You could give $100 per typo found and I bet that first page would be caught.

The problem is that it isn't their job to review it. They have their own deadlines, and their effort reviewing your prototype won't show up on their performance review.

Unfortunately, superficial feedback like typos are the least valuable feedback possible when creating a new design. What you really want to know is whether the design is actually feasible, if it introduced new pain points, if it is better than what it is going to replace. That's the sort of thing people will notice internally but not necessarily give voice to when they spend three minutes glancing at a prototype or initial build.

Not really, no.

It's that we humans are really, really bad at reviewing something carefully that we know is not the "real" thing.

Not just step 2, step one is to gain a clear understanding of user needs, different use cases, possible flows...

Now you're taking the whole design and development process and calling it "step 1", creating that parody "Waterfall" system.

I don't understand how you understood gathering information as design and development?

If you have no idea what you want to do you are just "vibe" designing and coding.

Starting with gathering information doesn't mean you can't have an iterative process, where you gain a better understanding with each cycle.

>The issue is that step 2 is wrong.

Step 1 could even be wrong if making detailed drawings turns out to be wasting time by making detailed drawings :\

But OTOH you could say up until step 14 it's not as disappointing as it could be.

Then it ends with the devs being pissed, that's probably why it's only 2.5 instead of the full 3.0 :)

There is an alternative ending but you would have to be a whole lot more optimistic.

13. Nobody’s happy. But nobody hates it.

14. That's better'n They Do Not Love It innit?

15. Progress is being made.

16. The devs are energized for more.

17+. . .

Next round a couple people love it. But just a couple.

Do over again, and almost everybody is happy.

One more time and you've really got something there!

~35+. Champagne 6.0 showered on devs.

It could happen . . .

I'd add that you have to be careful with this approach that you don't just outsource the design to the customer.

Customers give valuable feedback, but it's rarely a good idea to implement their ideas as-is. Usually you want to carefully consider problems/friction/frustration that they bring up, but take their suggested solutions with a grain of salt.

This can be harder than it sounds, because customers who give the best feedback are often very opinionated, and you naturally want to "reward" them by including exactly what they ask for.

Yeah, step 1 is wrong too. The article goes into that.

You can't design an interface based on a partial feature-set, you need full interaction modes specified beforehand. You can't finish the details before you implement it, or even before you test. You can't have a committee of "everyones" to like it before you test.

Combining the steps isn't something "you can do", it's the one way that works.

* Step 2: design is "tested" with the users, later we find out the users really had no idea what was going on because they weren't really paying attention. Then the real product is delivered and they are shocked that the changes were made behind their back and without their input.

UX is hard. What usually happens is that you have:

- developers who are bad at UX writing the software and improvising with all the use cases that were not adequately specified in the design document

- end users who are bad at UX giving their input, but can tell when something feels right for their use case

- managers/spec writers who are bad at UX and are trying to translate the wishes of end users to the developers

The result is a worthless spec, garbage in, garbage out.

Sometimes, when the stars align, in your team you get someone who is actually good at UX. I am told this happens, because in my career I have never seen such a unicorn. And even in that case, the end user with no understanding of UX, the one that actually pays for the project, might really, really want that periwinkle blue button, so in pretty much all cases GUIs get through countless rewrites and tweaks.

I've found that most teams are hesitant to show backend code, API calls, etc. during demos.

Screw that! Show your product owner and stakeholders the complexity of the backend _in conjunction_ to the ease of the front end.

The underlying note is "here is what you'll do manually and without support if you don't want the UX as it is now."

Showing the code won't do anything for non-technical people. They'll nod along politely and file it under "they did the job they were hired for".

Plus, it feels a little too passive-agressive to me.

I think of these steps as: designed by project managers who don't understand the user's work situation and don't understand the technology.

> customer team hire a semi-technical fresh grad

This is a person with two legs, one in each camp. This is the optimal solution and beats any one legged person.

It's unfortunate that so many organizations just don't like two legged people, they want you to go into a single box.

>I think the real issue with GUIs: You have technical people building something (mostly) for non-technical people.

As a disgruntled power user, I think we have more of the exact opposite problem: the 'common denominator' users are driving interfare development toward oversimplicity. We have good software which continually undergoes translation into the GUI-equivalent of New-Speak. No please, I beg of you: don't spuritually reduce your program to some singular green [GO!] button! KDE 3.5 > 4+, GNOME 2 > 3+. Mozilla with a long habit of option removal (rivaled by GNOME project). If today's interface designers were in control 60 years ago, we would never have the Unix paradigm (it would be "too complicated" lol).

There should be a bit of elitism in this. Some things are hard to do, not all software should turn all hard things into 'easy', 'simplified', singular [GO!] buttons.

I refer to it as "designed by programmers". It's so prevalent that the Silicon Valley TV show used this as one of it's story lines.

When I worked for a consultancy in early internet days I also often repeated "the customer doesn't know what they want until they see what they don't want". People weren't used to web GUIs and there weren't the common patterns we see today, so it wasn't until they had a half working version they could actually give feedback, so getting early feedback was essential to reduce the frustrating of building something that is immediately changed. It still applies today but less to do with usage patterns and more to do with missing requirements the customer forgot to tell you about.

Conversely, I've seen way too many designed-by-designers GUIs and UX flows that can be best characterized as a glittery, polished turd. They sure look nice in Figma but often only have one well-specified happy path from which the end user will surely deviate. Managers will easily greenlight broken designs because they can only see the visuals, not the complete picture.

If you find a talented designer, they are valued so much they will only get assigned to design tasks. If you have a rockstar 10x developer, their mind just cannot comprehend the average 0.1x end user.

What you need is someone who understands design but dislikes it enough to not focus on aligning single pixels or fixing the kerning. They need to be able to code but hate it with passion, because hard-working programmers create software for hard-working end users and the end user is not hard-working.

That's because "UX" designers need to build according to actual usability engineering guidelines, not just built what "looks good". The 1995-2005 feels like it was the golden decade of this sort of thing.

The whole damn point of calling it "UX" instead of "UI" is to stress that "looks good" is not actually the important part.

I'd argue that this failed though because UX really just means "design for maximum engagement".

Which means "keep the time between them using the UX and opening their wallet to a minimum" because that's the only place businesses care.

No one is building a delightful UX for running IR spectrometers.

It is really SEX. Shareholder's Equity Experience.

And yet, at least in my personal experience, it is only since i started hearing the term UX that i felt UIs started going downhill :-P

A lot of UIs are made to get a promotion. Others are made by numerical optimization of the funnel, which is even worse. The best UIs come from incorporating lots of actual user feedback, and then it almost doesn't matter if they're built by programmers or designers.

The "one happy path" idea is what you want, though. Non-technical users use software through rote muscle memory (it's why in 25 years as a sysadmin I've had thousands of "there was an error message" reports and precisely 0 of those people actually read the error message to report it to me: not in the happy path means user simply shuts down).

The problem becomes that people try to make software too complicated to have one happy path. This is the road to perdition.

An error message is an automated bug report for the developer. I don't know why you think the user is supposed to care about it, or even see it. Are you paying the user to develop the software?

> "the customer doesn't know what they want until they see what they don't want".

like all good NP-complete problems, the issue of making a good GUI is verifiable easily by a customer, but they cannot tell you what a good GUI is.

I think there's a figure mostly absent in these processes. Designers and devs are living in their bubble/silo and don't think like a user.

It's very rare to find someone who can understand design, UX, and code and put it all together into a cohesive vision. In my experience, if you have the UX right from the start, then the rest becomes much easier. UX is the foundation that will dictate how it has to be designed and programmed.

Looks like good insight to me.

But also in so many cases it needs to be made to work in reverse :\

Even when the pure logic or core process is where the real magic happens, and makes the app what it is, if interfacing with a user is very important you could also say that the UI is the actual heart of the program instead, which ends up calling that wonderfully unique code that may be different than anything else. Or anything else that has ever had a UI before.

But you need a "more common" interface that can accommodate optimized workflows of some kind or another, in enough ways for target mainstream users to make the most of the unique parts of the core creatively-engineered code, enjoying the most easily gained familiarity at the same time. With at least as usable a UI as they are accustomed to if not better.

Once that's all said & done is when I think it would be best for the creative artists to bring it up to meet visual objectives, with carefully crafted content curation, and run that by all kinds of ergonomic testers.

If they come up with any engineering shortcomings I would listen to them, even if it's nothing like an actual deficiency or true defect. There should be some pretty tight functioning and I think that would happen less often.

> if interfacing with a user is very important you could also say that the UI is the actual heart of the program instead

If it's meant to be used by humans, then yes. The experience should be the north star.

That doesn't mean that you have to sacrifice everything in favor of this. Obviously you need someone with enough technical knowledge to understand how to balance all the priorities.

Edit:

And by experience I don't only mean the UI per se. Also the performance of the whole system etc.

The main thing that pisses off devs is changing requirements. Unless the devs get a free pass the rebuild everything from scratch.

Like software, requirements can never be perfect. Overly prescriptive requirements are a huge red flag to me that a PM/client/designer is doing an engineer’s work, or micromanaging.

Nobody said requirements need to be perfect or never leave room for free interpretation.

Arguably lots of UIs getting worse with every iteration of redesign.

- Windows GUI went downhill from Windows 7 (or even XP) with every release.

- Outlook went from good over fair to annoying so that I finally replaced it as my personal client.

These are not the only examples I could name but they are the most prominent. I think the main problem is that both technical staff and UX designers both trying to make something "new" or "fancy" which is in most cases the opposite of something usable. E.g. Aero was fancy but it took away that my active window had one signal color header bar and all others were tamed. Now all windows are colorful and yelling at me at the same time. Orientation is gone.

And after that UIs got even more "fancy".

Step 13 ("Nobody's happy but nobody hates it") is the plateau when everybody is to tired to keep on fighting - a compromise, not the state of the GUI reached anything acceptable. It is not fancy enough anymore for developers and UX designers to be proud of but at the same time and is still annoyingly bad for the users.

About Outlook: Are you talking about the Win32 desktop client or the M365 web app? If the desktop client, what has gotten so much worse? And is there a better alternative to the Exchange calendar? I have not seen one in my experience at mega corps.

I think this is a partial solution, but I have to point out that relegating that function of translator and tester to a “fresh grad”. That is ideally the exact role of a Product Manager today, the very go-between and translator with vision that can manage customer/client expectations while also adequately communicate technical concepts and both communicate initial tex task breakdowns and also run interference for devs, i.e., dish out conditional nos.

This function is both extremely critical as well as it is also not valued in my opinion. The business/client side thinks that’s what devs are for, and devs think they’re just more management until they’ve learned that (please excuse the sport metaphor since it’s not something I do, but it seems fitting) Product Managers can be the defensive line as well as the quarterback for the running backs converting, the coach’s strategy into wins and a cheering crowds instead of boos and disappointments all around.

The difference? Fresh grads are much cheaper than experienced PMs. I always say: Don't hire PMs; hire better devs (who, when necessary, can wear the hat of a PM). To be clear: My example is specifically talking about internal software development, and I have seen this strategy work at multiple companies. Creating an external product for B2B or B2C is very different.

Internal SW dev can work with a lot less overhead and setting up direct communication between users and developers is reasonably simple. There is usually a 1:1 relationship between user roles and developers.

Published software ideally has many, many more licensees and you absolutely need rigid communication channels with various go-betweens (PM, marketing, support). Direct communication between devs and customers wastes too much of the developers' time. Especially the PM role becomes extremely important for product quality then. In the extreme, the product can only be as good as its PM.

Devs are expensive, and devs who can PM are incredibly expensive.

You are missing the point: What generates higher ROI: (1) dev + PM (separate people) or (2) highly skilled dev who can periodically act as PM? In my experience, it is always (2). Any time that I hear a senior manager complaining about "expensive devs", I always ask them: "How do you balance cost and quality?" Most of them are stunned by this question and give a bullshit answer. The truth: Almost all orgs are better to hire far fewer devs who are very high quality, versus many devs who are lower quality. I never worked for Amazon AWS but the "pizza-sized" team thing is real -- from experience.