top of page

Learning about our users

Research Findings

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.

Categorized the data generated from individual interviews
The major findings of both TAs and students

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.

Personas

Who we are designing for

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.

Scenarios

Expectations and context

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.

A day in the life of Tom McGill...

Already, he knows that this feedback tool will be the key to allowing him to improve as an educator…

A day in the life of Sarah Saveron...

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.

Personas
Scenarios

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.

Design Sketches & Ideas

Potential Functionality

TA View - Results Page

Student View - Filling out Survey

TA View - Dashboard

Ideation Sketching

Design Sketches

Some of our initial sketches

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

  • Quick, hand-drawn, but detailed enough to convey information

  • The key-path of using our application is shown through several screens

  • Context of where the mobile site is being used is also given

  • Storyboard rely primarily on the expression of the students and the TAs and not the captions

Storyboards

Conveying the experience

Storyboards

Organizing the flow

Sitemap

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:

  • Our site map was split into two different sections: one for the TAs and one for the Students

  • In all screens of our site map, we allows the user to navigate to the homepage

  • The site map offers archives of old files as well as currently live TA evaluations and student feedbacks

  • At the top of our site map, we have also included a scenario path of how the website is to be used throughout the course of a week

Sitemap

Sketching our screens

Paper Prototype

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.

Task 1: Submitting Feedback

 

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.

 

  • The task is to submit two independent pieces of feedback and add these feedbacks into the appropriate categories (content, teaching, logistics, misc).

Task 2: Upvoting, downvoting and adding comments

 

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.

 

  • The task is to upvote at least one comment you agree with and downvote one comment you disagree with.

  • Add additional comments to feedbacks that you feel strongly about 

​

Scenario for TAs

​

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.

 

Task 3: Taking student feedback and transforming it into a personal goal

 

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.

 

  • The task is to choose the most popular feedback and add it to your personal list of teaching goals.

  • Edit your current list of goals

Paper Prototype

Paper prototype usability testing

Quick Evaluation

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.

User Demographics

 

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.


Usability testing

Excerpt of Our findings…

Quick Evaluation

Digitizing our entire system

Annotated Wireframes

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.

Annotated Wireframes

Our latest screens

Hi-Fidelity Mockups

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.

Hi-Fi Mockups

Always improving...

Future Developments

Thank you for browsing through our 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.

Potential mobile development
Future Developments

Thank you for scrolling!

bottom of page