KODA
Project Overview
KODA is a prototype project created in a senior capstone class at Kennesaw State University. My team and I created KODA with the intent of working with mutual aid to actively strike against the pink tax and provide feminine care in lower-income areas.
Our goal was to create a kiosk in public locations like churches and schools to provide on-the-go products at a lower cost supplemented by donations. We aimed to also help bring awareness to women’s health, and common sexual diseases, and provide resources for women to get further care if needed.
Details
Role: Team Member ( Team of 4)
Duration: 10 Weeks
Tools: Figma, FigJam, Teams, Adobe Illustrator, and Rhino
Problem
In this class, the directions are incredibly open ended, basically just “make a fully functional prototype”. With this being most of our last and final school projects, we wanted to branch out and create a kiosk rather than a website or app to expland our abilities and frontier new territory. As a group, we went through social issues to find a problem we felt we could fix. We found that womens access to feminine care and medical attention is incredibly limited in lower income areas. Women will create their own feminine products when can cant afford to purchase items or do not have the resources to get to the store. This includes using diapers and toilet paper as pads, free-bleeding, rewashing pads and underwear, and overall neglecting their hygiene, health, and wellness, due to the expense of resources.
Objectives
research women’s wants and needs
create a kiosk prototype
develop a physical ATM mock up
prototype a website for further KODA resources
create a business strategy of feasability
Method
KODA was created with Goal-Directed Design as its guiding method. GDD was created by Alan Cooper and used at the Cooper Design Agency. This method is focused on “design of behavior” meaning we start with a stakeholder meeting to set expectations and ends with a user-achievement-based design.
For this course, we adapted the GDD process to include research, modeling, requirements, framework, and refinement. A further explanation of each phase as well as what my team completed during each phase can be found below.
Research Phase
In this phase, my team and I conducted a kick-off meeting, persona hypothesis, literature review and user interviews. This research phase was vital to our success so my team and I could better understand our scope, and what else is already out there. Without this phase, we would’ve been blindly designing what we thought would be best rather than keeping the problem and what else is out there in mind.
This whole process was research into who are users are, their struggles and needs, how other feminine care providers are working, what they do well and what we could do differently, and overall organizing our problem, goals, and measure of success.
Kick-Off Meeting
The goal of the Kick-off meeting was to get everyone on the team focused on the same scope and goals. We collectively developed a problem statement as well as assumption statements. We focused on how we could best tailor our app to the intended target audience, women in need of products and care needing easier access and less expensive options. We came to the conclusion that KODA wants to help women in public spaces by providing local kiosk ATM’s with products as well as the option to donate
The literature review set the foundation for our research. We began researching the context of our product domain trying to answer the essential question of “what do we need to about our product domain to be more effective designers?” which we found 5 citations to expand our knowledge. Looking at articles about menstrual product access challenges, period poverty, unmet menstrual hygiene needs, and period stigma explanation, we got greater detail on our broad knowledge of women’s health and menstruation. I think this phase was dire for our success to understand just how challenging it is for women to receive the help they need when it comes to “down-there care”. This phase gave us specific metrics, examples, and shocking stereotypes that need to be recognized socially.
Literature Review
Competitive Audit
In this competitive audit, we found five companies that applied both directly and indirectly to our goals that we could research and evaluate into positives and negatives to further determine our scope. We first chose Planned Parenthood which holds informative articles for bringing awareness to sexual health but has limited access state to state. We then chose Hers which gave online access to medication but at a high barrier to entry due to price, shipping, and online only access. We then looked into Sprinkles, a cupcake ATM to research the ATM’s abilities finding that the walk up access and customized experience gave users a lower barrier to entry and enhanced user freedom. We then looked into the Period Project Organization and the Pad Project Organization both similar in nature being a donation based outreach program providing products to lower income and limited access women. In both organizations the complete reliance on community donations and collaboration limits the ability to provide and no real metrics of their reach are shown.
After completing the competitive audit portion of the research phase, we specified our goals and must haves for KODA.
These goals include:
KODA ATM’s need to be in public easily accessible areas
the ATM needs products to be exponentially cheaper than in stores
there needs to be a donation aspect for community collaboration and to supplement the price of products
KODA needs to have an outlet for information that is external to the kiosk (hence the website)
User Interviews
This part of the research process was absolutely vital to our team and KODA’s success. As a team, we collectively selected five individuals who we felt fit our persona hypothesis and would help us flush our the primary persona. These interviewees gave us an insight to their personal experiences of being a woman, having feminine needs, the access they have to care, and their personal issues with the current providers of care.
We conducted these interview with the enitre community of women in mind choosing various ages, races, demographics, and locations. Throughout this research, we decided to expand further and send our a survey to have a wider reach with the limited time we had.
Overall, several key findings including:
Budget is a strong barrier to women getting care
People favor convenience, easy access is necessary
Users may or may not always have access to a car thus, centralized public locations of the kiosk
Some interviewees struggled more with find doctors and receiving care and information
Women want their needs heard and address at a larger scale
Persona Hypothesis
At this point, we jumped straight into our persona hypothesis template. The goal of this was to figure out who our team assumed the ideal interviewees would be. We struggled a good bit with this phase because their were some discrepancies in what we wanted and how to break the information up. We ended up with 1 main type of user being a woman of course but not neglecting to include transitioning individuals and fathers of daughters. We broke this main type of user into two actions, donater and receiver. We then took their needs, limitations, and goals and then further looked into their ranges of behaviors and types of environments that we needed to explore. We ended with the basic vision of a persona, ideally a younger woman living in a moderately dense city in a lower income bracket.
Modeling Phase
The modeling phase was where we took our previous research of users and sought out patterns, goals, and ended up with a more hands-on representation of our research and reasoning. We did this by creating a primary persona, to cohesively emulate our primary intended user. To better explain, a persona is a fictional character based on research patterns to represent different user types. Personas are used to help better understand a user’s needs, goals, behaviors, and preferences.
With the shortened amount of time, we focused on creating one primary persona. The primary persona represents dominant patterns seen during user research while the secondary would display residual patterns that still hold impact.
Thus, We introduced to you, Leila Eleter.
Leila Eleter exhibits all the basic needs of an average woman when it comes to feminine care. She is a college student and part time server who prioritizes taking care of her health and well being. She wants to feel safe and comfortable when accessing care and talking about her female experiences. She wants to further her knowledge on her own body and how to best take care of it. Leila’s strongest barrier is money, paying for college on her own takes up most of her serving pay checks leaving little for necessity. Living in Athens, she would have access to walk or ride her bike to a KODA kisok location on campus or at her local church.
The key question now is how did we synthesize five interviews into a representative made-up person? These personas are not simply creations of what we think a user would be like. To better explain we broke down all of our user interview information and webbed them together in a scaling environment.
To begin, our team identified behavioral variables we witnessed during interviews, these variables ranged from interviewee thoughts, actions, wants, attitudes, motivations, experiences, and abilities. We then are directed by GDD to map the interview participants on the previously created behavioral variables. This map acts as a scale visual continuum.
Identifying Behavioral Patterns
After placing the interviewees on the continuums, we looked for clusters that would represent dominant patterns. This brought to light the differences and similarities between our interviewees. We highlighted these groups of similarities and differences by common clusters to help create our primary persona and identify their wants and needs.
Requirements Phase
In this phase, we focused on defining what is required in the kiosk to help the persona achieve their goals. It is important to note that requirements are not supposed to be features rather they are the functional needs of personas turned into qualities of the future product. All of these requirements are created by first putting the persona into a context scenario of them using the app for a certain purpose and then extracting functions or expectations in the form of requirements.
Defining Product Vision
In Goal-Directed Design, we are starting with problem statements and vision statements based on user goals and user frustrations. In this phase, it is important to note the difference between a problem statement and a vision statement. A problem statement implements the stakeholder or business goal. A vision statement is the user goal that creates a design objective.
Our team then envisioned KODA kiosk. We brainstormed the potential creation and qualities of KODA. Then, we identified persona expectations. It is dire that the design aligns with user mental models or it will create challenges for users to achieve their goals. The persona expectations are built from the persona narrative, interviewee attitudes, and experiences. This process posed a challenge for us because its hypothetical since the app has not been created yet.
Creating Context Scenarios
We then put together a context scenario, which is a narrative that highlights the primary touch points that the persona would have in KODA. This narrative is told from the persona's perspective and focuses on high-level interactions within the app. The team and I imagined a hypothetical day in the life of the persona Leila and how she might use KODA in an average school day period emergency.
Using this scenario, we finally identified the requirements for KODA. We list these requirements in a certain sequence laid out by Alan Cooper where it begins with a base sentence of “call a person directly from an appointment”. In this sentence call is replaced with any action, a person is replaced with the object, and directly from an appointment simply describes the context.
It is important to remember although we are focused on the user goals in GDD, we note that these goals exist in tandem with business goals. We also list the requirements business, brand, and technical requirements. This gives us a list of what needs to be built for our next phase. At this point, we had decided in order to satisfy all needs, a secondary website with further information on wellness including diseases, what to dos, and medical advice would be neccesary.
Frameworks Phase
The frameworks phase of GDD is a personal favorite. The main goal of this phase is to lay out a baseline of low-fidelity wireframes and then build on them to create high-fidelity versions. Wireframes are the basic structural layout of an application focusing on the behaviors of each page, the flow from page to page, and the organization of those pages. These wireframes are highly impactful to the success of a designer because they act as design guides for the high-fidelity frames.
Low Fidelity
In GDD, we create wireframes by creating Key Path and Validation Scenarios. To further explain, a Key Path Scenario is task-oriented paving out the most well-worn or used path the primary persona will take through the app while, a Validation Scenario highlights the screens that are less frequently used but may satisfy the needs of the secondary persona without harming the experience of the primary persona.
To begin this process, we slowly but surely begin adding requirements in the wireframe and cross them off the list. As a team, we focused on what the primary persona would use most and where they would ideally end and begin. This process took us several tries and reiterations to organize and complete. We first built until we thought we had completed the Key Path Scenario and satisfied Leila’s needs. We created these key path and validation scenario wireframes for both this kiosk and the website to jumpstart our progress although, the kiosk remained our top priority.
With the layout created, we went to Figma from FigJam to create screens of the ideas we had structured. This included little to no color and basic functions to act as place holders for testing until the real design came in. We still prioritized the kiosk first, putting all of our efforts into those frames.
High Fidelity
We collectively created a style guide, although it was edited and changed, to enhance our design process. For the kiosk, I was in charge of creating the loading screen, cover page, product pages, search function and page, and category results page.
This prototype had many overlapping variables, the product listings, images, and buttons I created were often used in several other parts of the app. This posed a bit of a challenge due to the fact that all four team members live and work on different schedules and have different allotted times to work. Often, we would be missing functions on one page waiting for another page to be completed to implement consistency. We chose to take time to combine and correct these blanks and issues before usability testing.
Usability Testing
Usability testing was pretty consistent throughout our design process, so we constantly received feedback on general ideas like color scheme, basic layout, fonts, etc. But, when it came down to the details we set aside two weeks to go through a set of five thorough interviews testing each page, flow ability, likability, and user success. In this testing process, we reused some of our interviewees from the research phase while also adding other interviewees who had more of a design background.
This testing phase was pivotal in our process and vital for our prototype success as the users had loads and loads of feedback. Our users found trouble navigating to and from certain pages that we, as designers, found obvious, they also had preferences that varied from my team and I’s about layout, sizing, colors, and intended functionality. These notes then progressed us into the refinement phase.
Refinement Phase
During this phase, we spent our time reworking and re-prototyping many parts of the prototypes. We had to rework our color scheme to be more feminine-focused but not too much to limit our users. We also took time to re-work our language and a consistent tone for KODA from page to page. The team worked on various parts at a time with some overlap but some pages were created by a single person so going through and editing for consistency was dire. We had different button sizes, spacing, fonts, color ways, etc. from editing and re-iterating so this detail-oriented phase ended up being incredibly time-consuming due to our limited style guide from the beginning.
The feedback we received from testing was synthesized and we broke up the edits between the four of us on the team. We intentionally divided the work differently so different eyes would specifically work on each screen. We also made a point to each go through the screen by screen and leave notes and comments for specific changes that needed to be made whether for consistency, visual design improvement, or overall maturity of the screens.
Individual Responsibilities & Contributions
Key Screens I Created
Kiosk Prototype
Animated Gradient Cover Page
Entry Page
Loading Screen
Home Screen
Search Page
Search Results Page
Product Page
Category Organization Page
Category Results Page
iPhone View Prototype
Website Home Page
Sexual Diseases Page
Chlamydia Information Page
Web View Prototype
Website Home Page
Sexual Diseases Page
Chlamydia Information Page
Key Components I Created
All Product Images
Animated Background
Logo
Graphic Images
Card Components (8 variants)
ATM Mock-Up Images
Buttons
Generic Icon System
Content for Articles, Products, etc.
Sexual Disease Article Content and Click Actions
Filter/Sort Drop Down
Retrospective
In hindsight, many aspects of this project, from start to finish, felt rushed. I think the hardest challenge of this project was deciding what to create, narrowing down its necessary requirements, and really committing to jumping in on something as a team. With this project as our final capstone for college, the class was very hands-off and gave us a ton of freedom. With that freedom came the responsibility of the team members and team leader to drive productivity. I think in every group project some different skills and abilities should be recognized and put to use but, when put in a group for 14 weeks with 3 other people you’ve never spoken to understanding each other’s strengths and weaknesses is hard. I think if we had done a stronger setup from the get-go by understanding each other better, planning out schedules, and getting a stronger idea of how we wanted KODA to turn out the outcome would’ve been more successful. Nevertheless, I am proud of the work we did and I do love our concept and most of our designs. I think there are many accomplishments throughout the prototype for each of us.
If I had more time…
Spend more time researching and developing the ATM mock-ups, a 3D Animation would’ve been a cool addition
Rework the donation flow with more visual design appeal and stronger graphics
Challenge the payment flow for a more modern and mature look and feel
Edit some of our font hierarchy to feel more cohesive and consistent
Add in additional product pages to bulk up the flow and user freedom
Stronger facilitation in group meetings and overall productivity
Test the logic of donation flow in a kiosk setting
Bulk up both iPhone and Mac views of the website with additional pages to flow
Create a cleaner and more specified style guide
Spend more time researching business feasibility of KODA