STEM (Class Project)
My Roles
Project Manager
UX Designer
UX Researcher
Tools
Adobe Illustrator
Figma
Google Suite
Project Timeline
10 weeks (January - March 2019)
About
Student, Teacher, Employee, Manager (STEM) is a website that allows substitutes, faculty members, and administrators to efficiently manage employee absences. Our primary goal is to redesign a pre-existing set of systems to optimize substitute’s experience booking jobs and communicating with faculty/administration.
Problem Statement
Substitutes often feel frustrated with absence management because of their systematic disorganization, decentralized functionalities, and inefficiency. Currently, substitutes must use three different applications (AESOP, Skyward, and Jobulator) to find and accept a job opportunity. Multi-platform absence management is unsuitable for substitute teachers who require structure, planning, and consistent channels of communication.
Research & Findings
Through interviews, competitive analysis, and persona development, we gathered enough data to begin brainstorming how we could address the problem statement. The high-level data we collected from each method is compiled into “Takeaways” which inform our future design decisions.
User Interviews
We conducted four interviews with substitutes teachers and faculty members to determine what technological interactions (in current absence management systems) were working, or not working well. Empathizing with our user group helped us identify the needs that were not being met with existing resources. Our user research became the basis of all design decisions and later helped us create our personas and user journey map.
Takeaways
The substitution process is complex; it requires many checks and balances between multiple web applications, and involves district officials, faculty members, and administrators.
Absence managers are not universal, districts have the option to subscribe to different software systems.
There are three main applications used for absence management: Skyward, AESOP and Jobulator. Skyward is a place for teachers to put in absences, AESOP is a place for substitutes to book jobs and Jobulator is a monetized notification center for substitutes.
Substitute teachers find it hard to prepare for some subjects which do not have clear planned schedule.
Many substitutes have multiple jobs, or are students which influences how often they can check for new job opportunities.
Substitutes value interpersonal communication and expect consistency and organization from their co-workers.
Competitive Analysis
With our competitive analysis, each group member conducted research on different products/services that would potentially share the market with STEM. We focused on identifying how the product meets or fails to meet users’ goals and motivations. In completing this, we were able to use our findings to better understand our users’ pain points and goals.
Takeaways
Our competitors are seemingly more business oriented, than user-centered.
For accepting job opportunities, the first come first served procedure for substitutes makes notifications urgent.
The layout is clean and simple which makes it easier for substitutes to use.
Substitutes are not given the same privilege of setting preferences as teacher are.
Though the design of our competitor's applications is aesthetically pleasing, they are each missing key features that our interviewees desire.
Personas
Using our interview takeaways, we built two personas: a substitute (Ava) and a teacher (Malcom). More importantly, we were able to highlight our interviewee’s pain points and their goals/desires. Each persona includes characteristics, pain points, desires, goals and technology proficiency based on all of interviews to make them as realistic as possible.
Ava Jones
Ava is a graduate student and substitute who is pursuing a Masters in Education and hopes to be Child Development teacher. She is community driven; constantly seeking and engaging in meaningful conversations.
Malcom Hall
Malcom is a full-time high school honors English teacher. His busy schedule requires him to plan ahead and stay organized. The substitution system’s shortcomings conflict with his productive and orderly personality.
Takeaways
In building our personas, we were focused on how can we design an alternative solution to the current system’s problems that school districts face today.
We realized our personas do not reflect our entire user group of teachers and substitutes given the short time frame to conduct interviews.
In order to avoid assumptions and bias, we listed our different pain points and tied them back to which interviewee source it came from.
The scenarios we constructed for our personas are the basis of our user journey map.
User Journey Map
After deciding to choose substitutes as our primary user group, we began modeling our user journey map after Ava Jones' persona. Creating the map helped us empathize and get a better understanding of what kind of emotions are associated with the pain points we identified from interviews and our competitive analysis.
Takeaways
Modeling the thoughts and actions of a substitute showed us the range/combination of emotions that can occur at the same time from one touch point.
Understanding users' emotions is not as simple as a journey map makes it out to be. The journey map is a great starting point, however, we think it is still biased from our own assumptions of how someone would feel.
The journey map was contextual, so it also helped us understand the circumstances that precede and follow a touch/pain point.
Design Phase
During the design process, our goal was to clearly identify desirable features, understand their contextual use, and diagram the user flow. In the design phase, we created design requirements, storyboards, and an information architecture diagram.
Design Requirements
We deliberated in several ideation sessions and devised five design requirements for our product.
Centralizing functions (i.e. seeing job openings, submitting absences to the district, requesting coverage, and notifications) into one management system.
Allowing substitutes to set preferences for grade level, school location, teacher, and subject.
Instant messaging between teachers and substitutes for questions, emergencies, and general communication.
Allowing substitutes to sync their calendars (i.e Google Calendar) to check their availability and avoid overbooking.
Giving substitutes the option to sync the system’s job notifications as phone notifications for those on the go.
Storyboard
In creating storyboards, we were able to brainstorm our stories to put into our potential product. This helped us convey design ideas visually based on user experience and depict different aspects of our design. We chose to brainstorm representative scenarios that substitute teachers would face, such as booking a job and receiving job notifications.
Takeaways
In doing storyboards, we were given the opportunity to narrate and convey our design ideas from our design requirements, which paper prototypes and sketches can not do.
We were able to see different variations of storyboards with the same feature. This helped us see different design routes we could take as a group.
Illustrating our storyboards made us focus more on context and emotions involved with the action. We were able to convey the current issues our users may have and provide a solution.
Information Architecture
In creating our design requirements and visual storyboards, we organized our information architecture by mapping out the users’ flow through the software. This helped us outline how users would interact with our product.
Takeaways
Mapping allowed us to distinguish our features from other competitors as well as show the components of our system and the hierarchical relationship between those components.
We learned to focus on location a user might find themselves on rather than functionality. Additionally, we learned to have clean/logical connections, good alignment and differentiation between our content. Using our recent feedback, we were able to fix our alignment and add additional navigation tabs that were added later in the course from prototyping.
In our future assignments, we were able to use this map to guide us in our prototypes and wireframes.
Prototyping Phase
The prototyping phase allowed us to iterate quickly, test our ideas, and improve on our usability at a low cost. During the prototyping phase, we created paper prototypes, conducted usability tests, created wireframes, and high-fidelity mockups.
Paper Prototype
We used paper prototypes to quickly visualize our three key tasks. This was an efficient way to test if our designs meet the users’ expectations and needs.
We tested the following three key user tasks:
Task 1: Finding and Accepting a Job
User navigates within the dashboard tab to find and book a job. The user will need to refine the list of available jobs to reflect their preferences.
Task 2: Syncing the Calendar
In this task, the user navigates to the calendar tab. The user will need to sync their personal events in the calendar by using their Google Calendar.
Task 3: Send a Message to Chat with a Teacher
In this task the user has already found a job that interests them and would like to contact the teacher. The user will need to start a message with a teacher to find more information about the job.
Takeaways
In using our information architecture, we learned to incorporate our design sketches into one look. In doing so, we were able to fix our inconsistency with our design, especially with the dashboard.
With our prototypes, we understood the differences between our sketches and prototypes. Prototypes are distinct in that they are meant to be used to test an idea rather than share an idea.
We were able to use our in class and user testing feedback below in our future improvements for wireframing. This included fixing our filter icon, adding search results and changing pop-up dialogue.
Usability Testing
After creating our paper prototypes, we reached out to individuals who were teachers/substitutes/students in education to receive feedback on our provisional work. Through usability testing we were able to identify our product's shortcomings and iterate on our designs before the wireframes.
Takeaways
Usability testing helped us to find problems in our designs that we did not account for or expect to be an issue. Through testing we found that the style and placement of our icons were making the user interaction inefficient and slightly confusing. We changed our layout in future iterations.
Non-verbal feedback is important to look out for because body language is unfiltered and raw. It can really show exactly how the user is feeling when using your product.
Additionally, while conducting these tasks, we were able to clearly see how users would interact with the system by using the think-out-loud approach.
Annotated Wireframes
With our wireframes, we learned to keep it simple and focus on structure rather than functionality. Wireframing gave us an opportunity to be consistent with typography, spacing and edges.
Takeaways
In doing our wireframes, this gave us an overview of our system's functionality and purpose. This time allowed us to collectively envision our website and what it will look like.
Even with our feedback and fixing our inconsistencies from our paper prototypes, we learned there were still some inconsistent details in the design interfaces.
Our annotations gave us an opportunity to explain our design decision and rationale. This made us think about what questions our clients might ask about our design choices.
Using our information architecture made it easier to plan and map out our wireframes. We were able to add more details from our feedback such as adding a search result when a user refines a search.
High-Fidelity Mockups
We created a high fidelity prototype to convey how the final product would look and operate. We were able to use our wireframes and low-fidelity mock-ups to reach this stage. Using our in-class critique, we refined our design and final product to show our key tasks: booking a job, instant messaging and calendar sync feature.