Live data from Hacker News

GUIs are built at least 2.5 times

patricia.no

41–50 of 155 posts

Re: GUIs are built at least 2.5 times

#42
post #38
post #27

Earlier quoted context omitted.

It’s not only customer requirements that it works well for. Ever started prepping a site for a concrete foundation and run into rock as your levelling?

Yeah - next door didn’t enjoy the arrival of the rock breaker!

I like when they just give up and a huge natural rock sits in the front desk with a table top or something.

Re: GUIs are built at least 2.5 times

#43

Earlier quoted context omitted.

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…

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.

Re: GUIs are built at least 2.5 times

#44

> So imagine a pipeline that takes in encrypted text and the first “filter” decrypts the text, the second takes the decrypted text and strips away the beginning and the end, the third takes its input and sends it in an email. From a programmers perspective, we might think of these inputs and outputs as the “same” because they are text, however, in meaning, they are very different. I've only got this far and thought i…

It's just a description of InputStream/OutputStream type classes. You can have an EncryptedStream as well.

There's something to be said for having objects that are just "a string (or number), but having had its prerequisites enforced and validated". Especially in unicode land.

Re: GUIs are built at least 2.5 times

#45
post #25

A tight iteration loop is the only solution I've seen for building high quality UI/UX. Embrace that it's going to be terrible the first few times and plan for this. We could save on cost per iteration by avoiding the layout and styling pass until the very end. These interfaces are about communicating information. Plain text and basic form submissions work just as well as anything else when you're still trying to desi…

Outside in development helps here too.

Re: GUIs are built at least 2.5 times

#46

This part is genius: > I have made GUIs many, many times and my best case scenario goes something like: > 1. A design has been made, everyone loves it. Detailed drawings have been made. > 2. The devs are told to Make It > 3. The devs Make It, exactly to spec > 4. Everyone looks at it and everyone hates it > 5. So many meetings. So much stress. This Is Terrible! What To Do? > 6. A new design is made. So much better! D…

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.

Re: GUIs are built at least 2.5 times

#47
post #25

A tight iteration loop is the only solution I've seen for building high quality UI/UX. Embrace that it's going to be terrible the first few times and plan for this. We could save on cost per iteration by avoiding the layout and styling pass until the very end. These interfaces are about communicating information. Plain text and basic form submissions work just as well as anything else when you're still trying to desi…

It is also my experience that this is the way to go, and it also matches my theoretical view aka prejudices.

It seems to me that one of the things making this approach difficult is that we lack (design) tools that support iteration between design and development.

Modern tools make going from design to development easier, but it is still largely a one-way street. And one that's been made worse by recent trends towards building the UI in code, rather than from data. There are good local reasons for doing this, but it does seem to push even more strongly towards a waterfall-y development process (design does pretty mockups, throws over wall)

Re: GUIs are built at least 2.5 times

#50

This part is genius: > I have made GUIs many, many times and my best case scenario goes something like: > 1. A design has been made, everyone loves it. Detailed drawings have been made. > 2. The devs are told to Make It > 3. The devs Make It, exactly to spec > 4. Everyone looks at it and everyone hates it > 5. So many meetings. So much stress. This Is Terrible! What To Do? > 6. A new design is made. So much better! D…

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.

Post reply on HN