PAWN MANAGEMENT APP
In early Spring 2019, all of the students pitched an idea for an Android app. I was in the midst of the study abroad process at the time, and I decided to pitch an app about simplifying the study abroad process from start to finish. I called this app Student Abroad. After the pitches, we all voted on whose projects we'd like to work on. With several students interested in my project, I became one of the team leads.
UI, UX, Research
Desktop & Mobile App
I led a UX/UI app project with a team of 3 in my Interaction Design I class. As the team lead, I organized my team, created the schedules and deadlines, produced the high-fidelity prototyping, and was available for any questions my teammates had.
We began by gathering information on studying abroad and reviewing the research to give us a scope of what topics to focus on during the interview process. Research is essential for GDD; a design team must have understanding of their users, the product's constraints, and the business goals that are directing the design. The literature we found helped us determine demographics, students' priorities, and common frustrations in the process. We also audited other study abroad apps to determine which areas we could strengthen in the field.
Early in the GDD process, it is valuable to find and interview subject matter experts (SMEs)—experts on the area where the product focuses. We therefore began our interviews with Cassanda Danekes, Operations Coordinator & Gilman Scholarship Certifying Advisor for the KSU Education Abroad Department. She shared the parts of the process that students prioritized or put off, which pieces they looked forward to or dreaded, and which features may be most useful to students.
We then moved into interviewing current college students. According to GDD, interviews should ask open-ended questions that don't lead participants to the preferred answers so that we get unbiased, personal answers. These interviews, which typically ranged from thirty to forty-five minutes in length, focused on what the students experienced in their study abroad process - what they struggled with, what they loved, and what they wish they had done differently. We took this data and put it in an affinity map of demographics, user needs, frustrations, and goals. That helped us identify behavioral patterns, characteristics, and goals of our participants, which formed the basis of our personas, as described in the next section.
To ensure we were keeping the audience and their goals in mind as we designed, we created personas: example users based on our findings that represent the goals and needs of the overall audience. GDD prioritizes the use of personas because they provide designers with a focus point to think about how users behave, how they think, what they want to achieve, and why.
Our primary persona (the main target of our design) became Emma, who represents the highest priority and most common goals of our user base. The secondary persona is someone who is mostly satisfied with the primary persona’s interface, but has additional needs that can be designed to accommodate without upsetting the product’s ability to serve the primary persona. Those secondary personas are Sienna and Liam, who represents goals of our participants that were more uncommon but still needed attention to create a positive app experience for users.
MEET OUR PERSONAS
Emma is a junior Art History student. She's from a low-income family, so she’s intent on getting scholarships, but she is overwhelmed by the amount of research she needs to do.
She wants to find a program that’s right for her.
She wants to find enough scholarships to cover a large percentage of the cost.
She wants something to keep track of deadlines with.
She wants a way to talk to previous students or see testimonials.
Sienna is a sophomore International Affairs student. Scholarships aren’t a concern for her with her upper-middle class financial status, but she doesn’t know which program would fit her best, and she struggles with deadlines.
She wants a program with loose itinerary so she can have fun.
She wants a reminder and deadline system so she doesn’t forget important things.
She needs clear information about programs and how they complement her major.
Liam is a senior Mechanical Engineering student. He is clueless about going abroad, but it is required to study abroad for his program. He has put it off as long as possible because of his low-income status.
He needs to find scholarships, and he needs advice on how to increase his award chances.
He wants to find ways to “make the most” of his experience by finding other activities, etc.
He needs a place to keep track of which documents he needs.
Based on our research, interviews, and personas’ expectations, we created context scenarios—ideal narrative descriptions of personas using the product to achieve their goals. We did this to understand how their expectations would be met and to begin prioritizing the information and features in the app. Our team collaborated together in multiple sessions, basing our scenarios off of the affinity mapping and personas. This helped form a set of persona expectations and design requirements for our app prototype.
Emma Russell's Context Scenario (Above)
Design Requirements Preview (Right)
Once we had our personas set with their goals and scenarios, we worked to ensure we were meeting those needs. This brought us to the app's keypath and validation scenarios—common and uncommon paths that a user would take while navigating through the application. This ensured we paid attention to the flow of the app and its sequence of pages so that all goals and associated tasks could be achieved.
We then reached the prototype, which we completed in several stages. We began with low-fidelity prototyping on a whiteboard, sketching different ideas for the layout of each page. We modeled the layout almost as if it were a social media app, treating each program option as a profile you could flip through. Each team member created designs, which were then discussed and compared to ensure our different designs would still function cohesively. A few samples of my low-fidelity prototyping can be seen below.
Following the low-fidelity prototyping and the scenarios created alongside it, my team moved onto medium-fidelity prototyping. Based on what we created with our low-fidelity product, I began prototyping in Adobe XD. As I developed pages, we held voice conferences or met in person to discuss changes that should be made, making sure the design still made sense and met the user's goals.
To avoid the issue of clutter, we prioritized certain information to be displayed before anything else. For programs and scholarships, this meant due dates, terms, and reviews or award amounts. I created the idea of using icons for the terms (such as a snowflake for winter and a flower for spring), and these important pieces of information were displayed on 'cards' that users could click on for more information. The overall wireframe and a few page samples can be seen below.
With the approval of the team on our medium-fidelity prototype, I moved on to create the high-fidelity edition. This spanned one hundred artboards, all of which were fully designed and almost fully linked.
Once we completed our prototype, we moved into testing. Participants were asked to complete a series of tasks, such as finding a certain study abroad program, that took them through several features of the app. These tests gathered quantitative and qualitative data, such as the number of times they had to ask for assistance and their overall impressions of the prototype.
During the testing, participants were also asked to pick five Product Reaction Cards out of a total of 118, which gauge how desirable participants find the app, and what emotions are evoked while exploring it. Our overall results were overwhelmingly positive - all of the cards picked across five tests were positive, and when asked to specifically pick a critical one, several could not find one to select.
The constructive pieces of feedback we received were cosmetic-based and immediately adjusted for our final product, the largest of which was our color scheme. While some participants loved the colors and thought they were inviting, two thought they might be more appealing with a cool-tinted scheme that was more neutral. We now have two color schemes for the app - one based in pinks and purples, and one in blue and green. This alternative color scheme can be seen in the prototype.
THE FINAL PRODUCT
At the end of the semester, I gave a ten minute presentation of my team's process and final design to the class. I detailed each stage of the Goal-Directed Design process and how we applied it to our app creation.
I have to thank Brian and Henry - this could not have been done without my teammates. We have worked hard to create app that can truly help users meet their goals, and we are excited to present the final product of the app.
Click the phone to view the full prototype!