After three days of understanding the problems and tackling them from different angles, we were ready to embark on day four: prototype.

The Google Ventures blog describes a prototype as “anything a person can look at and respond to. A prototype doesn’t usually have to be very complex in order to learn what you need to know.” They recommend using Keynote to build our prototypes. Keynote doesn’t require code knowledge and allows for everyone to participate in the building of the prototype. Google Ventures describes Keynote as the “world’s best prototyping tool” based on its speed, low cost ($20), ease of use, and that “it’s impossible to make things look perfect, so you don’t get too precious.” Google Ventures recommends using “Keynotopia” a downloadable template filled with pre-made buttons, menus, drop-downs, and other design elements.

Today’s prototype was to be use for user testing tomorrow (day five: validate). The idea was to create a rich prototype that had basic design and real copy, but still allowing quick revisions.

Our team was initially skeptical of using Keynote. There were suggestions of other tools that the team was already familiar with such as UXPin. To stay true to the exercise we chose to stick with Keynote and use the recommended Keynotopia templates.

We divided the screens of the storyboard and assigned each person one or two to build in Keynote. We also assigned a “stitcher” to put all the slides together into a single flow.

During the exercise we noticed that people with a design background behaved differently from those without design or wireframing experience. The designers put much more emphasis on which ui elements to use (buttons, headers, etc) while the rest of the team didn’t put much consideration or focus on the choices. The designers felt that without a unanimous decision on certain ui elements they would be blocked from moving forward. Throughout the day the non-designer members of the team developed a new appreciation for the amount of consideration that goes into wireframing and website architecture and how deliberate many of the choices are. This was an interesting and unexpected learning process for the entire team.

The prototyping process was slow to start as our team downloaded and set up Keynote and Keynotopia. The design elements were not all easy to find within the numerous Keynotopia files and our team required extra to become familiar with using them. We acknowledged that it was a one-time delay, but was something to consider when bringing in new people to the design sprint (for example, a company CEO or product owner would not have the time to familiarize with Keynotopia beforehand).

Another challenge with Keynote was the inability to have variation in page sizes. Keynote pages are a fixed size so for a longer page there was no room to design below the fold. We felt constrained to fit everything into one frame, which is not realistic for web design where most pages scroll below the fold. Our solution was to span longer pages over two slides, which was not ideal for user testing.

At the end of the 4-hour session we had created a prototype of all the pages. Due to the amount of time it took us to familiarize with Keynote and the limitations we faced, the process was not as smooth or as fast as we expected. The final prototype had inconsistencies in fonts, button types, and placements of different elements. It required another revision before being ready to present in front of users. We questioned if the process would have been faster having a UX designer wireframe the entire storyboard.

Day four was by far the most ineffective day of the Google Ventures design sprint process. In our next blog post about day five: validate, we dive deeper into our frustrations and solutions to improve the exercises.