InStore
UX Design Project
Overview
Category: Web application
Type: SaaS / E-commerce
Project Length: 2 months
Team Members
Team Lead: Erica Hester
Interaction Designer: Roxanne Cole
Interaction/Visual Designer: Grant Kennedy
Interaction Designer/User Researcher: Stephanie Epeagba
Interaction Designer: Cole Christiansen
The Idea
When our Senior Capstone & Portfolio Showcase course had started, our Team Lead, Erica, brought our team together with a vision for a SaaS tool for use within companies outside of our classroom. Unfortunately, due to massive delays of IRB approval within our university, we found ourselves unable to interview anyone within our target audience and could no longer continue with our project. It was then that Erica sprouted another fantastic idea: a SaaS/E-commerce web application that helps students learn how to freelance and gain experience by connecting with their own university communities.
Design Process (Goal-Directed Design)
Our team followed Goal-Directed Design (GDD), a process created by Alan Cooper that focuses on user goals to design a product. We can divide this process into three stages:
Stage 1
Kickoff Meeting
Contextual Research
Persona Hypothesis
User Interviews
Stage 2
Build Personas
Context Scenario
Design Requirements
Wireframing
Stage 3
Low-fidelity Prototype
High-fidelity Prototype
Usability Testing
Refinement
Due to COVID-19 social distancing guidelines, most of our project was completed remotely using Discord for communication, Microsoft Teams for interviews, Miro for documentation and organization, and Figma for prototyping.
Stage 1: Research
The first stage primarily focuses on research. Our goal was to establish the purpose of InStore and conduct contextual research related to freelancing, small business ownership, and the obstacles of these experiences in preparation for user interviews.
Kickoff Meeting
Since this was a project made in class, we had no stakeholders for a kickoff meeting. Instead, our team worked together to fill out a form that answered several questions about what our web application was and what it was meant to do. At first, our ideas leaned too far towards e-commerce logistics and details. Once we identified this, we directed our focus towards the learning aspect and student communities because we believed that these two ideas separated our idea from existing applications.
Contextual Research
Our team needed to understand more about freelancing and small business, especially for students. In Goal-Directed Design, contextual research is made up by the literature review and competitive audit. We gathered research online and discussed evidence of our findings together in order to understand what all of this information meant for us and InStore.
For the literature review, we researched guides and barriers to freelancing. We learned why freelancing was difficult to start and what tips already existed.
In the competitive audit, we looked into existing competition, including sites to find freelancers, courses to learn freelancing, and sites where you can own a small business by opening an online store. Researching existing competition also helped us understand how these websites are typically structured in order to follow the user’s schema, or existing knowledge of applications’ layout and functions.
Persona Hypothesis
Now that we learned more about freelancing and small businesses, our team needed to decide what kind of people our users might be in order to find the most ideal people to interview. The persona hypothesis is made up of assumptions about InStore’s potential users. To complete this, we answered a set of questions about our projected user audience. To summarize, they would be students or recent graduates with skills that they would want to monetize, and with varying levels of freelancing experience.
User Interviews
Researching users is a vital part of Goal-Directed Design. We used our findings from contextual research and the persona hypothesis to write out a list of interview questions. Our interviews were conducted on Microsoft Teams by having one team member facilitate and ask questions, and the other 4 members moderated by listening and taking notes. Our first interview ended up including too many hypotheticals, so we updated our list of questions to receive more direct responses. In total, we conducted 4 user interviews.
Affinity Maps
We needed to be sure that every team member shared an understanding of the interviewee’s responses and why they were valuable to us. To do this, we used affinity mapping after each interview to gather our notes, draw connections between them, and discuss what they meant to us. This was done together by writing and grouping sticky notes on Miro.
Once each interview had an affinity map, we took every sticky note from every affinity map and organized them as a team into one large affinity map. Doing this helped us understand what all of our interview participants had in common and where they differed. Through these affinity mapping exercises, we discovered that most of our participants had a great interest in freelancing within their university community, because this reduced the amount of competition between sellers and made them feel more comfortable as they were learning. These responses confirmed that our idea was on the right track.
Stage 2: Personas & Requirements
After completing the research phase, our team moved on to the next phase. We used everything we learned in order to start building personas. Personas are user archetypes that are created with data from real people we interviewed. These personas were used to represent our users’ goals which helped us decide the requirements of our design’s wireframe.
Building Personas
With our research complete, we could move on to modeling. We used all of our research findings to create user personas: representations of a real person who would use InStore. We will refer to their goals when building a list of requirements for InStore.
We decided that InStore would have two primary personas: A seller and a shopper.
We mainly focused on the primary persona while designing InStore, so we made sure that both of their main goals were fulfilled by using our app. Our team constructed a persona narrative for each persona. This narrative described their daily lives and helped us understand the kinds of challenges they faced with freelancing and searching for skillsets to hire.
Context Scenario
Building our personas lead to constructing the context scenario. This was a narrative that described how InStore fits into the life of the primary personas and how it satisfied their goals. In the first context scenario, our seller, Eilene, is trying to kick off her small business selling cupcakes. Since it is still new to her, she has difficulty knowing how to execute some details, such as pricing and sending invoices. InStore explains terms and gives her tips to help her out. Eilene successfully sends the customer their invoice, and this experience helps her feel more comfortable and confident with running her cupcake business.
Design Requirements
Discussing the context scenario exercise helped our team understand what our personas needed, and we created a list of design requirements. This helped us identify what the app needed to have or do in order to achieve the primary personas’ goals. Writing the scenario helped us discover the most important features that our seller and shopper personas needed. Some of these requirements included the ability to create and customize an online store, a marketplace to search for stores, a smooth method of communication between seller and shopper, etc.
Wireframe Sketches
Using our personas and design requirements, our team began to sketch the wireframe of our prototype by establishing key path and validation scenarios, or different paths that the user will follow when using the app. The key path assumes the most frequent path the primary personas will take through the app. Validation scenarios assume the paths taken in order to fulfill all other design requirements. These paths were divided up between the team, and each team member drew out sketches for what the screens would look like and how they connect to each other. I drew the sketches for the onboarding section of the application, which would help the user build their profile depending on their usage as a seller or shopper.
Stage 3: Prototype
With our personas and design requirements set, our team moved on to prototyping. We created a low-fidelity prototype to build the foundation, and continued to create the high-fidelity prototype with this. We then conducted usability testing in order to learn what refinements were needed.
Low-fidelity Prototype
We constructed the low-fidelity prototype by building and refining our wireframe sketches in Figma. This was a non-linear process that enhanced the foundations of our prototype. Our team divided the work between us, once again assigning sections that we had already worked on while sketching. Once we discussed our decisions and felt that the current state of our prototype would satisfy the user’s goals and requirements, we moved on to the high-fidelity prototype.
High-fidelity Prototype
The high-fidelity prototype is a detailed version of the prototype that portrayed what the completed application would look like in order to prepare for usability testing. We continued to use Figma to design and animate each page of our application. In this stage, we also established the visual identity of InStore and implemented interactions and animations that replicated what the real experience of using InStore should feel like.
Usability Testing & Refinement
Once our high-fidelity prototype was ready, we were able to start usability testing. We do this in order to assess how users interact with our application and learn about any of their difficulty or ease of understanding how InStore works. Mostly, user feedback was positive overall. Users thought our layout was easy to follow despite the amount of content present, and they had minor troubles navigating through our app. Some of the common issues included confusion between the store reviews and messages icon, or the location of the email blast under the Marketing tab.
After hearing and discussing user feedback, our team worked together to work through some of the troubles our users had in testing sessions and refine our design. We removed the messaging icon so that it could not be confused with the reviews, and implemented other refinements including updating text, enhancing interactions, and adding graphics to onboarding.
Final Prototype
Takeaway
InStore was created as my team prepared for our Senior Portfolio Showcase, which was a virtual event for the very first time this year. Despite the troubles with IRB and sudden change of plans that we had in the beginning, I’m confident that InStore turned out to be a easy to use tool that could help a lot of real students gain experience in freelancing while they complete college. Many student interview participants told us how much they wished this kind of application could help them, and our team received great feedback during our virtual showcase. I’m proud of what my team created in such a short time, and I look forward to how this experience will help me in my future UX projects as well.