Problem Statement

The number of women technology is alarmingly low with only 26% of computing jobs being held by women (NCWIT, 2017). A lot of women leave the field due to lack of mentorship and network to tap into. The concept of pair-programming is the perfect solution for this problem as it not only helps improve skills and boost confidence, it also builds a network of women in technology. However, women often face difficulties in finding partners to pair program with. There is no dedicated platform to support this search and the existing platforms have mostly male users. To tackle this problem, I have created a Web Application called Coder Girls which allows users to search for pair programming partners.

Process

User Research Interviews

What are users looking for when seeking pair programming partners?

I conducted 5 user interviews of women in computer science (students and industry professionals) who have pair-programmed in the past. While all of them enjoyed the process when done in class/for work, most of them had never tried it outside of class/work because it was difficult to find someone to pair with, who had similar interests and proficiencies as them. These interviews gave me key insights about the need for a partner search platform. I also understood the motivation of my users through this process, with most users wanting this platform when they are preparing for interviews/exams or when they are just starting to learn a new coding language.

Comparitive Analysis

How are users currently searching for Pair Programming Partners?

I looked at the three most popular coding-partner search alternatives currently existing and compared their features, pros, and cons. The competitors included a Badge (pairprogramwith.me), a twitter hashtag (#pairwithme), and meetup.com.

The two major gaps in the existing systems were the lack of resources for in-person (not remote) partner search and the lack of proficiency information across the board. In the user interviews I had found that skill levels were a key criteria for users when searching for partners.

Persona

Who is our target user?

Based on the interviews, I created an empathy map for each persona involving their Needs, Goals and Motivations, Tasks, Feelings, Pain Points, and Influences. This helped me organize their information into Behaviour, Needs, Goals/ Motivation and Personality. Adding their demographics and a personal quote brought them to life. I could empathise with these personas and create a meaningful product for my users.

Sketching

What are the possible solutions to help our users?

Having gained an understanding of who the users were and what they needed, I started brainstorminging a few possible solutions to the problem and expanded them to include storyboards for each. This helped me explore a range of solutions, from physical to mixed reality:
Using a band that lights up when users cross paths, using a dedicated app, fast-switching hackathons, adding badges on LinkedIn profiles, using existing social media networks and posting on MOOCs discussion boards were some of them. (Each storyboard can be read top to bottom)

The solutions were then evaluated for feasability. I chose the 'dedicated application' solution as it fulfilled the problem need of supporting remote and in-person partner search both, in addition to other advantages such as accessbility.

QOC Design synthesis and Design defence

Going forward with the application, I identified one critical feature and explored three solutions of this feature. The most critical feature for this project is search - how a user searches, what is returned in the search, how the search list is presented, what is the order of the list and other such questions. I came up with possible ways to achieve these tasks and analyses each approach against a set of criteria particular to that question. This helped me determine major design decisions such as forced login to allow customization, profile creation to deliver rich results in searches by other users, ordering searches by matching interests to increase chances of a match and using in-app messaging for contact between two users for ease of use and quick response time. The detailed questions, options, and criteria used for each question are shown in the diagrams below.

Paper Prototyping

Paper prototyping was a quick, easy and inexpensive method to get feedback on my design. I tested the prototype with real users and discovered that I hadn't included the feature to edit profile. I also learned that adding LinkedIn login was much appreciated by most users as it reduced their onboarding time. Another hurdle I found in my design was that because of the position of filters, users tended to believe that all of them had to be selected to filter search results. I changed this to a universal search bar to avoid confusion. I gained a lot of constructive feedback in this process and re-iterated over my design to incorporate the insights gained from it.

Wireframing and User Flow

Incorportating the changes from the Paper Prototyping feedback, I mapped out the user flows for the entire application and created wireframes. This instigated me to think about the information architecture of the application and simplify some user paths. The main pages were Onboarding(Creating a Profile), Search, User Profile and Chat. The wireframes were employed while building the digital prototype.

High Fidelity Prototyping

I created each screen in Sketch and strung them together in a workflow in InVision. In the course of this, I did comparative feature analysis on the search bar and decided to change the universal search to include categories. I also added a 'Suggested Matches' area on the search page to increase user engagement. The high fidelity prototpye allowed users to provide specific feedback about areas of confusion. For example, some users were confused on how to save people for future reference, this resulted in the addition of a 'bookmark' feature on the user profile. I chose to use Material UI guidelines for this project as it gave a modern feel to the application and the user is comfortable with it (positive transfer from using other services on the internet).

Participatory and Social Interaction Design

Through the course of this project, I explored multiple design approaches, such as reflective, participatory and value sensitive design. For a topic that involved gender inclusion and coding, I found the participatory design process to be the most helpful. The target user had a lot of tacit knowledge and pain points that aided the design. Since the platform involved social interaction, I used concepts such as 'multiple selves' to enhance the experience of belonging to a community.

Reflections

Over the course of the project I realized the importance of involving the user in the process. Often, what I as a designer assumed to be obvious, was not the case. I also learned to iterate over my designs. This process lead to small tiny steps towards improvement, and before I realised it, my product looked much neater and had a much smoother user experience than what I had set out to achieve. However, if I could change one thing, it would be my user research. I'm afraid I might have a slight sampling bias here since my dataset was very limited. In the future, I will interview more users and perhaps also interview anti-users. I would also like to use a tool like Framer.js/ Proto.io to include microinteractions in my prototype since I believe they will deliver the exact feel of the product. Overall, this project taught me a lot about thinking from the users perspective and using my findings to create a better experience!

Flipkart: UI Designer and Developer

These projects were carried out as part of my employment at Flipkart. Details of the products are omitted due to a Non-Disclosure Agreement.

Project 1: Case Management Tool

Problem: The existing case management tool involved multiple screens with information scattered across them. The goal was to make a leaner tool with better information categorisation to reduce time spent in analyzing each blacklisting case.

Solution: Designed a new web application with cleaner information flow and migrated to a new tech stack (ReactJS) for better maintainability

Tools: Sketch, ReactJS, HTML, JS, CSS, Github

Role: Lead UX Designer and Web Developer

Process

Since the existing application had been in use for over a year, we decided to take up the Participatory Design approach as our users had tacit knowledge about the tool. User interviews were conducted to find the pain points in the existing system. This was followed by drawing an information diagram of the current system and reorganizing it using new categories to arrive at the new information diagram via the process of whiteboarding. Wireframes were created using the results of the earlier activity. A new look was decided for the web-app, keeping in mind the Flipkart brand’s new theme and adding material-UI. High Fidelity prototype was built in code (ReactJS). The new system was tested by users by conducting contextual inquiry style interviews, where users interacted with the system and provided first-usage feedback. After some tweaks, a sample set of users was onboarded for a week. The feedback received from this set was then incorporated into the system, resulting in the final development and deployment.

Project 2: Access Tool

Problem: Data across the team was available in all capacities to multiple users. This data needed to be guard-railed to ensure quality and security.

Solution: Creation of ‘groups’ headed by admins who could determine which individual had access to data in what capacity (read, write, download)

Tools: Sketch, ReactJS, HTML, JS, CSS, Github

Role: Jr. UX Designer and Web Developer

Process

Data within the company has to be secured with respect to who is using it and for what purpose. The team brainstormed multiple solution to adding guardrails, keeping in mind the various types of data the company owned. Brainstorming resulted in creating a few key ideas that we thought were possible technically. These were presented to the stakeholders and after discussions guided by a SWOT analysis, the idea of creating ‘groups’ within the company with admins who could decide privileges for their users was selected. After several iterations of problem scoping and wireframing, a high fidelity prototype was built in ReactJS (HTML, CSS, JS). Usability testing was conducted on this tool with each user being given specific tasks and being observed. Finally, the finished product code was deployed.

Research Question: What are the reference lines present in various chart types? Are these different for each individual?

Tools used: R, ggplot

Solution: Generated a model with greater than 80% fit that describes people's estimate for pie charts.

Role: Research Assistant

Our hypothesis was that everyone reads chart differently. In particular, for a pie chart, each individual imposes a certain guide on the chart to estimate the value that is being depicted in the chart. These guides, what we call implicit reference lines, affect the estimations errors. I created a cyclical power model to accurately predict the estimation errors when a person is presented with a certain quantity on a pie chart.
I am currently in the process of writing a research paper for this project.

Interactive Visualization that teaches the concept of Vectors

Goal: Design a visualization that supports learning the concept of vectors.

Tools used: D3.js, HTML, CSS, JS

Solution: Interactive Visualization with a real-world use case of playing with a ball.

Don’t Pull Me Back: Game Design

Problem: Use Papert’s idea of ‘objects to think with’ to make the students aware of the discrimination faced by the various genders ( known as GenderFuck in the New Liberal Arts 2.0 )

Skills: Game design, User Testing for games, Sentiment Analysis

Solution: Board Game

Team: Salik Ansari, Ruchi Ookalkar, Apoorva Savant

Process

We began by exploring the concept of GenderFuck and what it meant in the society we were living in. This lead to a lot of research about gender discrimination in the modern context and also about gender fluidity. Using Papert’s ideas, we wanted to build an object which the user could think with. So we decided to build a board game which would allow the players to feel what real people feel when they are discriminated against.

The examples of gender discrimination were crowdsourced from our social media network. While it limited the society, we received a great variation within that spectrum.

These examples were then given ‘influence points’ based on how significantly they affected the person's life.

Using the influence points and examples, a twist on the traditional snakes and ladders was created. The game consisted of cards, which spelled out the player's gender and punishment for belonging to that gender. The punishment was determined by the points calculated earlier.

The game was tested with fellow graduate students to get a sense of what was going right and wrong. We observed that 4 players were the most optimum to enjoying this game. The final prototype was built and displayed in an exhibition where undergraduate students could play with it. The game invoked multiple reactions, often leading to heated arguments and discussions about the discriminations. It was particularly interesting to note the knowledge exchange happening during the gameplay between members, such as “My mom does this. Why is this wrong?”, followed by an explanation.

Solution: Recommended changes to the current standards and workflow processes to reduce redundancy in work

Team: Anant Mittal, Olivia, Ruchi Ookalkar, Ruth Wang

Problem Statement

ICPSCR (Inter-University Consortium for Political and Social Research) is the world leader in data curation of social data. The process within the organization varies from data acquisition, data cleaning, data massaging, generating metadata and creating codebooks to the final release of data for public use on their website. The organization went through a structural change in January 2018. Prior to January 2018, the organization was divided into topical archives, i.e teams with expertise in a particular archive. Each archive had its own manager who coordinated with funders (who set requirements for the curation). Post the reorganization, all the data curators were brought into one team, lead by curation supervisors. The supervisors communicated with the managers. This change from topical expertise to a general pool has led to a pushback in terms of accepting a uniform standard since they are dealing with historical ways of doing things.

Process

Interview Methodology

We conducted a total of 6 interviews from across the various level of the organizational hierarchy (project managers, data curators, curation supervisors and head of the organization). The interviews were conducted in the contextual style, where the interviewer asked questions at the place of work of the interviewee, often asking the interviewee to demonstrate tasks which came up during the interview. This process helped us discover problems and social issues within the organization. The interviews were conducted by two members - one acting as the interviewer and one as the note taker. We also collected audio recordings of the interview and images from the workplace to guide our analysis.

Interpretation

Each interview was followed by an interpretation session within 24 hours of the interview. During these sessions, we went over the interview notes, recordings and images and analyses these to generate affinity notes - one complete sentence that would describe what was happening at that point. We also noted down any questions we wanted to cover in future interviews and jotted down our analysis of the events.

Affinity Wall

After the 6 interviews, we had about 500 notes. We went ahead and categorized these into three levels. The white notes were grouped together by similarity of content or possible causal relationships to arrive at the yellow notes. We then repeated the process two more times to arrive at pink and blue notes. We ensured that none of the clusters had more than 7 ideas in each. This helped us in writing clear detailed sentences describing each cluster. The final pink notes gave us an idea of what exactly was happening in the organization and the key issues faced by the staff.

Recommendations

From the blue sticky notes arrived at in the affinity wall, we made a map of the Key Findings. These showcased the root cause of the problems our client was facing. We then brainstormed for solutions to each problem, by exploring existing solution in the market and devising our own solutions tailored for our client. The brainstorming exercise resulted in a lot of ideas which were then passed through a rubric of feasibility, cost of implementation, impact of the solution and political acceptance. Following this activity there emerged two winners for each problem area. We then went ahead and created a report of these solutions where we presented both long-term and short-term solutions to our client. (The report is available on request.)

We found that there was a lack of guideline about the work processes and the existing guidelines weren't being accepted due to improper implementation. We suggested that the voices of the entire team be heard when re-drafting the guidelines and including all variations of requirements in the guideline to reduce redundancy in doing the same work as per multiple guidelines.

The move from project-driven to process-driven teams has lead to lack of communication and loss of expertise. For this problem, we suggested holding regular 'KT (Knowledge Transfer) Sessions' to exchange information across the team.

Through our contextual interviews, we discovered that there was a lot of confusion about the new tool JIRA being adopted. While extra training about this tool is an obvious long-term solution, we also discovered that there existed 'in-house experts' - some team members knew how to make better use of the system. For the short term, we suggest installing a whiteboard where members can ask questions and answer them, also leading to more collaboration within the team.

Our analysis helped us realize that there existed some political friction within the organization. This was majorly caused by the lack of communication loops, in particular, feedback channels from lower management levels to higher management levels. We suggested holding regular 'Check-In Sessions', where an employee meets his/her direct manager once a month for a free-flowing conversation about the current work, the employee's future, company policies etc. This has been known to work in the technology industry.

Reflection

This project helped me grow as not only a user researcher, it also helped me grow as a team player. I learned to ask crisp, targeted questions in the contextual interviews and I also learned to take notes in the interviews. It was challenging at first to relate affinity notes to one another but with practice, I became better at it. I definitely learned a lot about presenting my ideas, both to my team members and to the client. I ended up improving my soft skills in this project in addition to becoming a better user researcher.

Defining Research Questions

We started out by speaking to the User Research team at Google, who were our stakeholders in this project. They wanted the project to be focussed on “How college students use the mini and what could be done to increase usage in this demographic?”. We iterated and refined the research questions to the following:

How do college students consume media on different devices?

How do college students discover new or existing features?

Are there ways in which a smart speaker can support students?

Throughout the project, we conducted multiple small studies that involved looking at these questions from different perspectives.

Process

Interaction Mapping

We started out by exploring the Google Home Mini and understanding the system. To do this, we created an Interaction Map. We went through all possible user paths that might interest a college student and drew them out to examine what was included in the system and how they interacted with each other. We found that the Google Home Mini can’t perform certain operations which the companion app can do and vice versa. Another finding was the existence of multiple dead-ends. Although there were multiple branches of the map, each branch was very shallow, often ending in one/two sentence exchanges.

Need Finding Interviews

In our attempt to further understand the product and it’s users we conducted a series of initial interviews with 5 users. These interviews were exploratory in nature and consisted of open-ended questions regarding smart speaker usage. After the interviews, we conducted an affinity mapping exercise and arrived at key behavior patterns from our users. We found that college students were highly mobile and social. These were features that the Google Home Mini did not support. The idea of having a dedicated space for discovering new features appealed to our interviewees. Following the key findings from the affinity wall, we created personas and scenarios which depicted our target users.

“I actually think that [dedicated space for new feature discovery] is more helpful, because then I can just go bookmark it and go back to it. There is no sense of urgency that I have to go do it right now, like a pop up.“

Comparative Analysis

Once we had understood the Google Home Mini system and it’s users we wanted to evaluate its competitors and how the Google Home Mini stood against them. Since our client had already done a lot of research on the features, they wanted us to look at the product from a hardware perspective for this task. We decided to focus on the speaker, microphone and voice recognition quality. Following Mark Newman's taxonomy, we found direct, indirect, partial, parallel and analogous comparators and compared them on pre-decided parameters. We once again found that the Mini lost on portability. It also didn’t perform very well in microphone quality.

Survey

Going back to our original research questions, we designed a survey on Qualtrics that asked current users (college students) and non-users (college students) about their media consumption and perception about the Mini. Our most revealing finding was in the fact that out of 115 survey takers only 9 owned a Mini. The survey also revealed that user’s expectations of the Google Home Mini were high and they perceived it to meet those expectations. We also found that college students were heavily influenced by their social groups.

Heuristic Evaluation

Having found all this information regarding our user’s behaviors and expectations, it was time to test whether the system would fulfill these needs. We evaluated the Google Home Mini using Nielsen’s heuristic categories for usability testing. We found that the mini scored well for accessibility, consistency, and prevention, and understood most accents tested. However, it was difficult for the testers to navigate through the mini system especially due to the need to ‘activate’ the system every time which broke natural conversation.

Usability Tests and the way forward

We are currently in the process of conducting usability tests with college students. We hope to find results relevant to our research questions and improve the usability of the Mini through this project. If you would like to read the detailed findings and recommendations from this project please send me an email.

Problem

There are over 1.5 billion people worldwide learning English alone as a second language. A key aspect of learning a new language is becoming comfortable in speaking it. While there are multiple avenues of learning to read and write a language, speaking remains a problem. There is limited access to speaking partners and constructive pronunciation feedback coupled with the social anxiety of practicing with strangers.

Process

Survey

To evaluate the problems involving language learning, we sent out a survey to students at the University of Michigan and received 148 responses. 73% (n= 108) of our respondents said that speaking was the most difficult part of learning a new language.

Interviews

Equipped with information that speaking was a key concern, we conducted 5 user interviews of beginner to intermediate language learners who had used voice assistants. The conversations were about their experiences of using voice assistants and frustrations and wins while practicing speaking.

Comparative analysis

We then examined the applications that our users were currently using to support their speaking endeavors.

Feature Design

We analyzed the user research to arrive at four features that would help our users the most in practicing conversations in a new language.

Decision Tree (Interaction Architecture)

Having decided the features, we set about designing the user flow. This involved mapping out all possible paths and creating a decision tree based on user input and expected output. The process was repeated to extend the tree for all features. We followed Cathy Pearl’s book and determined the interaction architecture for Chattie.

Script Writing

To write the scripts for each dialog, we conducted multiple hallway tests to understand how people spoke in the real-world. This involved giving them small prompts such as “What did you eat for dinner yesterday?” and then analyzing multiple responses. With each test, we iterated the exact wording of the dialog until we received the most natural responses and minimum confused looks from our users. We also designed scripts for multiple dead-ends i.e when the user wanted information that Chattie was not equipped to provide.

Wizard-of-Oz Test

We conducted three Wizard-of-Oz tests by recording clips and playing them through an Amazon Echo Dot. 3/3 users found the design easy to use and rated an average of 4.3 (out of 5) for “likely to recommend to a friend”.

During the initial tests, we found that our users described Chattie as a teacher. This was in stark contrast to the "friend" vibe that we wanted to design for. We changed the language to include everyday vocabulary and encouragements, such as, "That sounds yummy" or "I would love to try that." Our subsequent user described Chattie as a friend which meant our script changes had worked. Overall, the wizard-of-tests proved the success of Chattie as a design solution for the problem of speaking a new language.

Reflections

This project was a self-initiated effort born out of my passion for Voice Interfaces. I learned to design decision trees, write scripts and found myself observing the mannerisms in which people talked. It not only helped me implement all my readings of how-to-design-for-voice but it also brought forward a lot of new questions - How does accessibility in voice work? How do we account for accents? How does the physical environment affect the user? I hope to delve deeper into this realm and explore the endless possibilities that voice offers.

Context Panels on Dashboards

This project was done during the Product Design Internship at Sumologic

Problem: Users feel lost when investigating causes for alerts on Sumologic and lose critical time

Solution: A Context Panel feature on dashboards to improve the investigation and troubleshooting experience of our customers

Tools: Sketch, Framer.js, UXPin, Pen, and Paper

What is Sumologic?

Sumologic is a log management and security analytics company. In simple words, it provides businesses a web-based tool to monitor their machine application data and investigate breakdowns.

Design Process

Goal

When our customer’s application breaks down, their DevOps engineers receive an alert about the issue. We have a persona called Andre that represents this user. Andre logs onto Sumologic to examine the issue and investigates the cause of the outage. Since he is coming to the platform at a critical time, we want to ensure an efficient and smooth investigation experience for him. The goal of the internship was to

Improve the Investigation Experience on Sumologic for Andre

Understanding Pain Points

The initial goal was very vague. In order to deal with the ambiguity in this project, I decided to examine our users' behavior. I wanted to understand how they currently investigated on the platform (existing user behavior) and the gaps where Sumologic was failing its users (pain points).

Through user interviews we found that users used a node-branching search pattern, had difficulty in correlating various data sources, and often felt lost during the process.

Brainstorming & Stakeholder Review

Equipped with this information, I brainstormed three design features to help our users - Timeline, Playground, and Context Panels.

I presented these options to the stakeholders (UX Director, Engineers and Product Managers). After discussions about the business impact, we decided to go with the Context Panels solution as it prompted our users to enter the Logs Page (which drives most of the income at Sumologic).

Competitive Analysis

I looked at both direct and indirect competitors to understand how they presented related content and helped users in investigation.

Storyboarding

Having understood how our existing teams presented content, I wanted to go ahead and start designing it. However, before actually putting pen to paper, I built a storyboard to examine the scenario when this feature will be used. Through this process, I understood the environments our users would be in and their context of use.

Wireframing

Upon inspecting the user needs and business requirements, I combined the two to arrive at necessary components. I then collaborated with my mentor to decide the information hierarchy within the context panels and built wireframes to demonstrate the same.

Prototyping

Once we had designed the wireframes, I used the component library to complete the visual design in Sketch. I then thought about interactions across the feature’s life cycle - how it would interact with other elements in the product, where the links would direct, what within the context panel would be interactive etc. I captured all these interactions in a clickable interactive prototype built using UXPin.

User Research & Design Iterations

I worked with the User Research Team to test this prototype with our users. We conducted 4 interviews which involved a demonstration of the prototype followed by asking the users for their reactions/impressions of it. 4/4 Users found value in the feature and suggested use cases where they would find the feature useful. This was a major success criterion for the project following which the feature was handed off to a scrum team to build

"Pivoting [enabled by Context Panels] is a very useful thing. I don’t have to write a new search, and it’s easier to find the root cause." P2

Based on the interaction specific feedback, we iterated over the design. We added a logs histogram in the metrics context panel since all users suggested it would be useful. We removed the zoomed-in state since the product already had a ‘Zoom’ button with the same functionality and all 4 of our users were confused with this interaction.

Final Design Features

Reflections

This industry experience of being a Product Designer at a mid-size startup taught me a lot. It not only helped me improve my prototyping skills (by giving me a chance to learn UXPin, Framer.js), it also helped me improved my soft skills. I presented design decisions to various stakeholders, working within a cross-functional team and improved my communication skills. Working with an enterprise product required me to develop empathy and think about my users more than I had done in the past. The entire process gave me a taste of dealing with ambiguity and using my design skills to create a seamless user experience.