Socheata Huot
My name is Socheata Huot. I am in the class of 2025, I am planning to major in Civil Engineering. I am interested in construction and sewage systems. I like exploring nature and riding a bike.
Kat Walton
I am a Freshman Civil Engineering major at Lafayette College. I am a member of the school’s Cross Country and Track and Field team and mostly run middle distance/sprints. In my free time, I enjoy spending time with my teammates and other friends doing anything from watching a movie to taking day trips to the beach!
Brian Reilly
I am a Junior Economics major at Lafayette College. I am a member of the football team and play inside linebacker. I enjoy spending time with family and friends, playing golf, and going to the beach.
Carter Gates
I am Carter Gates and I am a Mechanical Engineer at Lafayette College. I am a member of the club squash team at Lafayette. Outside of school, I like to hang out with my friends, fish, be active in the outdoors and play golf.
Asher Ricci
I am a Freshman Mechanical Engineering major at Lafayette College. I enjoy spending time with friends, playing sports, baking, playing instruments, or just being outside. I play basketball, football, golf, and surf in my free time as well as playing lacrosse, squash, and Spikeball at the club level at Lafayette.
Discover
The first and possibly most important part of the design process is to identify the problem. We were given the problem of redesigning a grocery store. After that our next step was to decide who our users were. To do this all the group members separately created a list of possible users that are related to grocery stores. We brainstormed all the possible groups or people involved in the grocery store process and experience. We then shared our lists and combined them into 5 groups.
- The Consumer
- Farmers and Producers
- Shippers
- Owners/Employees
- Other
We then ranked the different “stakeholders” or users to decide which group we most wanted to design for. We decided to target a very broad category of stakeholders, adult, and young adult customers(consumers).
The next step is to collect data from our users. We used qualitative user research however there are a few ways we can go about doing this type of research. We landed on conducting a structured interview to collect our data. This means that we have a set of questions that everyone will be asked and we can target very specific questions that we might have about our user. This was favorable because we could attain very specific information from our users. If we were to use other methods such as observation or unstructured interviews, we may not get the information needed to solve the problem we were given. Our questions were as follows,
- Do you like/enjoy your experience at a grocery store?
This question sets the tone for the interview. While most people are inclined to say yes, if they hesitate, or say something such as “sometimes” or just “no”, we know that they clearly have issues with their experience. This knowledge helps us as we go about the rest of our interview with that particular customer.
- How frequently do you go to the grocery store per week?
- Which grocery store do you go to most frequently?
- How much do you spend on groceries on average?
The next three questions were to get the customer talking, comfortable, and to give a little background on their experience with grocery stores. It may not be of much importance, however, from these questions, we can understand their experience with grocery stores.
- What do you like about grocery stores (that you normally go to)?
This question gets the user thinking about what they like and dislike and essentially primes them for the next two questions.
- What are the challenges while shopping at grocery stores?
- Do wish that grocery stores would have done anything differently to improve your grocery shopping experiences?
These last two questions are the heart of what we are looking at. This tells us exactly what they see wrong in their grocery store experience. These two questions outline the user’s needs for us.
Two of the group members went to the grocery store to ask customers there, the rest of the group asked students around campus as well as older family members or friends for input. Each student collected about 3 responses to the questions while also keeping track of the demographic of the customers asked. All of the users we asked needed to fall in the young adult and adult range because that is who we were designing for, however, that group is very large. So, tracking the demographic became critical to our data pool as we need a diverse group so that everyone can be properly represented in the solution. We tried to target people of varying races, genders, ages within the range we set, and even those who seemed to have different backgrounds such as single or married, kids or no kids, and we even targeted some DoorDash shoppers.
Define
Once all the data was collected the group looked through the responses to determine the main needs of our users. We mainly focused on their answers to questions 1, 6, and 7 as they are the most telling about their needs and overall experience. The answers that came up the most among users’ responses were identified as the most important needs to accommodate. We took our users’ frustrations and turned them into needs for our solution. The needs of our users were
- A shorter amount of time in the store, especially faster time finding products and checking out
- A simpler self-checkout system and layout to the store
- A better weighing system in the self-checkout line
- More accessibility for people with disabilities (Wheelchair accessible, Closed Captioning)
We used these consolidated needs to create a persona. A persona is “archetypical users whose goals and characteristics represent the needs of a larger group of users” (Faller, 2019). The final persona we created is the first slide of the presentation linked and shown below.
In the creation of our persona, there is an understanding that we have natural biases and that there is possible discrimination going on. So, we created an antipersona(linked above, pictured below). This is the second slide of the presentation linked above. By creating this antipersona we defined the people for who we were intentionally not designing this product. This was important to note so that we knew we did not have to think about accommodating them, however, it was very important in realizing exactly who we were designing for. We went back to our persona sheet to see if the people excluded in the persona sheet, were the same as those on the antipersona. We found that there were a lot of demographics of people that we were not included in our design and unintentionally excluded. We redid the persona sheet to make it more detailed so that it included a broader demographic of people. We now intentionally included people with certain disabilities.
The next step was to create a well-defined problem to solve. Often problems can be over-constrained or too loosely constrained which leads to a bad solution. A sheet of functional requirements can help to create a well-defined problem. We created our functional requirements by discussing as a group a fair goal for the needs provided.
| User Need | Functional Requirement | Type
(Objective or Constraint) |
Metric
(How will it be measured?) |
Specification
(Target value) |
Priority |
| Faster self-checkout | On average 5-6 seconds or less per item | Constraint | Seconds | N/A | 1 |
| Simpler system | Less than 2 errors per check-out | Constraint | Per error | N/A | 2 |
| Better weight system | Less than 2 errors per check-out | Constraint | Per error | N/A | 3 |
| Accessibility to system | Someone with a disability could use the system | Objective | ADA Standards | ADA regulations and laws | 4 |
Design and Develop
Now that we outlined our users’ needs and other important concepts such as deliberate inclusion and exclusion, we can accurately design and develop solutions to our problem. As a team, we brainstormed many possible solutions that could solve one or more of the needs we had. Once we had all of our possible solutions, we created a final list based on which solutions best solved our needs. We came up with a final list of 5 possible solutions for our problem.
- GPS with Closed Captioning on the shopping cart along with an app containing products and payment methods
- Amazon cart: a cart that scans items as you put them in the shopping cart and bills an account set up with the store
- A simpler self-checkout computer system: refining the system to have fewer buttons and redirections
- A more accurate scale: a more sensitive scale that will read when an item is bagged.
- AI help service: oftentimes the self-checkout system glitches and requires assistance, this assistance will come from a more helpful and competent AI system rather than a possibly less efficient human employee.
Once these solutions were developed, we needed to evaluate each one on how they addressed our users’ wants and needs. To do this we utilized a Pugh Template which simply breaks down which solution is the best by comparing them in an organized manner.
| Priority | Functional Requirement | Weight | Idea 1 | Idea 2 | Idea 3 | Idea 4 | Idea 5 |
| App/GPS | Amazon Cart | Simpler System | Accurate Scale | AI to solve glitches | |||
| 3 | App for products in stores | 25 | + | + | 0 | – | – |
| 1 | Simplicity | 30 | + | + | 0 | + | – |
| 5 | Better weight system | 10 | – | – | 0 | ++ | – |
| 4 | Accessibility(Closed Caption) | 10 | + | – | 0 | – | + |
| 2 | Speed | 25 | + | + | 0 | + | + |
| Total Pluses | 80 | 80 | 75 | 35 | |||
| Total Zeroes | |||||||
| Total Minuses | 10 | 20 | 35 | 65 | |||
| Total | 100 | 70 | 60 | 0 | 40 | -30 |
The Pugh Template helped us to effectively choose the best option which was the GPS shopping cart with an accompanying app.
Deliver
Now that we have our solution, we started to work toward delivering that final product. The first step toward this was to prototype the solution.
To begin prototyping we used a planner to lay out what the prototype will look like and what we wanted to get out of it.
Once we planned out our prototype, we delivered it in the form of an interactive Google slide show.
The prototype was tested by the other students in our class and we received feedback from their interactions with the prototype. Mainly the feedback was centered around making the design cleaner and simpler. This feedback was used to fill out the “Act” column in our first prototype. Once we had this feedback we went back and iterated our first design. From the testing, we realized that the prototype had many glitches such as links not working and some links going to the wrong slide. This made it very hard for the user to interact with the prototype. Using this feedback, we went back and made a second prototype planner.
After this second planner was filled out, we clearly understood what needed to be changed in our design of the prototype. (The link to the prototype is below. To use, start on the first slide, go into “present” mode, and then try and complete the tasks by clicking the different features on the screen.)
The prototype was tested one final time by the senior engineering students and the feedback was very positive. They found no glitches, and all the links worked which were both big improvements from the last time we had students test our prototype. The senior students liked the layout and had almost no trouble navigating through the app and overall had no complaints.
The Process
It may seem basic, but the biggest part of our success as a group was good teamwork and communication. Through the design process, these were two strengths that were critical to creating a great solution. The ability of our team to properly, freely, and easily convey ideas to each other lays the foundation for success. So, it may seem simple, however from the start, we were putting ourselves in a good place to succeed by listening to each other well, communicating well, and overall, just working well together. Another step that our team did well with was properly identifying needs and solving them. Once data is collected it can be very hard to analyze that data and pull out a need from users. Our team did an amazing job identifying the needs of users so that we could find a proper solution. And in our creation of possible solutions and in the process of picking the best one, we always kept the users’ needs in mind and made sure to meet all of them.
As a team, we did face a few challenges along the way. From the first time, the project was introduced a few of the group members already had possible solutions that they wanted to try. While they were good ideas and the team was being creative and productive, we were jumping to conclusions before doing anything else. Often times through the design process we had to all step back and realize that the process is there for a reason and it will only help. By identifying users, getting data, identifying needs, and then coming up with multiple solutions and weighing our options, we came up with a solution that can solve a big problem in grocery stores today instead of just fitting what we thought we should solve. Another big challenge was being intentionally inclusive in our design. We created a persona, and an anti-persona and realized that they just didn’t match. There were groups that weren’t in the persona, but also weren’t being intentionally excluded on the anti-persona. So, we had to iterate our persona many times and iterate our possible solutions so that they included more features to accommodate people with certain disabilities.
Now that our group has gone through the design process and reflected on our successes and challenges, we can also reflect on what our group would like to have done differently. When we collected data, we only used the method of structured interviews. In the future, we would like to incorporate other methods of collecting data, possibly an unstructured interview, or observation. This will give us greater diversity of responses and cover some gaps that structured interviews may have. Another aspect we would like the change is to try to eliminate designer bias. Many group members who came up with solutions that were being weighed to be the final solution were heavily biased toward their solution regardless of its benefits and shortcomings. So now that we were aware of this bias, we will be able to work past it in the future.