Comment by senko
6 days ago
> Why can't we figure out the right thing faster by building the wrong thing faster?
> Because usually the customer can only tolerate so many failed attempts per unit of time. Running your fitness function is often very expensive in terms of other people's time.
Heh, depends on what you do. Many times the stakeholders can't explain what they want but can clearly articulate what they don't want when they see it.
Generate a few alternatives, have them pick, is a tried and true method in design. It was way too expensive when coding was manual, so often you need multiple rounds of meetings and emails to align.
If you don't think coding was the bottleneck, you're not thinking creatively about what's only now possible.
It's not what you can do faster (well, it is, up to a point), but also what can you now, do that would have been positively insane and out of the question before.
> Generate a few alternatives, have them pick, is a tried and true method in design. It was way too expensive when coding was manual, so often you need multiple rounds of meetings and emails to align.
Why do you need coding for those. You can doodle on a whiteboard for a lot of those discussions. I use Balsamiq[0] and I can produce a wireframe for a whole screen in minutes. Even faster than prompting.
> If you don't think coding was the bottleneck, you're not thinking creatively about what's only now possible.
If you think coding was a bottleneck, that means you spent too much time doing when you should have been thinking.
[0]: https://balsamiq.com/product/desktop/
I've been using Balsamiq since back in 2012 (perhaps earlier, can't find an earlier reference in email), when it was all in Flash/Flex (IIRC).
For UX, approach like that can often work. For non-UI stuff, more complex processes and exploration (because nobody is actually sure what's going to work best), the handwaving is just deluding everyone.
I've been on enough demos where customers pretended they understood the concepts only to be surprised later, or going back and forth for months on what they actually need, to know that:
> If you think coding was a bottleneck, that means you spent too much time doing when you should have been thinking
is cute, but naive.
That's done by arranging a demo (the very old way) or (better) by deploying to a staging server. The customer meets with you for a demo not very often, maybe once per month, or checks what's on the staging server maybe a couple of times per week. They have other things to do, so you cannot make them check your proposal multiple times per day. However I concede that if you are fast you can work for multiple customers at the same time and juggle their demos on the staging servers.