SIUE HCI Project
Easy Dinner was a final assignment for my Human-Centered Interaction course at SIUE. The project required covering various aspects of User Experience as well as measuring some metrics that could determine as improvements through testing. My team consisted of two software developers and myself who focused on the visual design, documentation, and UX components of the project.
You can try out the XD prototype here. The prototype is scripted, and clicking on various components will allow you to simulate using it on a tablet device. The demo can also be experienced on an iPad using the Adobe XD app. Begin by selecting the icon from the home screen. The following info is the process of development of the project.
One issue with a project with no client is finding a purpose. Commonly solving a problem is a good approach. We had discussed ideas from binaural beat generators to organization apps. We focused on need finding. We observed people we knew and asked questions. As a group, we discussed our findings as well as our own needs. We found a common ground for problems to solve, food.
Understanding the problem
Before we start we try to identify 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.
The problem we chose to resolve is one in which people would like to make dishes that require ingredients they already possess. Rather than having to hunt through websites and cookbooks that provide the query by dish name or type and then reveal the ingredients, we propose using the ingredients as the query element. Some similar concepts to this exist however these pose a tedious interface problem that requires you to enter your ingredients each search and also explore your pantry to see what items you have in stock.
The target user groups are anyone who chooses to make their own food and does not want to or is not able to go out to get additional items needed for a dish. This could be expanded to anyone who simply cooks and wants to know what they have or someone who has extra ingredients and they are looking for ideas on how to use them up. We could include users who are wanting to explore new dishes, and this application might allow them to see what common ingredients they have and how those might be used for dishes foreign to them. Lastly, we can also consider anyone who wants to keep an inventory of items they have. The demographic is quite broad, which means we need to design for the average user.
Our solution is geared around two basic concepts. An application that keeps inventory of all of one’s ingredients and allows them to do searches that return recipes based on what they have in stock. This will allow the user to quickly find recipes, learn new dishes, and not be troubled to go out to get more items. Rather than just searching through their pantry to see what they have this will also allow them to maintain their inventory as well for when they use up ingredients.
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 handling 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 database 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 begin 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 with 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 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 a 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 the 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.”
Changes After Testing
When testing this application with our interviewees we found data based on our questionnaire, our interviews, and the timing functions of the app.
These changes include adding functionality to the app. We incorporated the ability to manually change or remove items from the inventory under the conditions a user may not always use the app, which could lead to inconsistencies. We also found the process of doing all of the inventory took many steps, and while this did not detour our users we found a way to give a streamlines option to make the app more enjoyable to use. In addition, other minor changes were made to ease the use of the application.
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