5 ms·

Hard agree. I don't know if "design doc" is the right word—I call them technical analyses—but writing up a doc that connects business & product needs to impleme

by bccdee 2y ago

Hard agree. I don't know if "design doc" is the right word—I call them technical analyses—but writing up a doc that connects business & product needs to implementation details is highly useful to get everyone on the same page in terms of requirements & deliverables. If I'm clear on the requirements & everyone else is clear on what I'm delivering, this is unnecessary. Sure, jump straight to prototyping. But this is rarely true for any serious project. There are always unknown unknowns that you need to tease out from the stakeholders, and a technical analysis is a great way to do that.

rockemsockem 2y ago
It's also easier for all involved parties to read, whether they're technical or not, assuming you have some sections that explain things without relying on code.
- bccdee 2y ago
  Yeah 100%. I'm not going to make my product manager read a thousand lines of code just to get them to confirm all the assumptions I made about what they were asking for when I could just clarify.
keypusher 2y ago
> If I'm clear on the requirements & everyone else is clear on what I'm delivering. That's a big 'if', and usually isn't possible without prototyping in my experience. What you're describing seems like something that would be written after a prototype is already done. Presenting a prototype (or iterating on multiple prototypes) is a better way to tease out unknowns than any document.
- bccdee 2y ago
  It's usually not possible without a technical analysis, is my point. A throw-away prototype takes much longer to build and is much harder to review and discuss with stakeholders than a document. Like, how are you going to build a prototype demonstrating design trade-offs—are you just going to build every possible version? Are you really going to make a product manager read a 2000-line PR instead of three pages of bullet points? Presenting a prototype only really make sense for UI-centric things anyway, and even then, there's a million ways to make a UI mock-up that don't involve functioning code.

by bccdee 2y ago

rockemsockem 2y ago

It's also easier for all involved parties to read, whether they're technical or not, assuming you have some sections that explain things without relying on code.

bccdee 2y ago
Yeah 100%. I'm not going to make my product manager read a thousand lines of code just to get them to confirm all the assumptions I made about what they were asking for when I could just clarify.

keypusher 2y ago

> If I'm clear on the requirements & everyone else is clear on what I'm delivering. That's a big 'if', and usually isn't possible without prototyping in my experience. What you're describing seems like something that would be written after a prototype is already done. Presenting a prototype (or iterating on multiple prototypes) is a better way to tease out unknowns than any document.

bccdee 2y ago
It's usually not possible without a technical analysis, is my point. A throw-away prototype takes much longer to build and is much harder to review and discuss with stakeholders than a document. Like, how are you going to build a prototype demonstrating design trade-offs—are you just going to build every possible version? Are you really going to make a product manager read a 2000-line PR instead of three pages of bullet points? Presenting a prototype only really make sense for UI-centric things anyway, and even then, there's a million ways to make a UI mock-up that don't involve functioning code.