Hacker News new | past | comments | ask | show | jobs | submit login

It really depends on what you do. If you have a well defined problem, that is complex enough to require quite some work, than I would say: Do as little as possible to be able to imagine as much of the workflow as possible, while also staying as flexible as possible.

If a problem is less complex or can be released iteratively, than that's the lean way to do it, where you also have good learning. But often to solve the problem just a bit you already need a load of stuff to be taken care of.

Key to me is to stay in text or cheap click-dummies for long enough. Depending on the complexity I go through several stages:

generally:

- Always probe for details if you can imagine some already, you are trying to know as much as possible as soon as possible. File it all in to a "to take care of later"-list at least, better yet sort in properly already.

- write down everything (maybe others can remember everything, fine too :) )

- change and refine whenever something new has to be taken care of. IN the following steps it will always be easier now, than in the next step.

1. gather high level requirements with the stakeholders

2. sketch a rough workflow. I usually do a nested list.

3. write down a complete workflow

4. now you might know what you need, so define a rough UI, technology, interfaces

5. still in text: write your concept so someone else understands it

6. talk everyone involved through the concept (first stakeholders, than devs)

7. double-check if you cant simplify or leave out anything, at least for a first version

8. if necessary: do mockups, designs, schemas

9. only now start to program (for difficult stuff a prototype)

- On top it might be helpful to have a small checklist depending on your needs with entries like "reporting?, testing?, support?"




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: