Hacker News Reader

Comment by wongarsu | 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

View on HN

> 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.

Reply on news.ycombinator.com