I realized this week that in a traditional web app design scenario there end up being three review cycles:
- Wireframe review – ensuring all the elements are on the page, hierarchically correct and flowing logically from screen to screen. Confirming that the right data is being captured and then presented back to the user in meaningful ways that encourage the correct actions.
- Visual design review – once the wireframes are approved, the visual design transforms that skeletal frame into a living, breathing, beautiful work of art business solution. Colors, branding, typography, white space et al are all examined to ensure alignment and aesthetic quality.
- Interaction review – this is when the actual code is put through its paces and stakeholders, for the first time get to play with their creation. All of the assumptions “approved” in the first two reviews are now put to the test to see if, in reality, they behave the way they were represented in the wireframes and visual mockups.
This last (and third!) review cycle, the interaction review, is the first time the experience being designed is actually, well, experienced. Any changes, tweaks, complete re-works and realizations are only now surfaced. The code has to be updated and, in most shops, the documentation leading up to that code will also have to be updated. This is wasted effort.
Prototyping gets the experience out in front of stakeholders, users and the execution teams early and often. The proposed end-state can be evaluated and estimated. Workflow challenges and nuances are far more readily exposed and solved – all without having to update ANY documentation (because none exists). Prototyping shows your executives where you’re heading. It shows your dev team what they should be building and how it should behave. And it shows your customers how you’re solving their problems — before any major code is written.
As the experience is validated each time the prototype is presented, a finer layer of polish can be applied to the design – this includes interaction design tweaks, visual design and, if your code is good enough, code tweaks. Even if the prototype produces throw-away code (or no code at all) it is still far more effective at getting you to working software faster by experiencing the experience early and often.
Save yourself time. Prototype first.
[Jeff]
Comments are closed.