Live data from Hacker News

GUIs are built at least 2.5 times

patricia.no

91–100 of 155 posts

Re: GUIs are built at least 2.5 times

#91

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…

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…

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.

Re: GUIs are built at least 2.5 times

#92
post #50

Earlier quoted context omitted.

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

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.

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

Re: GUIs are built at least 2.5 times

#93

Earlier quoted context omitted.

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…

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.

Re: GUIs are built at least 2.5 times

#94
post #50

Earlier quoted context omitted.

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

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.

Re: GUIs are built at least 2.5 times

#95

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…

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…

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?

Re: GUIs are built at least 2.5 times

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

When I do GUI work, it's usually for hobbyist or internal projects. I value quality UI/UX extremely highly. I often get 'analysis-by-paralysis' here because I try to do the design and development in a synchronous single pass. Your comment about tight and rapid iteration being the only solution resonates with me. One 'trick' I discovered recently was to completely ignore UI design and focus on _formatting_ instead --…

>GUIs are built at least 2.5 times

Unfortunately what is more often needed is 3.0+ and far too many fall short :\

>"good UI" = "good page formatting" + "pretty UI elements".

Nice to have, icing on the cake, but what I need if it was to be mission-critical is at least 10x better workflow than average these days.

As a child, before I had any concept of software, I just wanted to get something worthwhile out of electronics itself.

I'm so old that most adults didn't have a concept of software either in those days. "Software awareness", that it even exists as an entity of its own has by now proliferated by many orders of magnitude like most other things do not.

One thing that's stood the test of time, if you can make the electronics do something it wasn't doing before, well that might just be remarkable. Maybe even game-changing. Maybe even like never before.

Sometimes you program, sometimes you don't.

In the right balance it can end up quite a system.

Decades ago for my own purposes I separated the UI from the rest of the code, and this was of course a monolith with line numbers. The equivalent of punch cards, but when you think about it the UI could be in the final 25% of the deck of cards, and quite easily physically replaceable in that media form factor. Plus, if you're transparent about it, it can really come in handy sometimes to deal from the bottom on the deck. GOTO can easily be your friend if you know how to accommodate each other ;)

But code also doesn't necessarily have to have any electronics involved.

Software alone can be considered more independent of constraint by a "system", because it can be so abstract.

Doesn't have to be so abstract, but that is a serious option sometimes.

The ultimate would be pure software which is not part of any other "system" at all.

I'm so out-of-date I'll probably just stick with the electronics ;)

>Any thoughts on this approach?

Sorry, my head's a blank ;)

Re: GUIs are built at least 2.5 times

#97
post #66

Earlier quoted context omitted.

The best functional specs for a UI have come from business people building their own in excel. At a minimum they will have some idea of layout and what information should be displayed on which screens. This also lets them focus on the core information, not the styling. Building GUIs on the web, there are infinite ways to style every UI element and more attention goes to that then the actual interaction.

I'd disagree with that. People build wild shit in Excel that only they can understand. It makes sense to them because they built it. Nobody else can use it. Not all spreadsheets are like this but there are absolutely no guardrails to prevent it. Building a good GUI takes thoughtful design by someone who understands what makes a good GUI and what the goals of the interface are from the user's perspective. Someone who…

> People build wild shit in Excel that only they can understand.

If these people are the customer, then a wild shit xlsx file is perhaps one of the better possible scenarios for requirements gathering.

Re: GUIs are built at least 2.5 times

#98
post #97

Earlier quoted context omitted.

I'd disagree with that. People build wild shit in Excel that only they can understand. It makes sense to them because they built it. Nobody else can use it. Not all spreadsheets are like this but there are absolutely no guardrails to prevent it. Building a good GUI takes thoughtful design by someone who understands what makes a good GUI and what the goals of the interface are from the user's perspective. Someone who…

> People build wild shit in Excel that only they can understand. If these people are the customer, then a wild shit xlsx file is perhaps one of the better possible scenarios for requirements gathering.

I've been in this exact situation. Client provides their current workflow, implemented in a spreadsheet.

The problem is they make significant concessions in their design to fit the tabular model of spreadsheets. It can be really warping, not only to GUI but also the underlying data model. Then you show them what a relational data model is capable of, and (hopefully) blow their mind.

Re: GUIs are built at least 2.5 times

#99
It's weird that the author is bothered by the concept of waste being applied to software, because when people talk about waste in software development, one of the main forms of waste is inventory: the effort put into building software that has not yet been used.

Or, in the article's terms, things you've built but have yet to receive the feedback "that's shit" so that they can be iterated on.

Re: GUIs are built at least 2.5 times

#100

I think agile approach to iterative building is kind of obsolete with AI. There is no "12th step agile fast process", with all stakeholders involved. Instead you get experts throwing slop over the wall to stakeholders, to see what sticks. I made webservice recently. To help me debug and test results, I asked AI to make me a simple CRUD web UI in Vue. Customer liked it, and it was kept in final version. This UI was no…

Curious, which AI tool are you using for this kind of simple UI prototype?
Post reply on HN