Recently Bryan talked about how we launched a successful product: Verify, our second publicly released app. We created Verify because we thought it was time for everyone (ourselves included) to use more data in their decisions. Great products not only come from great ideas, but also from information and iteration.
Verify was a lot of fun for us to build because we went about it in a slightly different and much more aggressive way than other apps and sites wea''ve built. Leta''s look at the process we took to create Verify, along with some examples of each step.
Starting with Sketching
We love sketching at ZURB. It helps you get ideas out quickly, ita''s disposable, and it keeps you from focusing on detail too much. With Verify we started by very quickly sketching out the core pieces of the application - things like creating tests, how tests were taken, what reports looked like. We went through probably 80 sketched screens and interactions within the first week of the project, which represented the majority of the application.
Immediate Front-End Prototyping
After sketching is where we deviated from our usual process. Instead of moving into hi-fi wireframes or visual design we took advantage of the work wea''d already done for Notable to jump right into front-end prototyping. We built out the entire front end in 2 weeks.
There were a few critical pieces that helped us build the prototype that quickly:
- Our global stylesheet, including the grid. We use a common global.css file for all of our apps, and wea''ve worked with that file to make it a powerful and flexible tool for us to build pages very, very quickly.
- Our global visual design, governed by Notable. Since Verify is part of a platform of apps, we wanted to be sure the visual style was representative of that. This allowed us to cue in on Notablea''s look and feel with just a few variations.
- Iteration. We knew wea''d have time after the first push to refine the application, so our first pass was deliberately rough.
Two test screens from the original prototype
Building out the front end prototype not only helped us validate the experience early, it also created a de facto functional requirement for our engineering team. After just the first week of prototyping we were already hooking up the back end and enabling core pieces of the app.
Working with Engineering
Once the first pass at the front end was complete it was just another couple weeks before the application was working and usable - albeit rough around the edges. Because we got engineering involved early we were able to quickly resolve technical issues or design challenges around functions, edge cases - anything we might not have foreseen.
We cana''t stress enough the value of having a nearly complete front end to get engineering involved with. It communicates clearly the intent and function of the app, it provides a solid foundation for discussion and it exposes early where problems could lie and what the solutions might be. This only works if you can prototype rapidly - if you can, ita''s a huge help.
The same two screens from the image above, in their current iteration
Start to Finish in Time for Demo
The goal in the first phases of Verify was to build out the application in 3 months, in time for Demo 2010. Once Demo rolled around we not only had the app built out, but had had time to iterate, refine, and improve the app in a number of key areas. We kept refining Verify through Demo and through the summer until our launch in October, but because we built quickly we already had paying customers, with great feedback.
Just over a month from a pile of sketches to an entire front-end to a working application was a challenge for us, but thanks to our experience with Notable as well as our own processes and code tools we were up to it.
How do you prototype, and when do you get different teams involved? Let us know in the comments, and be sure to RSVP for Friday when youa''ll get the chance to ask Facebook Product Design Manager Julie Zhuo how they prototype and iterate at Facebook.