Timeframe: 8 Weeks Year: Spring 2020 Role: Interaction Designer
Meet the team
Joey Spreha
Ana Ortega
Muhammad Bilal
Overview &
Challenges
As a group, we set out to create a solution for a problem that we found was prevalent around us. Through research, we found that a lot of people had very little to no knowledge about their own vehicle, those that did, had issues keeping track of their vehicle's information.
AutoAuto is an app prototype that is intended to help individuals keep up to date and track information about their cars. This allows users to log mileage, accidents, automotive work, and other information. AutoAuto can also be used for less experienced car owners in order to look up tutorials on basic car repair and to search for nearby repair shops.
Our main challenge during this project overall was time. With a compressed schedule of only 8 weeks, we had less time than usual to complete the entire design and goal-directed design process. As three graduating seniors with conflicting schedules, in-person meetings during these 8 weeks were nearly impossible and we all had to strive as a group to meet remotely or outside of usual hours.
Finally, with the sudden arrival of COVID-19, all institutional learning was pushed online. We found ourselves having to adapt to the nature of our group in order to be able to remain efficient as our "normal" changed. With social distancing put into place, all user testing had to come to a halt which affected both our user testing process and group meetings. Even without being able to physically meet during the end, we still overcame these challenges as a team.
Process
In order to properly solve our problem, we turned to a qualitative research process known as Goal-Directed Design (GDD). By using GDD we ensure that we are not designing for ourselves but rather for the user's needs. Goal-Directed Design has 6 main "parts" that we must go through as a team in order to successfully create a product that the users can benefit from.
Navigate ahead
Within the context of our assignment, our research step of Goal-Directed design included a kickoff meeting, literature review, competitive audit, Subject Matter Expert (SME) interviews, and user interviews.
Kickoff Meeting
Step 1
Research
A kickoff meeting is traditionally held with stakeholders in order to ask potential information gathering questions about the product and create the first ideas about the product and its vision. Due to the nature of our assignment, we did not have stakeholders as we did not have a client. Instead, we held the kickoff meeting amongst ourselves.
During this meeting, we agreed upon the idea for the app as well as the name AutoAuto, which is a play on words for "Automobile Automatically".
Literature Review
& Competetive Audit
A literature review and competitive audit are done to gather research and data that already exist that could help us in designing our app. Our literature review focused primarily on web searches and reports over the average person and their vehicle knowledge. We found that most people did not service their vehicles regularly or know basic information over their car's care.
Our competitive audit was done to search for products in the market that already exist and are similar to ours. We do this to view their success and setbacks as well as create questions for our product which will fuel its design. We found that there was no exact match for our app and that any similar websites or apps did not possess the features that we were hoping to give users with AutoAuto.
Subject Matter
Expert Interview
A subject matter expert (SME) is a person with authority over the domain in which we are creating our app. In our case, our SME was a mechanic who would be able to give us insight on what users may be looking for or may need in an app such as AutoAuto.
User
Interviews
User Interviews are conducted with or after SME interviews. Prior to user interviews, we constructed what we believed would be our personas. Our persona hypothesis was that our two main users would be mechanic-level users who were highly knowledgeable with cars and the "Average Joe" who had little to no car experience.
We picked our interview candidates only on the criteria that they owned a car. This made just about anyone eligible and we were able to grab individuals off the street.
Within the modeling stage, we synthesize the data we gathered from the research stage in order to create personas.
Step 2
Modeling
Creating
Personas
Personas are hypothetical users based and created using the research gathered during the interview and research phase of GDD. Personas are a tool used to convey information and concepts to stakeholders in a simplified way. Once created, personas are used to craft context scenarios that shape the functionality and design of our first prototype and eventually the overall design of our product.
Primary
Persona
Name: Emma Fanning
Age: 23
“I do my best to take care of my car, but I usually need help to do the basics.”
Bio:
Emma is a student and a casual car owner who visits the mechanic when the lights go off on the dash. She does not keep track of her car’s stats and cannot do basic maintenance beyond changing a tire, but even that requires help from a video. She uses her car for commuting and rarely goes on long road trips.
Goals:
Emma is aspiring to become a psychologist. She wants a resource that she can use to look up basic care tips. She also wants to be able to search up reputable mechanics and car shops nearby.
Secondary
Persona
Name: Charlie Edelson
Age: 23
“I can take care of my car on my own, but I wish there was a better way to do it.”
Bio:
Charlie is a college graduate looking for a job. He knows a little about cars, but not enough to be a mechanic. He occasionally checks the oil and his tires, but nothing else beyond that. When problems arise, he tends to just take his car to a mechanic and let them deal with it. He keeps receipts of all work and does service when he is told. Since Charlie drives every day, he wants his car to be in good condition but doesn’t know the best way to do that.
​
Goals:
Charlie wants a place where he can keep information about his cars, such as mileage and maintenance records. He wants a system that stores the history of his car in a reliable way, while also reminding him to service his vehicle and do regular checks.
Step 3
Requirements
During the requirements phase, the personas and research are combined using context scenarios in order to create the foundation for the app's framework.
Context
Scenarios
Context scenarios are used to place our personas into the context of our app. We use these scenarios to show how our products fit into the lives of our users and how they might use them. Context scenarios also create a list of requirements which later form the basic elements required for a low-fidelity prototype.
We use our context scenarios to support and create our design choices as context scenarios are based on our research-based personas and their needs.
​
Primary Context Scenario
Secondary Context Scenario
When Emma uses AutoAuto it is because she doesn’t track maintenance on her car, and needs to be reminded often. She also has no idea of how to do basic maintenance, or what anything is on her car, and would need help in doing so. If something were to happen to her car, Emma would not even know where to take her car for service. This is when she would use Auto2.
​
Every so often, our app will send a notification to Emma, letting her know it is time to check her cars oil, tires, belt, fluids, etc. She would open the app, and realize that it has been a while since any of those of last been changed, and probably needs to change them soon, but wants to check to see their condition first. Emma would then go to the tutorials page and read some of the basic included tutorials since she has never performed maintenance before.
Depending on the task at hand will determine the tutorial she reviews. Afterward, if she determines she needs maintenance, she can go to recommended shops, and find one near her that fits her needs. Emma will take her car to the shop and have maintenance performed. Afterward, she can go to the log page and insert the date and mileage, as well as other info to record the maintenance and set the next reminder. Emma will then close the app until the next notification comes to her phone.
Unlike Emma, Charlie often checks his car’s oil, tires, fluids, etc. He just wants a better way to track his information and record maintenance. Since Charlie often does his own work and modifies his car, he only needs the app for the log and service history options.
Charlie doesn’t have notifications for Auto2. He only goes on the app when he has performed maintenance on his car or swapped parts out. Charlie likes to be super detailed with his history and wants to include everything. So when Charlie performs maintenance, he opens the app and goes to the logbook. Here he inserts the action performed, the date, mileage, part name, and receipts if applicable.
He wants to keep this not only for himself but for others if he ever sells the car down the road. Also, since he checks his own fluids and oil often, he will go to the service history page to check the last time they were changed, and if they are due for a change, he will do it himself then update the maintenance in the logbook. Charlie will then close the app and won’t open it until he checks his car or does maintenance.
Requirements
Requirements are taken from the persona context scenarios. These are elements or features that are required for the personas to successfully execute their context scenarios. Such examples would include a login page, a tutorial page, and even a profile page. We create a list of requirements to ensure that AutoAuto has all the elements it needs to be successful in its design.
​
During our requirements process, we also discussed what our problem and vision statements were. A problem statement is an issue we are addressing while the vision statement is how we intend to address it as designers. These steps help refine our initial designs.
During the framework phase, the overall look and design of the app come alive. Using our requirements from the context scenarios, we have an idea of what we need in our app and now it is time to assemble it.
Step 4
Framework
Low Fidelity
Prototype
We began with a low fidelity prototype session by creating the basic wireframe of our app. Each one of us spent a couple of minutes sketching out what we believed the first few pages of the app would look like. We do this separately in order to create the most possible solutions to the design possible. From here, we pick the elements which work best in the design and insert them into a prototype software known as Figma to create a medium-fidelity prototype.
Mid Fidelity
Prototype
Once we gathered the most successful elements from our wireframe sketches, we began by assembling them into screens on the prototype service, Figma. We then took our screens and added functionality to allow for user testing to occur.
We tested our prototype by having three users go through tasks on our app and receiving feedback through a user testing technique known as think-aloud protocol. Some of these tasks included deleting one's account or accessing the tutorials page. The tasks were based on key-path scenarios we had created as well as other context scenarios. We use the feedback from these user testing sessions to create changes in the app as problems arise or as more efficient elements are implemented.
Step 5
Refinement
During the refinement phase, feedback from the user-testing session is taken and applied to the design. Changes are made which benefit the usability of the app by using data given by users.
