...
We learned a lot over the course of the design process. Most of our general intuitions were right. In the beginning, we predicted that it was best to make more risky design bets - because the cost for testing was slow. This proved to be true. We were able to quickly determine what worked and what did not, and for a low-cost. Also, this allowed us to move to a consensus pretty quickly. We also learned an obvious, yet important truth out of this: “keep it simple.” Though we tried a lot of design risks, in the beginning - we almost ended up using none of them past the paper prototype stage, resorting to a simpler step at each stage.
...
If we were to do this again, we would probably add another round of paper prototyping right after the heuristic evaluation. Seeing those changes enacted for us on paper would firmly solidify the new additions of decisions and help us confirm them with the user. Though heuristic evaluation is important, we have to come fundamentally believe that user feedback triumphs all. Therefore, testing a round of heuristic evaluation before our final project would have perhaps helped us avoid our problems with feedback on filtering and carts. We realize that going from computer prototype to heuristic evaluation midway is a change in direction (from high to low fidelity). However, it would've helped solidify our final conception.
Also, one issue that we faced while prototyping for mobile early on was having too large paper prototypes. Usually in terms of prototyping for web, bigger prototypes help. However, for creating and designing paper prototypes, we felt it was best to have smaller prototypes. For designing on mobile, screen real estate is key. The earlier this constraint is imposed - the better. We spent too much time narrowing down what was good for the small mobile screen and what wasn’t. If we had the imposed the constraint from the beginning, we would have narrowed down features sooner, and user feedback during paper prototyping would have been more accurate. Therefore, we would a paper prototype with a smaller screen size; the size of the phone would be best.
...
One last meta-level decision we wish we had made was piloting this with a restaurant through some pre-arranged agreement. This would have enabled us to try and test this in real-time and get exact user-situation feedback. We tried testing this live at Flour Bakery (however, this didn’t work as planned as explained in the Evaluation section). A better way to go about it would have been making an agreement before for a set day and time - and testing it with the users present at the restaurant on that given day.
...
However, we recently encountered a startup, out of MIT CSAIL, called Locu that exists to solve this very problem. Locu has an API that indexes the menus of several restaurants so that they can be queried via other applications. We plan to integrate with this API (http://developer.menuplatform.com/) so that this app can truly be scaled to be released.
We also plan to incorporate A/B testing available via companies such as MixPanel and Kissmetrics to make the app more usable, and increase conversions. However, before we plan to release, more work on the HTML, CSS and Javascript remains to be done (such as fixing the usability issues described above and more robust user testing).
Yet, we are excited about releasing this for the public to use!