Understanding the problem
Before we start we try to identity the primary problems we are trying to solve. While more problems may surface through development, choosing the major problems to resolve allows us to focus on the goal of the application.
The initial problem is time. (We) do not have time to sit around finding what we should eat on a daily basis. We also do not have time to figure out what kind of ingredients we have in the house. The goal is to help the user save time by helping them find recipes quickly based on the ingredients they have.
Money and food go hand in hand. This application will help find the item’s you already have, stopping you from buying more of what you PROBABLY already have.
This team has three members to distribute roles, Josh Coldiron, Cory, and Daren. Between them, there are various tasks, some of which are joint efforts, that they will carry out. Each individual will be evaluating some subjects of their own as a means of research for this project. Each of them will provide input and testing on the development of the program’s requirements as well as its input functions. Josh will be handing the documentation of the project, as well as design specs, and UX documentation. Josh will also provide the UI wireframes to be implemented. Corey will lead the databased information and setup and provide the research that allows it to hook up any related APIs to be used for this functionality. Daren will lead the foundation of the application and related research to make it operate and be compatible with the UI and database API. All three team members will be involved in the QA and relative co-tasks that support each other’s primary tasks.
The task to be performed initially will be developing a full minimum feature list, which will be done by all three team members. Next, a UX persona and design spec will be assembled from the team’s notes by Josh. Once this is complete the team will review it and amend it. After the direction and checkpoints of the project are established by the team Corey can begin assembling a database. This may be as simple as an array of information that can be queried by the application for demonstration purposes. Once a collection of recipes is established Daren can begin testing out various interfaces with the data that allow us to use the application to request them and display them. During this time Josh will be working on a basic wireframe of the UX with input from the rest of the team. Once the basic application works in the manner in which we intend, then Josh will implement the UI into the system. A secondary feature list will exist depending on if the project is done early enough to further flesh out functionality.
To beginning the project as well as its documentation, I feel it is important to come up with project goals. I think one way is to get into the heads of our users with personas. With the group notes I devised two personas for the project. A student named Stan and a Single mother named Masha.
Looking at this information as well as asking questions to our stakeholders we begin the process of brainstorming features. Tasks are a way of sorting out features that we might include to resolve user goals.
We also look at the following basic purpose of this application and the problem it solves: This application was developed for all people young and old. We designed it to assist all of us in what we should make for dinner after a long day. The application will help you pick out what to eat and how to make it. If you can’t find what you want or don’t have enough to make what you want the application will find you somewhere to eat.
Below are the initially proposed features. These features are the primary goals of the project development and the basis of supporting features.
Inventory food items
Inventory alcoholic drink items
Find recipes based on inventory
Find drink mixes based on inventory
Find a Restaurant near the user’s location
Storage: The first task is how we put our supplies into our database. There should be an addition to the button, that the user could use. After pushing the button, the screen would change and would go to an additional list. On this screen, the user would be asked to enter the food, spices, and other items into the list and save the list to the database. After saving the information into the system, the user at the top of the screen can change from different screens and could hit the home button. The slider bar at the top of the user’s screen can be used as a better or quick screen change.
Slider bar: The slider would be the next task for the user’s easy navigation. It will consist of all buttons that the application will be able to go to, with the quick access the user will have full rain of the features. The usability is more intuitive for all people. This bar does not show on the main screen or the home screen. Its abilities are for each of the other screens to help the user better navigate without having to go back to the home screen. This should save the user a step and time in the process of their using the application.
Home: The home functions are much the same as the slider bar. This is where the application will first start the user experience. Each of the functions, pantry, drinks, find recipe, find a restaurant, add to list and settings will be located on this page. Large buttons will be implemented for an easy visual representation.
Pantry: From the pantry page, the user can also put food and supplies into the pantry list with a simple add button. This list will show the user what is currently in their inventory. The list may also show what the user is in need of. However, with this function, the user will need to answer a prompted question if the users still have any ingredients remaining.
Drinks: For this task, we would like the user to be able to have the ability to search for drinks based on what they have in their household. The user should already have drinks added to their pantry in which case they can then either select all the drink ingredients they currently have or select the desired ingredients they wish to make a drink out of. If the user does not have any drinks in their pantry the app will alert the user there are no drinks in their panty. In case the user is just prospecting, they can still continue to find a drink with specific ingredients but will not be able to select the “select all from pantry” option.
Find Restaurant: For this task we want the user to reply to the software to decide where to eat. This feature will allow the user the option to select from a specific kind of food they will eat that meal, Or the user can get an entirely randomized food selection. The software will also allow the user to select a mileage range they wish to travel to get to the randomized restaurant. If the user does not select a mileage range the software will automatically set the search range to 10 miles.
Initial pencil sketches were done to plan out the placement elements of the app. The next phase was devising the architecture in which the user would navigate the process of using the app. Before presenting I remade the initial wireframe concept in Balsamiq for better presentation and clarity when articulating the concept to the rest of the team. After discussion with the team, we were able to use the notes from this and our research to develop our first low-fi wireframes.
With the initial wireframes, we want to focus on the features and evolve the design. Even in the early phases, I feel it is important to make it somewhat visually appealing, even if not fully fleshed out. I do a quick and simple logo design to make it feel somewhat official. For the UI we allow the buttons to be the sole focus of the visuals as we want to test and refine the functionality before we do a complete visual overhaul.
Another component to creating a functional visually coherent design is to rely on the OS native graphics. The user is normally already familiar with them and aware of their function. This reduces the learning curve and allows them to focus more on the newly introduced features.
Some steps can be time-consuming such as populating image fields with relevant images, but I think the more functional the wireframe feels the more the tester can use it as if it was a functioning app and give better feedback. You can try out the XD prototype here. It will load in your browser.
“Aesthetic Usibility Effect is when a visually appealing utility makes the user more interested in learning it.”
Each member did an interview and questionnaire for those we interviewed. We then put our information obtained from the interviews into the above table and averaged the marks. Each member after receiving feedback from the interviewee changed the low-fi and re-asked questions in class to see if others also responded to the changes to the design. Each team member also would take on making adjustments to components of the design as they were available.
For our interview, we have a largely unstructured script, with the intention of including certain information. Initially, we establish a frame of mind. We inform the user about what the application is, what it does and how a prototype functions differently than a fully-fledged application. We then ask them how they perceive the application, and if it seems to reach that goal. We also asked if this app meets their expectations based on their initial information or how it is different. As they continue through the app, we answer the questions they ask if any questions arise. We also ask questions along the way about the types of dishes they would like to cook, and under what circumstances they might use this app. Once they have finished that component we then ask them if they feel familiar with the app. If the answer is yes, which it was in all cases we would then ask them to add an item. If it were no, we would help clarify, however that was not needed. During the process of adding an item, we timed the user to see how long it took. Once that process was complete we went through the questions that were rated for agreeing to disagree and took their score. Along the way, we would note their responses to these questions that were in addition to their numerical answers. We then thank them for their time and conclude the interview.
excerpt from my Interviews
My interview began explaining what the app did. I then explained how this prototype experience is slightly different from a fully functioning app since it is scripted. I first asked the user to just click around and explore the app. I asked them to let me know when they feel like they are comfortable with the program. After they had some time with it, I had them go to the main menu, and I timed them for the full process of adding an item. Afterward, I had them answer the questionnaire. Once that was done, we continued the rest of the interview in an unstructured manner. I was able to get feedback about areas that felt less clear or difficult than others. She is a working mother and likes the idea of the app to keep track of what she has in the house and what she can cook without having to go out.
My next subject is a design student at SIUE. I followed the same process for her as I did with my previous subject. I explained how a XD prototype differed from a regular working app. I then explained what the application’s use was. I asked her to go ahead and get familiar with the different sections on her own. As she would go along she would ask questions about certain functions and then mention how they pertain to her. She also brought up a few interesting points. She feels like there is lots of clicking and would like less of that. She mentions that she does not know what the current inventory is when she is adding an item. This is something we can consider as a later feature. She also would like to see a feature that allows her to delete items from the inventory in case she cooks without using the app. She mentions she would not likely use an app like this since she cooks very simple dishes and does not want to put the effort in logging her inventory. I was able to get feedback on possible features that might streamline the app and make it more usable.
We found the process of adding items one of the biggest factors that could affect if a user utilizes our app. We took data from our initial prototype and streamlined the process to reduce the steps and time greatly.
Average initial time: 14.25s
Average redesign time: 6.75s
Average time save: 7.5s
Examples of change
A menu option was added to the inventory to change details or delete items.
Another major addition was the photo icon added to the first add item page. This reduces steps greatly with an autofill option when a barcode is scanned.
Doing interviews, and testing greatly affected the end result of our prototype.
Come up with solutions to previously unknown problems.
Use metrics as a guide to improving features and usability.
Prototyping created a very useful tool for feedback and development.
Helped in flow organization.
Help establish the design and function of UI elements.