I was tyring to get the module working with little knowledge of what the requirment was, this led me to lot of re-work and most of the time was spent discussing with the team what API should be given and how things should be done. Now I think it would have been better if we could have understood what we were really building.
I have been developing the front end, most of the time it invloved only UI logic, the only thing that I had to do was, make service calls, get the data and display it, the requirment was based on a document that provided what the UI should provide, that was easy...I started designing the the UI, got a bunch of APIs from the service team, and started filling in, what I did not understand was the whole idea behind the requierment.
As days went on, issues started to rise, and I had to sit with the service team and ask ourselves why we were doing a particular thing , this ultimatley led into rework and hours of time were spent on discussion.
I learnt my lessions, what ever you are doing, understand the business requirment for why you are doing something, without basing your implementation on a mere UI prototype.
Well, guess that's the disadvantage with UI prototypes; you try to implement what ever that is in the prototype without ever thinking why your are doing it.
I would not even want to design a screen for the sake of the UI prototype, without understanding what each and every field does or it's intended purpose.