[z92]

Prototyping takes less time than writing up the requirement in paper. And customers can give more accurate feedback watching the prototype than reading the docs.

It rarely happens that once a prototype is written, the developer finds out it was all a wastage and the customer wanted something quite different.

Think of the prototype as a Photoshop mock, but interactive like the real application.

[slumpt_]

You aren’t writing up UX requirements. You’re writing system designs.

If you’ve never had to write down and get feedback on a system design that is entirely okay, but as you work on projects of increasing complexity and scope, it becomes more and more important to plan before you write.

The prototypes you’re describing are primarily useful for UX iteration, not system design.

[radley]

> it becomes more and more important to plan before you write.

I'll counter that with a real-world experience.

I contracted at a well known company that did system design & documentation first, without doing prototyping, etc. My first day working on the UI I pointed out that the web app had so many menus that the actual content would barely fit on a 15" laptop screens.

The team debated and debated on how to fix it, but ultimately it kept getting trumped by the documentation team who said the docs are done so we couldn't change anything. I left after a couple of months. They worked on it for a year before finally tossing it out.

[0xEFF]

A short system design doc with a working prototype is vastly superior to a 50 page design doc with no code.

Think of it as the scale model of the house in the original example. It’s a way for sake holder to see and feel what they’re going to get.

[tsimionescu]

Sure, but a few days of intense dedicated discussions /white boarding with a handful of senior engineers can save you from throwing a bunch of different prototypes at a wall to see which one sticks.

[corytheboyd]

Controversial as it may be I completely agree. Maybe I’m just not on the same god tier level as the rest of you but I have done the days/weeks of planning carefully without touching anything close to code “because you’re not supposed to” and there still ends up being things we didn’t think through that become obvious at implementation time. I agree that coding and planning don’t have to be mutually exclusive

[spdionis]

I think spending days on planning is really valuable. Spending weeks is counterproductive in most cases.

[sanderjd]

Figuring out exactly what code to write is not the goal. Figuring out approximately what code not to write is.

[billfruit]

The thing is engineers in other engineering disciplines have documentation that lay down things to the minutest detail. So is it not a good idea for software specifications to do the same, instead of having a brief design document missing huge amounts of design details.

Abridged and abstracted documents add their own confusion.

[sanderjd]

Agreed! And this does not contradict what I said. I think it's easy to swing too far in both directions.

[radley]

> it becomes more and more important to plan before you write.

I'll counter that with a real-world experience.

I worked at a well known company that did system design & documentation first, without doing prototyping, etc. My first day working on the UI I pointed out that the web app had so many menus that the actual content would barely fit on a 15" laptop screen.

The team debated and debated on how to fix it, but ultimately it kept getting trumped by the documentation team who said the docs are done so we couldn't change anything.

I left after a couple of months. They worked on it for a year before finally tossing it out.

[sanderjd]

Well this is obviously also bad. It is not necessary to either dogmatically code without first planning or discussing, or to dogmatically write a fully specified and unchangeable spec. There is a huge continuum of possibilities between those extremes, which strike a better balance than either approach.

[yarcob]

> It rarely happens that once a prototype is written, the developer finds out it was all a wastage and the customer wanted something quite different.

In my experience this leads to mediocre results. You need to throw out prototypes often, otherwise you'll end up with shitty solutions.

It's an unfortunate fact that as soon as you see a prototype, everyones instict is to fix the most glaring issues and call it done.

But to get to a truly great solution, you often have to throw out the prototype, and start all over.

Unfortunately very few people have the patience for that. Usually the prototype already took so much time, that everyone is already totally stressed, and starting over is out of the question.

If throwing the prototype away isn't possible, it's not really a prototype anymore.