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