Prototype
Quickly build the right path
Last updated
Quickly build the right path
Last updated
The core purpose of the prototype, the assumptions you are trying to validate/invalidate or the knowledge gaps you are trying to fill should have all been discussed in . During this phase you will build a quick and dirty prototype. Since you only have at most a day to build the prototype it should be as low-fi as you can get away with during .
During this phase roles shift. Designers are typically the ones building the prototype unless it is low-fi enough for everyone to contribute (see: or ). Product Owners should be in charge of getting realistic information, data and copy into the prototype. It should be clear what everyone's role is before the phase starts. The team should check in with each other as much as possible to make sure everything is on the right track.
HTML & CSS prototypes tend to be the most time consuming but are best for heavier web interactions like filling out forms. Use for a starting point and quickly host on GitHub pages - this is no longer maintained.
Invision really great for being able to take mockups from Photoshop or Sketch and allow for users to click through to different states or pages. Invision allows for you to create a simple image map for your users. Because it takes mockups it allows for you to create designs that look more visually appealing or visually complete.
The traditional , Keynote is great for a low-fi click through prototype similar to Invision. Keynote allows for really great animations and transitions. Because it is Keynote and not a graphical editor there is a limit to the visual design you can do. If you are going to use Keynote for prototyping use a template like to speed up your design process.
Paper prototyping is as low-fi as you can get for a prototype. It is especially useful when you are under a time crunch to produce a prototype. It also allows for the whole team to contribute. Because the prototype is sketches on paper you are relying much more on the imagination of the participant. It gives you the ability to prototype on the fly, even during the session with the participant. Tools like and can help present sketches on a mobile device or in the browser so that it seems more real.
Our prototype is much higher-fidelity than a prototype would typically be, but that was somewhat necessary for testing our hypothesis.
Before couples can address the details of planning a wedding (decoration, guests, caterers, dress, etc.), couples usually have to decide on a location and venue. The couple is filled with excitement; as the wedding day will usher forth a new life for the couple together. However, the couple might experience a bit of uncertainty as to how even to proceed planning their wedding. We want to capture couples at their “excitement” period and put aside all uncertainty and potential anxiety that the wedding planning process may cause. A customer’s initial engagement with our website should parallel his/her engagement with the wedding process in general.
With our prototype, we want to evaluate our ability to capture the excitement of a recently engaged person and leverage that excitement to create engagement with our website.