5 ms·
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 ok
by slumpt_ 6y ago
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.
- 0xEFF 6y agoA 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.
- corytheboyd 6y agoControversial 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
- tsimionescu 6y agoSure, 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.
- sanderjd 6y agoAgreed! And this does not contradict what I said. I think it's easy to swing too far in both directions.
- billfruit 6y agoThe 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.
- radley 6y ago> 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.
- radley 6y ago> 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 6y agoWell 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.