...
For the most part, the users were able to very easily pick up the features of the application, once they actually saw an action happen once. For example, once the user found the resizing affordance, they were easily able to understand how to resize contacts. Thus, we feel like a demo video, as mentioned previously, would be extremely useful to helping the user overcome these issues.
Reflection
One of the major lessons learned through implementing ContactLens was the balance of breadth and depth. Because of the vast number of APIs we were accessing, we quickly realized that we would not be able to implement a fully functional product in the timeline given. One of the difficult design decisions was to leave several of the APIs unimplemented. However, there was a large sunk engineering cost in the first week of the project setting up the product to be ready for use with all of the APIs.
One of the things we would have done differently would have been to decide earlier on to implement a single API fully, rather than trying to implement integration with 6 APIs at once. This design decision boiled down to the fact that we did not spec out the engineering guidelines of the project, or estimate the amount of time it would take to build the product, before jumping in heads-first and beginning to code.
We also should have gotten user feedback on the live site earlier on, since one of the screens which we invested engineering time into ended up getting entirely scrapped from the entire product. The team should have kept in mind KISS (Keep It Simple Stupid), and implemented the Minimum Viable Feature Set to test the product with potential users, rather than adding on bells and whistles before putting the product out in the wild.