INTRODUCTION
CLIENT:
Ryecatcher
BRIEF:
Help translate functionality from an
existing web application and optimize features for use in a mobile context.
TEAMMATES:
Vic Costikyan, Scott Dombkowski,
Monica Looze
TIMEFRAME:
5 weeks
COURSE:
Interaction Design Studio (MA), Carnegie Mellon University. Taught by Ashley Deal and Raelynn O'Leary
TOOLS:
illustrator / figma
LINK TO PROCESS DOCUMENTATION
For this studio project, we were asked to take existing content from Ryecatcher's website and translate the most pertinent features of it to their mobile app.
Ryecatcher for Mobile is a tablet app for users of the school resource software, Ryecatcher. Ryecatcher connects and coordinates services for special needs and high risk students. The app acts as a task manager for busy teachers, social workers, and school administrators. This app makes the process easy, quick, and simple for users. In creating this app, we have streamlined data entry, allowing users to quickly do what they need to in a simple, straightforward process.
Our final deliverables to our client include annotated wireframes, high fidelity screen mockups, and high resolution images which capture the key ideas of our solution. Over the course of this project, we also developed a project plan, a halfway point client presentation, a presentation regarding user testing results, and a process document.
EARLY INSIGHTS
PERSONAL RESEARCH
To acquaint ourselves with the Ryecatcher website, we explored Ryecatcher’s interface and walked ourselves through entering student information and notes. We analyzed our experiences with the interface and created lists of positive and negative factors. We met as a group to compare one another’s insights.
From this exercise, we developed a few key insights that directed the development of our solution. We all liked that the Ryecatcher website had a clean and open interface; the information on each page didn’t feel crowded. However, we also felt that feature creep was an issue on the site. We also noticed that adding a note to the website wasn’t a very straightforward process.
USER RESEARCH
In order to transfer Ryecatcher into a mobile platform, we wanted to first understand what was working well on the website. We reached out to two potential users, an administrator at a therapeutic school and a former school social worker. In this testing, we gave these users scenarios on the website and asked them to add new students, make notes, and add trackers. There were some helpful insights from this research. For instance, we discovered that the website’s attendance-taking feature was misleading and the tracker functionality was unclear. These insights later guided how we addressed trackers and attendance taking in the app.
CONCEPT DEVELOPMENT
From these insights, we formed our design direction. In order to bring clarity and fight feature creep, we wanted to develop a solution that was simple, quick, easy, polite, and helpful. We used these words as guides for our initial sketches and ideation.
After we had our initial concept, we started working on the overall architecture of the app. Discussions arose about how we would organize the app and what terminology we would use. We worked out a convention that included a landing page as a quick at-a-glance resource for teachers separated into action items, meetings, and “latest” updates for a way for teachers to easily and effectively get an idea of what they need to do for the day.
For the features of the app, we decided to focus on the latest page, students, trackers, and student groups. We determined that these pages were most important for teachers to access.
As our goal was to make the process simple, quick, and less overwhelming for the user, we spent a significant amount of time on streamlining the data entry process. Taking Turbo Tax as inspiration, we developed a predictive wizard that walks the user through the process, eliminating steps that are irrelevant to the type of "Note" being entered.
One key pain point in our project was what we should do with Quick Notes. We all agreed that we disliked the verbal communication of the term “Quick Notes”. The quick note functionality on the website suggests to users that the other notes aren’t quick, and as a result many users enter data as a quick note. This is bad for Ryecatcher because they lose important data which would have been entered by the user if they hadn’t chose “quick note.” However, Ryecatcher likes that the Quick Notes function is easy and quick for their users. As a result, we decided to build in a “save as draft” system within our Wizard, so that the functionality of a quick note is retained without the terminology “Quick Note”.
We also built orientation conventions into the wizard so that the user always knows where they are in the process. Dots at the bottom of the screen indicating the number of steps the user has been through, and a point where the user can save the note as a draft were added to make the quick-note functionality ever-present while still collecting data for RyeCatcher.
USER TESTING
We conducted user testing with former Ryecatcher user and current Ryecatcher employee, Senchel. We worked as a team to create a list of testing prompts and questions for her. For example, one of our prompts was: “You gave your meeting a title, but you don’t have time to add in any other information because a class is starting. What do you do?”.
Senchel answered all of our prompts correctly, so we concluded that our architecture was fairly straightforward and easy to navigate at first glance. After we took Senchel through our wireframes, we asked her for feedback. She liked the way that we had bucketed the latest page, but she expressed that there should be more information about each action displayed. At this time, we only had the title and time of each meeting; Senchel expressed that there should be more information available. Senchel also mentioned that the students should be alphabetized, and she was skeptical of the wizard we had developed because of all the screens she would have to deal with. While we took this into consideration, we also only showed her a flow diagram, not wireframes. We feel that this was a weak-point in our research, and if we did it again, we would build out all the screens so she could physically see the flow rather than a diagrammatic representation.
WIREFRAMES
Mobile app site map
PROTOTYPE
HIGH FIDELITY MOCKUPS
