Research Findings
Our research for this project consisted of two major parts. First we conducted a set of semi-structured interviews with current and former Resident Advisors (RAs) at the University of Washington. Concurrently, we conducted multiple competitive analyses of products that could be useful for RAs, such as Asana, Reminders for iOS, and Outlook. We analyzed both of these in order to learn not just what problems RAs have to deal with, but also how other designers have decided to address similar problems. To get a broad perspective with less chance of bias from any particular person, each team member conducted one interview and one competitive analysis. You can view our findings from the interviews attached below:
After conducting our interviews and analyses, we organized our thoughts and findings with sticky notes gathered into groups. In order to get a few extra perspectives, we reorganized these groups a few times as well. This clustering really helped us narrow down our key issues for persona creation.
Personas
After interviewing our participants, we gained a better understanding of our users and their contexts. This included their behavior patterns, motivations, desires, and pains. After summarizing what we each learned, we categorized the common traits our users had and started creating our personas.
In the beginning, we created two provisional personas by brainstorming who they were, what problems they were having, what they wanted, and some scenarios based on the information from our interviews.
Then, we refined the two provisional personas in order to make them more aesthetically pleasing and to create a more empathetic point of view.
These personas were used throughout the quarter to help us identify issues that Resident Advisers deal with while carrying out their job tasks. When we made design decisions, we referred to these our personas to be sure we were mindful of our users' interests and needs.
​
With the personas, we were able to create a user journey map that visualized the experiences of our users and allowed us to develop deeper insights about them.
User Journey Map
After the creation of our personas, we synthesized information from our interviews as well as the traits of one of our personas, Darren, to create a user journey map. We decided to represent the map as an actual mockup floor plan of a residence hall with the points Darren would go to during his shift. We placed these points on the floor plan to represent the physicality of being an RA. RAs have to go to many parts of the floor during their duty, and this gave us a better idea of how hectic and demanding their job is. We also featured a representation of a timeline in order to help us understand when certain events happen in Darren’s day, and how the timing of events might particularly affect his mood. Our timeline also shows how his mood would generally fluctuate throughout the day. Seeing these key points allowed us to better identify touch points, which later developed design opportunities.
Creating the map was very important in helping us to define our key design requirements, as well as choosing which ones could be a lower priority.
Design Requirements
Looking at our user journey map, we noticed a couple design opportunities. This included how we might help relieve them from the overwhelming paperwork and design a more efficient way of writing documents. To address these problems, we decided to design a tool. In our previous research, we found that RAs carried their phones all the time and most of them were comfortable with technology. This led us to the decision that a mobile app could be the best solution.
In terms of the capabilities of our app, we listed ten design requirements using two techniques: “Action-Object Context” and “Data-Function Context”. During this process, we developed a deeper insight about the context of our product, the functions of our product, and the way it will process the data. It also helped us discover the parts that were most salient so that we could prioritize our later work. The most important requirements are: allowing RAs to quickly submit various kinds of reports, allowing RAs to efficiently communicate with each other, allowing RAs to view and manage their schedules, and allowing RAs to quickly check protocol and policies.
The design requirements helped us identify what our product needed to accomplish. Therefore, we could start creating storyboards that helped us visualize context and how users would be interacting with our product.
Storyboards
With our tentative solution of creating centralized mobile application and our design requirements, we proceeded to put our ideas to the test. Each team member created storyboards that helped us visualize how our solution was going to help our users and relieve the stress that their job tasks brought on. Each of us came up with two different scenarios. From there, we created two storyboards: one drawn and one of photos.
We then evaluated the user experience within each scenario. After discussion, we found that we could incorporate all the ideas in the our scenarios and turned them into features of a centralized platform. Those storyboards helped us learn more about the context of our product, picture how our users could be interacting with it, and evaluate the feasibility of our design.
With the storyboards, we had conversations and gained more insight of our design idea. This knowledge led us to the next step of our design, which was to build a sitemap for our product.
Information Architecture
After creating our storyboards and nailing down the details of a few specific interactions, we needed to also have a higher level view of how all the information in our service would be laid out. This sitemap would give us a more grounded base to work from in the next phase of our work, the paper prototype.
We decided to focus the information layout around a central dashboard that provides quick access to all the other portions of the application. We found that the RAs we interviewed were very busy people already, and we didn’t want any particular activity to be buried too deep in menus. We decided that the four key areas of the service were form filing, messaging, viewing students and staff, and referencing the handbook. As such, these all recieved top level actions at the dashboard, allowing for quick access. We repeated this process for each sub-menu, until we had a great base structure to work with for our paper prototype.
Paper Prototype
We followed up on our storyboards with paper prototypes in order to test our designs with potential users without investing too much time into ideas that might not make the final cut. We combined elements from our storyboards and a few new sketches, then printed out copies in a mobile form-factor to help users see it in the format the final version was planned to be. While we used the storyboards to help us design specific interactions, we also used data from our sitemaps to help us design the higher levels of the layout.
Task 1: Interact with Dashboard's 'QuickAdd' button
 |  |
|---|
Task 2: Write and Submit an Incident Report
 |  |
|---|---|
 |
Task 3: View Calendar and Swap with Another RA
 |  |
|---|---|
 |
Quick Evaluation
After the creation of our paper prototypes, we conducted studies of the prototypes with prospective users. We planned out three major tasks: using QuickAdd to submit a report, submitting a report via the full menu system, and requesting a duty swap. We selected these three tasks because we felt that they would provide the most insight into the unique features of our application. This was opposed to testing something like the messaging system, which has already been done many times before, and therefore wasn’t a testing priority. We also asked users a set of pre-test and post-test questions in order to get a answers to questions that might not come up during the basic functionality testing.
During the testing of the prototypes, we gave users minimal assistance. We told them what their task was, and little else. We did this to make sure that we were actually testing our prototype, and not just making sure that our tests were “successful”.
Users in this study had two major problems with this version of auroRA. First, they had difficulty finding the 'plus' button that was used to add a new report, however once they learned where it was, they had no further issues. We decided we would remedy this issue by adding color, giving the interface more contrast, and making it easier for first time users to find the button. The second issue, users having major difficulties with the calendar and duty swap features, had to be remedied in a more major way. Users universally had difficulty with these features, and none of them were particularly interested in having the feature, either. Not only was the calendar feature confusing because of the myriad of functions we tried to add to it, but users pointed out that as an RA, they would rather use their own calendar to organize their schedule rather than deal with multiple calendars. Based on these findings, we decided to completely axe the calendar functionality, allowing us to put more of our resources into features users found valuable.
Annotated Wireframes
Once we completed the testing of our paper prototypes and the analysis of the results, we were able to create a wireframe version of our application. A wireframe allowed us to create a digital version of the current (at the time) form of auroRA, but with colors and detailed contents removed. This allowed us to put more of a focus on the structure of the application rather than the content that would be included within it. We created our wireframes in Adobe XD in order to ensure compatibility with both Windows and macOS (as opposed to Sketch, which ony supports macOS). We included annotations in the wireframes in order to better clarify our ideas so that they can be better shared with users as well as other designers. They help to add a further focus to the wireframes. In addition to the wireframes, we also added a few key path scenarios to this document, which helps to show specific, common interactions that users might experience.
 Search the Handbook |  QuickAdd an Insight |
|---|---|
 Add Incident Report (non-QuickAdd) |
While these wireframes were based upon the paper prototype, the design has been refined based on feedback received during testing of the paper prototypes.
High-Fidelity Mock-Ups
For the final step in the design process, we refined our annotated wireframes into a high-fidelity mockup, made in Adobe XD, as well as an interactive prototype made in InVision. We made slight changes, such as the addition of more color, based on peer feedback received in class. In addition, we refined our placeholder data into items that might be actual content one would see while using the app. The creation of these mockups, and especially the working prototype allowed us to professionally present our work to designers from Amazon and Artefact in the best light possible.
 |  |
|---|---|
 |  |
 |  |
Reflection
We learned a lot about user-centered design throughout this quarter. We went through the whole design process starting from user research to high-fidelity mockups.
​
We wished we had more time so that we could flesh out every part of this project, however we were constrained to the 10 week quarter. If we did have more time, here are some things we'd do differently:
-
We would do much more user research. With the limited amount of time that this project offered, we were only able to interview 4 RAs, all of whom were from the University of Washington. This may have been biased, as we only really know for sure what happens with RAs at the UW. With more time, we would’ve been able to greatly expand this pool, especially to other universities.
-
We would try to get more information about the current system RAs are using. We recieved a brief look at the current system that RAs at UW use. It’s a decrepit system that only runs in Internet Explorer, and is very poorly designed. However, we couldn’t dig deep into this system due to privacy concerns, and didn’t have time to work out an agreement with UW’s administration. If we had more time, we would have asked for screenshots of the current web-based system with private information redacted.
-
We would pay more attention to security and privacy issues. The content that will be used in auroRA is very private in nature, and as such needs to be kept extremely secure. While we did make some nods to information security, such as logins and biometrics similar to banking apps, we didn’t have time to put as much of a focus as we would’ve liked on security.
The biggest challenge was that we didn’t have enough information about RAs and the tool they’re currently using. Because of this, we had to make a lot of biased assumptions. In hindsight, these assumptions were often made without a second thought because we personally know many RAs and we all lived in a Residential Hall prior to beginning the project. If we had more time to interview more RAs (not only on UW campus, but other university campuses as well), we feel that we wouldn't have made as many assumptions as we did and that our research would be much more thorough.
The biggest surprise was the amount of effort RAs put into their jobs. After our user research, we were deeply impressed by the number of forms and documents they need to fill. For example, they are required to write a report about any conversation they have with their residents. This was particularly surprising to us because interactions seem so minute and unimportant, however they still need to be documented.
We were also surprised by how inefficiently they performed their tasks. Even when they simply interact with a resident, they are required to take notes on their phones and then later, use their laptop to fill out documents. As students who are often forced to multitask on a myriad of platforms, we sympathized with RAs. This provided us with motivation to build a solution to make their jobs easier.