Timeline: Jan - Mar 2017
Project Type: Class Project
My Role: UX Designer, UI Designer
Tools: Lucid Chart, Sketch, Figma
Skills: User Reserach, Personas, Ideation/Sketching, Storyboarding, Information Architecture/Site Mapping, Paper Prototyping, Wireframing, Hi-Fi Mockups
Over the course of 10 weeks, a talented group of 3 and I went through an extensive UX process to generate, reserach, wireframe, usability test, and present an application called E.val. A tool for teaching and learning experiences for both teaching assistants and students.
We aim to address the disconnection between TAs and students along with other 3 problems: a lack of space to provide anonymous feedback at all times, a lack of tools for TAs to improve their teaching abilities by tracking progresses and most importantly a lack of insight to student needs.
Our tool will allow students and TAs to work together to improve the classroom learning experience by providing TAs with student-driven, anonymous feedback that will give insight to actual student needs. This will help shed light on opportunities for growth and help TAs improve their performance in the classroom to better serve their students.
The solution that we have designed is a hybrid between a discussion forum and your standard UW course evaluations. This solution is very simple, lightweight and designed with students’ and TAs’ busy lives in mind. For the student, our applications designs for both various levels of engagements ranging from writing a new review themselves to simply upvoting or downvoting others’ feedbacks. For TAs, feedbacks are sorted based on teaching categories or by sections, helping them contextualize the student concern. TAs are able to use student feedback as inspiration for weekly goals. At the end of the week, an evaluation survey is sent out to the students to see how the TAs measure up.
Our research consisted of two different components: semi-structured interviews and a competitive analysis. We initially selected TAs as our primary users. Each group member interviewed one TA from UW, asking about various aspects of their lives, goals, motivations, pain points, and more. Additionally, each group member picked a different tool to research and analyze, seeing how it successfully meets user needs and how it fails. We did this to learn about other services TAs currently use and how effectively they serve their users. We also realized we would need to include students as primary users, thus we conducted a few more interviews to understand student perspectives. Conducting this user research helped provide us with key insights to begin figuring out how to design for our users. The followings are the individual reports of interview and competitive analysis from our team members:
Across all of our interviews, we were able to define the common traits, goals, pain points, etc. We put all the identified facts on the sticky notes and then categorized them in several clusters. This step is important as it helped us further build and refine the personas which are essentially based off the identified facts.
By conducting some interviews, we accumulated a lot of valuable insight from both TAs and students. In class, we worked together to create provisional personas. We brainstormed based off of our research, categorized our ideas, and created a poster of our provisional persona. Outside of class, we met to create another provisional persona and worked on refining the two, editing out unnecessary content and adding more details to make them feel more like real people.
Initially, we were going to focus on TAs as our primary users. However, during the user research phase, we discovered we have two primary users: TAs and Students. By interviewing both types of users we learned valuable information like the pain points. Our polished personas would then guide us through the rest of the design process, helping us make sure we are designing with our users in mind.
After creating our personas, we individually worked on writing scenarios for our personas. These furthered our understanding of our personas and made us think about how we could design to meet our users’ needs. We first began by identifying persona expectations based on the data we collected during user research and noting where we made assumptions. Then from these expectations, we constructed our scenarios, keeping them high-level and not delving too deep into solutions quite yet. Creating scenarios helped us think more about how to approach our design problem and provided great content for our storyboards.
Tom teaches a 8:30 am section and expects that his students will most likely arrive late or just not show up at all. When section does start, he helps explain “for loops” and variables in the way he was taught. The class is not very responsive to the discussion prompts and asks few questions. He assumes this is because it’s an early section and everyone is just tired. Tom logs onto our app and sees the several feedback comments left for him….
He brainstorms ways to better explain concepts using examples, illustrations, and analogies. Instead of having to wait until the end of the quarter to receive this sort of feedback, he is able to make changes within the first week of school.
Already, he knows that this feedback tool will be the key to allowing him to improve as an educator…
Sarah shows up early to section hoping to ask her TA, Tom, some questions before class begins. Tom reviews the week’s lecture slides and contributes very little additional explanations. To Sarah, everyone else in the class seems to understand the material as no one is asking questions.
She logs onto our app as a way to address her issues. She is able to provide feedback to Tom through number ratings as well as free-responses to suggest improvements. She hopes her responses will help Tom become more aware of the needs of his students, allowing him to improve as an educator. Sarah continues to use this app throughout the quarter, giving her a way to raise concerns in an effective, professional and anonymous way.
She hopes that this not only improves her own learning experience but that Tom can benefit from her feedback as well.
With our personas and scenarios in mind, we engaged in more brainstorming, both individually, and as a group. We worked to come up with some of the design requirements for our application, thinking about some of the potential functional requirements and data requirements involved. We also sketched out some potential screen designs individually, and refined three of the more promising ideas. Taking a step back, we then analyzed these three sketches, highlighting some of their strengths and weaknesses. This work would then help guide us in creating our storyboards and laying out our whole system.
At this stage, we all worked individually to come up with two different scenarios, one hand-drawn, and another with images. One scenario focused more on the context of use and the other focused on a specific interaction within our application. These were created to help us think about and convey the experience of interacting with our application. Our individual scenarios created earlier on served as a great starting point along with the key path scenarios we developed in class. We each brainstormed different stories, focused in on specific narratives, sketched some drafts, and refined them, utilizing different image perspectives and extra lines to convey motion. Sketching out the flows of some specific uses helped prepare us to think about the flow of our entire system.
Requirements of Storyboards:
Storyboarding had us thinking about some of the user flows on a general level. At this stage, we needed to think about the entire system and lay it out in our information architecture diagram/sitemap. In creating the sitemap, we planned out how to break down high level and low level pages in our application. We utilized our design requirements list to figure out the content and flow of information for both the TA and student side of our app, but also the other logistical aspects as well. Once we had the flow of the entire system worked out, we could begin thinking about and sketching out how each screen would look
Site Map Requirements:
Based off our sitemap, some of our storyboard scenarios, and our initial design sketches, we began discussing and brainstorming more ideas of how we wanted our screens to look. For efficiency and consistency, we began with creating a template for all of our screens. Then, we worked on sketching the content for each screen. We focused on drawing screens for three key path scenarios. These paper prototypes were a low-cost, efficient way to get our ideas across visually and would serve as our artifacts to conduct usability testing with.
You have been having difficulty understanding “for loops” and had hoped that your TA would better explain this concept during quiz section. You wish to leave the TA feedback detailing how you would like further explanations on this concept as well as more time in class to for homework clarifications.
Once again, you have been having difficulties in class over technical concepts. You are starting to worry over whether or not this is your own lack of understanding or if your peers have also been feeling this way. You browse through the feedback and upvote those you agree with and downvote those which you do not.
Imagine you are a TA for CSE 142 at the University of Washington. You are a relatively new TA and would like to improve on your personal teaching abilities. You use E.Val in hopes that it will help you gain insight on your students’ needs as well as your personal areas for growth.
The task is to browse through all the recently submitted student feedbacks and use these feedbacks as inspiration for your personal list of goals. You are also asked to update your current list of goals by editing and deleting unnecessary goals.
With our paper prototypes complete, we needed to conduct some usability testing with our prototypes to find areas of weakness in our designs. We reached out to potential users, three students and one TA, to observe how they would interact with our system, if they could successfully complete each task, if they had any suggestions for improvement, or any strong likes or dislikes with our current system.
Gaining these perspectives from others outside of our group were extremely valuable because they helped highlight unintuitive actions or flows that we may not have otherwise realized ourselves. We then compiled our results into a report with our methods for evaluation, some of our key findings, and next steps for improvement. These new insights helped us realize some changes to be made which were then implemented in our lo-fidelity wireframes.
Our user demographics consisted of two undergraduate students and the other is a graduate student. They all come from a tech/engineering related major with two from EE and one from CSE. One of which is a graduate CSE TA.
Our usability testing pointed out some key design issues we needed to address in our next iterations. With these research findings in mind, paper prototypes as our starting design point, and our information architecture diagram as a guide, we began digitizing the entire system using a collaborative design tool called Figma. These wireframes were intended to be lo-fidelity, with minimal use of color and space holders in place of user-generated content. After creating the whole application, we explicitly annotated each screen, highlighting key components, and describing some of the functionality and rationale behind these choices. This step in the design process helped us think about the intention behind each element and acted as a useful tool to receive feedback on prior to designing our hi-fidelity prototype.
For this project, the last step in the design process was creating our hi-fidelity mockups. After an in-class peer review session, we selected a few screens from our low-fidelity wireframes to further design. With the feedback and critiques in mind, we worked to remove placeholders as well as solidify our color scheme and layout. Creating these hi-fidelity mockups helped us to convey our ideas in a more complete, professional manner and brought together all the elements we have worked so hard on for the past ten weeks.
Thank you for browsing through this portfolio! We are excited to launch E.val for the very first time. We see E.val as a tool not only in UW learning classrooms but we see E.val’s potential to be repurposed to fit many other environments. The colors, the logos and the content of E.val can easily be changed. Beyond this, we hope that E.val will build partnerships with other learning tools such as Canvas or PollEverywhere so that students do not have to navigate multiple different sites in order to access all their learning tools.
As for our design team, we are constantly curious to learn more! We would love to hear your feedback and comments on how we can make E.val better for everyone.