The way I was taught was to start by hiring several designers to design every screen, and then only hire programmers after you're completely satisfied with the design. The way these outsourcing firms get you is by offering a cheap bid, and then charging you every time you want to make a change. So start out by knowing 100% what you want, and then once they've accepted the project don't let them ask any questions or make any suggestions until 1.0 is completely finished. (If they don't understand something they can ask for clarification, but that's it.)
Always have your fights up front, never once the project has started. That way you'll get the project on time and under budget.
I totally disagree, get basic stuff done by the designer, but I find it completely changes as programming happens. You figure out things won't work the way you thought they should, you figure out better ways, etc. Get wireframes down, so you don't spend thousands on designers, and then realise you have to spend thousands more.
Right get the UI right and it won't cause as many iterations on the back end (where it hurts more) as well prototype the whole UI in HTML/Javascript, Flash, Desktop app, whatever suits your fancy. Have a fully functioning UI that the user can touch and feel before you develop the back end. This will flesh out all data requirements and business logic services that will be needed to support the UI.
I am a little leery of not allowing the developer to provide input though. Things are going to change, you just want to narrow those changes to the important things.
I don't think you need a finely polished UI to start with, but some wireframes or even hand sketches of what each page/screen/dialog will look like can be a very effective communication tool. Written use cases are great but a picture can truly be worth 1000 words.
End users think in terms of screens, if you can provide them with a fully functioning ui then you can get valuable feedback about useability up front. The client knows in short order that they are getting all of the features they want because the get to touch and feel the system. After I adopted this method my project change orders slowed to a trickle.
Comments
The way I was taught was to start by hiring several designers to design every screen, and then only hire programmers after you're completely satisfied with the design. The way these outsourcing firms get you is by offering a cheap bid, and then charging you every time you want to make a change. So start out by knowing 100% what you want, and then once they've accepted the project don't let them ask any questions or make any suggestions until 1.0 is completely finished. (If they don't understand something they can ask for clarification, but that's it.)
Always have your fights up front, never once the project has started. That way you'll get the project on time and under budget.
I totally disagree, get basic stuff done by the designer, but I find it completely changes as programming happens. You figure out things won't work the way you thought they should, you figure out better ways, etc. Get wireframes down, so you don't spend thousands on designers, and then realise you have to spend thousands more.
Right get the UI right and it won't cause as many iterations on the back end (where it hurts more) as well prototype the whole UI in HTML/Javascript, Flash, Desktop app, whatever suits your fancy. Have a fully functioning UI that the user can touch and feel before you develop the back end. This will flesh out all data requirements and business logic services that will be needed to support the UI.
I am a little leery of not allowing the developer to provide input though. Things are going to change, you just want to narrow those changes to the important things.
I don't think you need a finely polished UI to start with, but some wireframes or even hand sketches of what each page/screen/dialog will look like can be a very effective communication tool. Written use cases are great but a picture can truly be worth 1000 words.
End users think in terms of screens, if you can provide them with a fully functioning ui then you can get valuable feedback about useability up front. The client knows in short order that they are getting all of the features they want because the get to touch and feel the system. After I adopted this method my project change orders slowed to a trickle.
It must be horrible working with you.