Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualKylotan

Posted 24 January 2013 - 12:42 PM

A document is a tool for communication. In a team collaboration your doc usually communicates the scope and details of future work to be done by others. They get pissed off if you keep changing it a lot because it interferes with their work, leading to wasted time or even people quitting. Hence it's a bad idea to change the design doc significantly while the team is working, as it delays the project. But the doc is just the artefact - the problem is that what you're telling your team has changed and so have their expectations.

If it's just you on the team, you're just communicating with yourself. As such it's more of a reminder than an instruction, and this is why a design log can be as useful as a design document - you already know the basic information that would otherwise go into a design doc, so you just need somewhere to note down the adjustments that you end up making to the original vision. But whichever way you do it, if the goals of the project change, and you will need reminding of this, change the doc.

If you're worried about feature creep, throw all your features into a list and prioritise them. Never add a planned feature without adding a priority. Revise priorities from time to time. Always work on the highest priority features that remain on the list. Ship the product whenever you're happy with it or when you reach your deadline.

#1Kylotan

Posted 24 January 2013 - 12:42 PM

A document is a tool for communication.In a team collaboration your doc usually communicates the scope and details of future work to be done by others. They get pissed off if you keep changing it a lot because it interferes with their work, leading to wasted time or even people quitting. Hence it's a bad idea to change the design doc significantly while the team is working, as it delays the project. But the doc is just the artefact - the problem is that what you're telling your team has changed and so have their expectations.

 

If it's just you on the team, you're just communicating with yourself. As such it's more of a reminder than an instruction, and this is why a design log can be as useful as a design document - you already know the basic information that would otherwise go into a design doc, so you just need somewhere to note down the adjustments that you end up making to the original vision. But whichever way you do it, if the goals of the project change, and you will need reminding of this, change the doc.

 

If you're worried about feature creep, throw all your features into a list and prioritise them. Never add a planned feature without adding a priority. Revise priorities from time to time. Always work on the highest priority features that remain on the list. Ship the product whenever you're happy with it or when you reach your deadline.


PARTNERS