Butter MEDIUM-FIDELITY PROTOTYPE 1
Our Team James Rose Elan Isha Schull Li Halpern Kumar 2
Value Proposition A farmers’ market in the palm of your hand. Problem The food sourcing supply chain is rife with ambiguity and inefficiency. The lack of transparency surrounding price, quality, and logistics timing unnecessarily complicates the relationship between restaurants and suppliers, creating the need for extensive middlemen. Solution We present a platform called Butter: a search engine and messaging platform that allows restaurants and suppliers to connect smarter. Producers can easily advertise their products while restaurants 3
Task 1: Find a supplier for a niche ingredient Restaurants, simple [no changes] 4
Task 2: Communicate with suppliers Restaurants, medium Originally: Communicate with suppliers about order status 5
Task 3: Get supplier suggestions tailored for you Restaurants, complex Originally: Get supplier suggestions based on input ingredients / menu 6
Task 4: Upload / update inventory with products to sell Suppliers Originally: Upload / update products you wish to sell 7
Feedback we received Major design change #1: when testing our Recommendations based on low-fi prototype last search history rather than menu week revealed that while getting supplier scanning suggestions from scanning a menu might sound cool, restaurants wouldn’t actually need new suppliers for every menu item / ingredient . We decided to instead incorporate supplier recommendations based on recent searches, which seemed to make more sense for our Before After users. 8
Major design change #2: Calendar integration functionality for both user types (suppliers & buyers) Testing on our low-fi prototype illustrated that automated message notifications to remind suppliers and restaurants about scheduled deliveries were a source of frustration. Receiving notifications in different chat archives is inconvenient and a source of frustration. Instead, we decided to develop a calendar feature to help users more easily keep track of order information in a centralized location. Before After 9
Major design change #3: Simplification of home screen / landing page During our testing, we noticed that users found the home screen unintuitive , and couldn’t find their way to key task flows like messaging and ingredient searching. We decided to replace the home screen buttons with a navigation bar that persists across the application, as well as a simpler dashboard. Before After 10
Task 1: Find a supplier for a niche ingredient | Restaurants, simple Click search icon Type in search bar Click search icon Scroll to see results 11
Task 2: Communicate with suppliers | Restaurants, medium Click on messages icon Click on a chat Communicate with your supplier / buyer! 12
Task 3: Get supplier suggestions tailored for you | Restaurants, complex Saved suppliers Suggested suppliers This task flow initially was our complex task, as it involved the scanning of a menu and sorting through the supplier suggestions generated on the basis of the menu. After user testing, we concluded that this was an inefficient and unnecessary action to personalize recommendations , and instead chose to place them in the buyer search page and the supplier home page. 13
Task 4: Upload / update inventory with products to sell | Suppliers Click + inventory icon Fill out all fields Click add to save Redirect back to home 14
Design + Wizard of Oz + Prototyping Tools Hard-Coded Prototype overview We used: ● Photoshop ● AdobeXD ● Procreate How the tools helped: ● To create the visuals for the prototype/graphics for landing and onboarding screens ● To mimic interactions available with the app How the tools did not help: ● Could not create the full breadth of options (e.g. horizontally scrolling on recommended boxes in the dashboard) ● Could not simulate typed user input per field without creating multiple redundant screens ● Could not emulate scrolling, animation, or loading symbols 15
Design + Wizard of Oz + Prototyping Tools Hard-Coded Prototype overview Wizard of Oz Techniques: ● Recommended buyers or suppliers automatically appear preloaded onto dashboard screen as if we were able to optimize suggestions using AI ○ Offering of optimal selections appears on multiple screens, including the search as well ● Simulating the passing and exchanging of messages between parties ● Simulating the filling in of all fields related to adding new inventory ○ On the supplier side Hard Coded Features: ● No features actually required being hard-coded, as most of our interaction is based on directly tapping. A few features that were in consideration to hard code included horizontal & vertical scrolling, and typing in text fields. Of the three, the typing of text is the most frequent and unavailable action in AdobeXD, but we felt that the end interaction could be conveyed using tapping and that hard-coding was not necessary. 16
Limitations to our prototype Limitation #1: Users can only search for suppliers by single ingredient Rationale: Previously we allowed users to input their menu and receive a list of matched suppliers, but we removed this from our current prototype because its utility is limited to very specific circumstances Limitation #2: No ordering functionality Rationale: A possible addition we considered was the ability to place and track orders between restaurants and suppliers, but we wanted our prototype to focus on a specific need (i.e. efficient communication in the food supply chain) Limitation #3: Interaction limited to buttons Rationale: A more developed prototype would include the ability to navigate between views via swipe gestures, as well as scroll through horizontal lists (such as the recommended Daily Goods). We wanted to simplify interactions for our med-fi prototype, and were limited to the gestures facilitated by Adobe XD, but these capabilities would be included in the future. 17
Appendix Additional prototype screens can be found labeled and in the order of task flows in our google drive folder: Assignment 6 > FINAL_MED_PROTO 18
Recommend
More recommend