As the semester is coming to a close, so is our time working on this project. In these hectic past few weeks we’ve been working hard to ensure that our project is completed to the best of our ability. Since performing our second round of testing with our 10 Woman in Computing students, we’ve been able to gather some meaningful data, and incorporate the invaluable feedback we’ve received into our final iteration of the M.I.R.A.N.D.A prototype. The new round of testing allowed us to be alerted of the shortcomings of our product, giving us the opportunity to bring some features back to the drawing board. The Marvel application was once again opened up and some parts of our product were re-designed to offer an increased sense of usability to our user base. With the submission date fast approaching, we hope the final product we will be delivering is up to the standards of our customer and professor alike. We will now be signing off for the time being. Who knows? Maybe someday down the road, the members of JavaScript For Her may one day cross paths again.......
Over the last week, we’ve been meeting up with 10 usability testers to try out our high fidelity prototype. Before we began each test, we had each of the testers sign an informed consent form to make sure they knew the purpose of the testing and allow us to use data gathered from the sessions. Then, we explained the purpose of our product to give them some context on what it was they were testing.
To gather data, we had each of them perform 4 tasks which included:
1. Accepting one of MIRANDA’s text suggestions
2. Adding a word to the blacklist/whitelist
3. Removing a word from the blacklist/whitelist
4. Sending a pre-written email to a peer through the Share button
We gathered both qualitative data (tester comments, expressions, body language) and quantitative data (time spent on task, number of clicks, number of failures) from each of the testers and compiled it all into one document. From this document, we were able to compare test results and determine information such as mean task times, outliers, and most common problems. This information will be useful in creating our final product.
In 10/25′s class, we showed our detailed designs to test users from other teams, and asked them to help us identify Heuristics that were violated. This information would help us moving forward to make changes to our designs before we invest time into making a more high fidelity interactive prototype.
Our first test user was shown the design for modifying personal lists- adding, removing, and editing the words which the system should flag and replace. He gave us feedback specifically about our wording, that the confirm action button when editing a list element could be more clear or specific than “Accept”. He told us that it might be more natural to show suggestions as underlines instead of highlights. Our first interviewee also mentioned that the button to send your writing to a peer that appeared in the email draft space looked like spam or malware, and that they wouldn’t click on it.
Our second interviewee gave us generally positive feedback, noting that the use of color and it’s meaning wasn’t immediately obvious, leaving room for improvement.
From this feedback, we developed a list of items to change in order to move forward with the creation of our prototype.
After having established the foundation of our application from interviews and constructing the WAAD, we were now able to begin designing MIRANDA. The majority of our time this past few weeks has been spent creating wireframes of what we anticipate our application to look like. The current functionality we have been modeling for includes: Adding and removing words from a blacklist/whitelist, content sharing, as well as general use. Interaction flows for these main tasks has been generated from HTA’s (Hierarchal Task Analysis) the group created.
After creating the initial wire frames and going through a simple user test with another group from class. The tester was presented wireframes of our system and asked to talk through how they would interact to perform the desired tasks. We observed and recorded how the tester interacted with our wireframes and any problems they had as well as what they enjoyed. We incorporated the given feedback into our design and updated our wire-wireframes to account for this feedback.
These last few days we have been turning our refined wireframes into detailed prototype screens as well as searching for more women in computing who are willing to be interviewed and test our application.
With the interviews finished, we were better able to understand all of the needs and requirements of our users. It quickly became clear that the two primary work roles would be the author (the person writing the text to be edited by the product) and the audience (the people receiving the edited text). Many other work roles fall under these broad categories. For example, the author could be a professor writing an email to his/her student audience. Or the author could be an employee communicating with another coworker. We modeled the flow of the user experience in a simple flow diagram. It demonstrated that the user would interact with the Miranda Chrome extension, which would then communicate with Miranda’s servers to suggest edits to written text, and then forward it on to the audience.
Once the general work flow was done, we began looking into more specific requirements. To help with this, we created a Work Activity Affinity Diagram (WAAD). Each member of the team selected an interview and drafted work notes based on our observations of the interviewees and their responses to our prompts. We then categorized the work notes on the WAAD to get a better idea of what most of our users were looking for.
We pulled our interactive design requirements directly from the WAAD, citing the exact notes the requirements came from. We named and categorized the requirements and provided rationales for those that needed them. We hope our finished product will meet each of these requirements. Finally, we created a list of usability requirements that will use quantifiable results to benchmark the product.
Creating the WAAD was a very effective way of sorting through all of the results we obtained from the interviews. It allowed us to categorize our work notes and clarified what our target audience needs from Miranda. Soon we will start designing the product with these needs in mind.
After some deliberation following last class’ project idea brainstorming session, our group selected to prototype the Power of Language Suggestion Tool for the purposes of this class. We decided to call the product MIRANDA in honor of a Professional Communications professor at RIT who stressed the importance of powerful language in the workplace. In this case, MIRANDA stands for Metacognitive Inline Reader Administering Non-submissive Dialogue Automation.
Today’s lecture covered Contextual Inquiry; the act of interviewing and observing your target audience perform the task which your software seeks to improve, or face the problem your software is designed to solve. We were tasked with planning out a rough interview, as well as finding and executing this interview plan with 5 women in computing. In addition, our team decided to give the same interview to a few computing students who do not identify as feminine, to really understand how our problem space uniquely affects female computing students.
[Expand this post to read about our awesome interviews we will be conducting]
For our interview plan, we decided it was best to try to open with some simple friendly banter, then cut right into a scenario-based activity. We considered opening with some contextually relevant questions, but the decided that by suggesting we were looking for patterns in grammatical structure and vocabulary, that it could lead the interviewees to use language they otherwise may not have.
Our first scenario should play out something like this:
You’re working at main headquarters, but your boss works from a remote office. You feel you deserve a raise, and you happen to know that a male co-worker with identical qualifications and slightly less work throughput makes more than you. A female friend of yours in the office confides in you that she agrees you deserve a raise, but mentions that your mutual boss can be unreasonable at times. Write an email to your boss asking for a raise.
This situation is designed to put the interviewee in a position where they have tools at their disposal that they could use to ask for a raise- the idea that a comparable co-worker earns more with less to show for it. We hypothesize that the female subjects we interview will use less active voice statements, and vocabulary that is less demanding than their male counterparts.
As a secondary scenario, we want to analyze how women speak differently in technical discussions than men might. For this situation, the interviewee will be shown a pull request written by someone with a clearly masculine username, and be asked to leave comments about the code they see. This code will be intentionally low quality, so there should be plenty to write about. We want to see how strongly they express their technical opinions to a male co-worker, on a project they are told they have stake in.
In closing, we will finish the interviews out with questions regarding how the interviewee felt about the scenarios, their feelings about their writing, and any similar situations they’ve experienced in the classroom or on co-op. Questions like, “Have you ever felt anxious to leave technical feedback to a co-worker?”, or “How many times do you re-read through an email before sending it?”.
We hope the information we collect from our peers will help guide us to design a solution experience that helps the user navigate these situations with more ease and less anxiety, that empowers them to succeed and excel in their field.
Today in class we were asked to meet with our groups for the first time, and brainstorm three ideas of products we could build to address any issues in our problem space, with attention to usability features and details. After some internet searching, deliberation, and discussion with our professor, we came up with the following product ideas:
- Name Obfuscation System: Research shows that feminine internet identities, especially those in the space of computing, are more likely to be met with pushback. Pull requests tagged with feminine names are more likely to be rejected than those with masculine or gender-neutral names. Technical discussion boards often disregard contributions made by users with female sounding names. A system could be conceived that would extend one’s browser and identify when the user was operating under an explicitly female identity, and make suggestions of alternative aliases to work under. While not directly addressing the greater issues associated with this problem space, this could be a useful tool for real women who need to be heard and have their code merged today.
- Unconscious Bias Simulator: Unconscious Bias is a team issue that all minorities have faced at some point in their professional career. We believe that instead of only training minorities to deal with this bias, biased individuals should become aware of their biases and learn how to shift their behavior to be more inclusive. For our purposes, we can achieve this through a training simulation used in an introductory class for the Software Engineering department. One way we can achieve this is to execute by analogy. If we display common behaviors individuals execute when interacting with someone they do not respect or trust, we may be able to link that with real interactions that have transpired with minority groups. Alternatively, another goal of this simulation could be to get others to speak up when they notice unfair biases affecting team communication, and to help them notice these biases more frequently.
- Power of Language Suggestion Tool: Online sources often cite the tendency of women to use less powerful language as a barrier for them to overcome in order to be taken more seriously in the workplace, especially when that workplace is technical. A simple tool could monitor the use of language structures and vocabulary in a browser, and make suggestions of more assertive ways to get their message across. For example, if a user were to be writing something like, “Maybe we could consider using a heap sort here, because it might be faster than bubble sort”, some visual could suggest they instead say, “Merge sort will always out perform bubble sort, so we should be using it here”. This type of tool could be useful for users of all genders, while addressing a commonly cited root cause of oppression of women in computing.
