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