cluelessPHP;11057855 wrote:I'm curious, how often are wireframes used in modern development now? I was under the impression rapid developed prototypes were becoming more favoured
This will really depend on the client. I spent several weeks last year talking to a retail pet store about creating a new web-based site to manage their business. They didn't ask for wireframes. We met in person and did a lot of sketches on paper. We examined screenshots of their existing software (originally designed to run hair salons). Never once made a wireframe. They didn't seem to mind. They were pretty smart guys. Based on these scribblings and meetings, we quoted them a number that was too much for them and they walked away.
Another client the year before that was working on an education-related website. Unable to meet in person, we started off by trying to create a rapid prototype using Javascript, but the scope of the project expanded so rapidly that our rapid prototype's basis was woefully inadequate to support all of the desired features. The client expressed dissatisfaction with the cost of the development process. I made a case that the client lacked a clear idea of the desired product so it was hard to identify what baseline components were needed to support the desired functionality. The client, also a smart guy, agreed and asked if there might be some tool to mock up the features he had in mind. I suggested Balsamiq and he was initially very excited about it until he started to realize its woeful limitations--namely how it's great for capturing an initial workflow, but then removing or adding a single button requires you to reformulate every screen that started from that form.
Years ago (eons?) I worked for a small software company that served giant Enterprise software clients. This miserable process involved generating numerous hundred-plus-page documents (Func Spec, Use Cases, Documentation, et. al) that absolutely nobody would read in their entirety. Basically everyone was covering their ass with with their own hundred page document and then we'd develop the software as best we could. All productive dialog would usually center very closely around the delivered prototypes and occasionally someone covering their ass would whine about us having ignored page 97 of their own 100-page document so we'd fix the prototype, bill the client, and then go home late and self-medicate to deal with the irritation.
I think the problem with wireframes is that they are static documents whereas actual functioning websites are moving/changing/temporal beasts that actually function. Unfortunately, many corporate organizations and non-technical people need them because they lack trust or imagination to envision what the software might look like. Pointy-haired bosses are notorious for this lack of imagination. I would say that for a talented and technically-savvy team that wireframes are uneccessary, but hand-drawn sketches are very useful. I would also say that for bureaucratic, dogmatic, corporate organizations or situations where you have to present to moneyed corporate people that wireframes can be useful.
I would add that the most productive situations I encounter don't require any static representation of a website and that the prototype itself serves tremendously as a 'straw man' and you should get on the phone and maybe share a computer screen to really get things done.
