Experiencing the Experience: The Case for Prototyping

I realized this week that in a traditional web app design scenario there end up being three review cycles:

  1. 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.
  2. 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.
  3. 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.


About Jeff Gothelf

Jeff Gothelf is a lean thinking and design evangelist, spreading the gospel of great team collaboration, product innovation and evidence-based decision making. Jeff is an author, speaker and thought leader on the future of product development and design, often teaching workshops or giving talks on building cultures that support teamwork and innovation. Jeff co-founded Neo Innovation, a lean/agile product firm in NYC. Prior to that, he led the UX design teams at TheLadders and Web Trends. Earlier he worked with and led small teams of software designers at AOL. He is the co-author (with Josh Seiden) of Lean UX: Applying Lean Principles to Improve User Experience and the upcoming (Harvard, 2016) Sense and Respond (sensingbook.com).
This entry was posted in agile, design, Productivity, prototyping and tagged , , , , . Bookmark the permalink.