Is Wireframing Overplanning?

Question

37 Signal's Getting Real convinced me that wireframing and writing functional specification documents are middleman steps unnecessary for building web applications and dynamic websites.

Is the overhead for these steps worth its weight? Is prototyping in HTML/CSS or even PhotoShop documents (so designers can work on them directly) a better option than using software like Visio? Personally, I am swaying towards the latter but am not sure.

Answer 1

"Fail to plan is plan to fail" - or something like that.

Wireframing is not limited to web-apps; it is pervasively used wherever a high-level overview of any system is needed (it's just called something else).

Functional specs, when you know what is to be done & how to do it would indeed be overkill. A high-level diagram of your intentions would suffice. And it will never be unnecessary. It primarily helps you focus on the scope and intent/target of what you want to do.

The focus should be on preventing wasted effort - finding out half-way through that something essential, that impacts on all other objects, are missing is not what you want to discover. Wireframing in this case would assist in detecting most major functional needs. You would only need to elaborate on functional spec where absolutely needed. Using Photoshop to design your will also be 'wasted effort" - far better to use evolutionary prototyping (RAD technique) with CSS/HTML - but still do pen & paper mock-up of your intentions.

Answer 2

37Signals advocates skipping even Photoshop and going right to HTML. See http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop. I agree with their assessment of pre-planning. I don't think its worth the time in the long run when you could be spending time building a working prototype in HTML/CSS/JS.

Answer 3

In real life you want to avoid looking for the "ideal" way to do things. Instead use what you understand for clear and specific purpose.

Mockups can save you TONS of time and effort. As they can be just extra time you spent on creating and maintaining them.

Real life example #1: Mockups saved the day. Big system for the government, deadline is ridiculous.

Reason: Months have gone by in producing all kinds of architecture documents which are in fact completely unnecessary because both HW and SW architecture are fixed in stone to the tiniest detail, and in fact already exist.

Solution: 20 frantic days of creating mockups together with the customer, until we simply handed the screens with our notes over to developers. Developers did have to ask for some clarifications but with fixed architecture and clear and visualized requirements they were able to crank out required tons of features in no time.

Real life example #2: Mockups ruined the day. Big government system that "recognized" the need for mockups.

This one shows human (or corporative?) ability to turn the best thing in the world into a nightmare.

Big government agency asked the big consultant company to lead the big IT company to solve a problem. Government agency also established a big ad-hoc body of government subject matter experts to help and speed up the process.

Months have passed in big words and in deciding on appropriate methodologies to use and proper ways to use them. All kinds of compromises were made, of course, not to hurt anyone's feelings or importance.

Result: Sw architecture was to be the source of everything including mockups. Which were to be designed first and drawn second. Mapping the actions from OOAD and sequence diagrams, UX diagrams were made, then UI logical objects and content bundles were recognized, actual screens were drawn and incorporated in formal Use-cases, UCs were presented to users in once-a-month formal workshops, those workshops doubled as requirements-acceptance meetings since somebody figured out time is slipping by.

On those workshops, even by force customers couldn't be made to undestand (highly-formal, with lot of tables describing data attributes and such) UCs, each approximately 30 pages long. When customers had some feedback it was on the mockups. But feedback was discouraged, because any change in mockup resulted in changing the sequence diagrams, component diagrams, operational model, UX diagrams, checking the traceability matrices, updating UC texts, etc etc. And only to get more feedback. ("Damn the customers, they are never satisfied." was the moto). After the rollout of v1.0 with limited functionality, nobody cared about documentation any more, there was so much of it. Developers were fighting for their lives, making myriad of small changes daily, just to get the system up and running (after yesterdays batch of changes made something else break).

This is NOT the way to use mockups. The project lasted almost 2 years longer than planned.

In other words, don't look for ideal methodology. Or any methodology you don't understand. What's your goal at the moment? What's the quickest way you know (other ways don't count) to achieve that goal? Go for it.

Answer 4

It probably depends on who you're working with. If it's you and a designer, then a functional spec might be too much trouble. But, in my job, the executives want to know precisely what they're going to get at the end of a project and so we've had a real hard time implementing iterative development. Usually the iterations are defined with wireframes, functional specs and mock ups..:)

Answer 5

The main purpose of doing wire-frames is to clarify requirements. Clearly documenting requirements is always advisable and there is no better way than visualizing a requirement. Wireframes help in a great way here, it gives the product owner (client) clear idea of what to expect from the end product. On approval from product owner it also gives clearer picture to development team of what to develop.In a way it saves lot of development time and avoids conflicts. In my opinion wire-frames are always useful for smooth project execution even when project is small.

Answer 6

I believe it depends on how well you understand what you are trying to do. If you are working for a client and they haven't expressed much in the way of requirements you may want an approach with extremely quick iterations. If you already have a good understanding and can produce something more substantial without worrying about throwing it away because it was the wrong direction then more time can be spent. Either way, a clickable prototype can go a long way in determining what the real site needs to be in the end. If you can get agreement on the prototype, then when your application matches the prototype you know it is complete.