NASA JPL
HCD Internship
12 weeks spent designing a database of all past JPL mission statistics
*Note: All data values shown below are notional and do not reflect true values
This research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, and was sponsored by the JPL Summer Internship Program and the National Aeronautics and Space Administration
Problem
-
NASA mission details (cost, instruments, and mission design) are stored in individual excel sheets
-
JPL needs all past mission data to create relevant proposal metrics for future missions
-
No centralized methods have been implemented to find or extract mission data for analysis
Goal
-
Build a database application to contain JPL mission information (Mission and Costing Database (MCDB))
-
Implement simple searchability for a large, diverse user group with different needs
-
Add basic data analysis visualizations that can be easily exported and shared
Dynamic
Role: UX Researcher, UX/UI Designer Team: Three Designers, Two Developers Duration: June- September 2018 (12 weeks)
Overview of Design Process
Part I: Data Analysis
-
Prior to my arrival, my team had completed initial user interviews and use cases analysis
-
Needed to identify user trends, information holes, and design goals from interviews
-
To do this, I completed the following:
-
Transcribed Interviews
-
Re-worked Use Cases
-
Created Personas & User Flows
-
Preformed Heuristic Evaluations
-
-
Led our team to decide we needed more user input into the functionality of the future application
Affinity Diagraming Process
Part II: User Research
-
Four different users: Cost Chairs, System Engineers, Cost Engineers, & Subsystem Engineers
-
Discovered a need for multiple functionalities to support all user needs
-
I worked closely with the user groups to:
-
Completed Additional User Interviews
-
Lead Card Sorting Activities
-
Organized Affinity Diagraming Sessions
-
Created Needs Validation Scenarios
-
-
Consolidated all user concerns into a single overarching set of desires for the application
Card Sorting Exercise with User
Part III: Design
-
Provided my team with design suggestions based on my user research
-
Created an Information Architecture for the application based on these deliverables:
-
Card Sorting of Information Architecture
-
Initial Low-Fidelity Wireframes
-
Needs Validation Sessions
-
-
Iterated upon a progressive disclosure-based filtering system design for the database
-
Lead to team to add additional focus of normalizing vocabulary across different roles
Design implementation suggestion screenflow
Timeline
Throughout this project, my team and I had to meet certain sprint requirements, as well as meet with stakeholders to confirm our progress and direction. Below is a list of all of the deliverables that I completed during my time on this project. They expand to give additional context and detail about that design area.
Guidelines
Background Research
I was given all the previous work my design team had done when was first on-boarded onto my project. This involved interviews, some transcribed and some not, basic personas, uses cases, and other preliminary user flows and information. After completing the necessary
background debriefing, I was asked to take the research that had been complied and use it to create a complete understanding of the needs of the tool and eventually use it to make the user interface of the tool itself. I wrote two initial reports about this information.
I then sorted and went through all of the interviews that had summaries, and transcribed the ones that did not. During this time, I also listened to a recorded card sorting exercise to understand what certain users were envisioning this new tool would provide them with. This exercise had been previously summarized but there was vital information missing, which led me to re-listen to it and take additional notes.
PDF reports about the project background
In-Depth Project Details
Use Cases
After completing the transcription of the interviews, I created a matrix, seen below, that had common/expected queries that the users would input into the application. These example queries were created based on the user interviews and past tools that had similar uses. The majority of these use cases had been created prior to my arrival, but I organized it into a more usable and understandable information layout. By including a section about the search parameters, it gave my team a better feeling for the type of searches that the users would be hoping to do-which was the first step increasing a basic information hierarchy.
Use Case Matrix
Personas
As I completed the use cases and interviews, I wanted to continue onward and create personas. The team had already developed basic personas, but they were somewhat incomplete and needed additional information. I was able to take information regarding specific job roles and needs from them, but I wanted more detail such as including use cases and making them feel more like true people.
My mentor suggested that I create a work flow for all of the users, which was then implemented as a way to tell a story about how that user group may want to use the application in the future. Through completing this exercise, I found that the user groups that we were working with did not have any universal workflows, which became a goal of mine for the future MCDB application. I also found that there was many overlaps in the Pain Points of the various users, which was helpful in determining what we should focus on approving upon in the new application.
User Personas (expandable into a pop-up)
User Flows: Competitive Analysis
I realized after working on the project for a little while that we were basically trying to create a user-friendly search interface for an application that had a lot of data available to the user. I decided to try to find analogous search interfaces that could be deconstructed to understand what were strong points and where we could improve.
I chose to use Yelp, Airbnb, and a library website (MCPL) to demonstrate various different user flows. Initially, I created sketches that became high fidelity user flows after my mentor saw my notes and liked my process.
These flows were created to point out the different ways a user can navigate through a search engine's interface. I highlighted the aspects of the flows that seemed particularly relevant to our goals, as well as included a few aspects that were not asked for by our users but could potentially be included to add additional ease in the use of our tool.
After finishing the detailed user flows for these two websites I decided to dropp the library website because it wasn't useful. The other two sites added a different perspectives into the possible capabilities for the MCDB tool, while the user interface of the library search engine was not designed to a degree that would help us move forward.
Initial hand-drawn flows
I took my sketches and built more refined design artifacts that specifically highlighted positive and negative aspects of the two respective websites to get an understanding of possible design implementations of MCDB. I found that there were a few details that were definitely needed in the future design of our application:
1. At least two levels of progressive disclosure to create a filter hierarchy
2. A visualization that displays the results of the query as well as a table to show the results
3. Visibility to see the filters that have been chosen to alert the user of their current status
4. Ability to save/export the results or a single result from a query
Second Iteration of User Flows
Experience Maps: Competitive Analysis (cont.)
After completing the analogous user flows, my team decided that I should consider making experience maps based on my workflows. Because I did not have the ability to do any user testing, I created the maps based on my own experiences interacting with the search engines. I did a map for yelp because I thought they did a very good job creating a hierarchy of filtering- with progressive disclosure- while Airbnb also used progressive disclosure but in a more confusing way. This comparison can be seen very drastically above.
Design Guidelines
Once our team had reached this point in our design research, we decided that we needed to create design guidelines for our application. We presented the research that we had each done, and created an affinity diagram that was grouped by type of desire that our users had vocalized or expressed. These needs more mostly identified through comparing the above user flows and user scenarios.
Final design requirements:
1. Give user options without increasing decision time
2. Use progressive disclosure when possible
3. Help the user find the thing they didn't know they were looking for
4. Use visualizations to provide guidance
Heuristic Evaluation
Prior to creating these design guidelines, our design team had been shown an application called JAM that had been created a few years before and had many of the same goals that we were trying to achieve. I was tasked with evaluating the application to determine if there were any aspects that would be helpful in creating MCDB. I did this through a Heuristic Evaluation and an Experience Map.
As can be seen, the experience of using JAM was not very pleasant for the user nor did the user get all the information that they needed.
JAM Experience Map
To understand where the application and the user were not working together, I did a heuristic evaluation of the application. The reference criteria for the evaluation is written below. They are modified from the article "10 Usability Heuristics for User Interface Design" by the Nielson Norman Group which can been seen here.
Heuristic Evaluation Spreadsheet
This chart shows all the issues that I discovered within each problem I encountered while using JAM. The "x" signifies that specific issue is not correctly solving the criteria that I had created that it failed that parameter. As can be seen, there are many "x"s on the chart, but the requirement that was least accommodated for was the "User Control and Freedom."
There is a matrix that accompanies this chart with examples from the application itself to accompany this chart and give context, but due to my NDA I cannot share the details of that chart here. This evaluation helped the design team to determine both positive and negative design decisions moving forward.
Affinity Diagram
Video of my Affinity Diagraming Process
By this point in the design process, I decided that it was necessary to begin understanding the application's data more completely as well as compile a list of all the user's desires. I searched through all of the interviews that had been conducted and created a list of all of the groupings (filters) that our users had mentioned. I was able to create a document of all the possible filters, which ones users asked for, which they did not, and the specific data points that could be filtered. I then cross checked this list against the data that would be available in the application.
During this time, I discovered that the numerous filters that various users wanted needed to be organized well to make the application usable. I created a list of the major questions/issues I had about creating an information architecture for this data base. These questions were the pieces of my diagram.
The goal off this session was to find an overarching question that would lead me to the next stages of my design process and help me to understand the goals that I had for the application. I completed an affinity diagraming session for myself to identify this single question that I wanted to work towards.
Final overarching question:
How might we create a progressive disclosure-based filtering system that helps users find specific low level mission details with wide ranges of diverse data while also normalizing vocab across different roles?
Information Organization
I decided that I had enough information at this point to begin to create a diagram of what I believed the Information Architecture of this application was going to look like. I was able to take all of the filters that I complied from the interviews and create a two level system that embodied what I thought were the desires of the users.
Based on the interviews that I conducted, read, or transcribed, I was able to curate and place the most commonly requested filters are on the first level of the diagram and the more nuanced filters on on the second. This architecture is based on the assessment that I was able to make from the spreadsheet with all of the data, the user interviews, and my above assessment.
But, I had some questions:
Were there two levels of hierarchy?
Did I have the correct type of the data expressed?
Was the order of the high level filters correct?
Was the order of the sub-filters correct?
Initial Information Architecture
Card Sorting
I chose to do a card sorting exercise because I felt that it could answer my four major questions in a very quick way, as well as give the user immediate feedback that I wanted to incorporate their ideas into the design as much as possible
The exercise was very helpful at identifying areas of vocabulary with which I was unfamiliar, as well as showed what filters were useful to our users. I was able to take away four major points:
- There should be two major levels of hierarchy
- For the most part, the categories that the users had mentioned the most in pervious meetings were the
most desired filters
- There were additional filters the each user was able to add to my architecture during the exercise that I
wasn't even aware were desired
- The organization of the sub-filters within the categories were not very important to the user
Information Architecture
Four Users' Ideal Information Architecture
These are the four different information layouts that the users I worked with provided me as their ideal filtering system. As can be seen, there does not seem to be any patterns or consistency across the four users, but I felt that there must be something that all the users desired. I took these filters and did a mini-affinity diagraming/card matching session to understand the similarities between the users. This shows my work for only three of the users' first level filters, but my final data model includes all the user feedback.
Video of my mini Affinity Diagraming
Low-Fidelity Wireframes
From the research that I conducted, as well as the extensive work that I did to create the informationmarhitecture for the interface of MCDB, I was able to make some informed design dessions about the user interface of the application.
I created these initial sketches of the interface and was then able to create a higher fidelity screen flow that demonstrates how I envision using the design guidelines to best display the information of the application.
My Sketches
Screen Flow Mockup
Reflection
Working at JPL is an incredible experience. The intelligence, energy, and excitement is palpable, and I truly enjoyed my 12 weeks here.
If I had more time, I would have liked to have been able to spend a bit more time on the users as part of this project, but due to their busy schedules, that wasn't possible. I would have also liked to better understand the user groups and their needs prior to creating their personas, as I think that would have given the project a steadier ground to initially stand on.
I found that I grew in my design abilities, as well as my abilities as a communicator and colleague This was one of two projects that I worked on, with the other being an application that is currently being deployed. These two applications gave me the opportunity to work in two very different parts of the design world, the research side and the implementation side. I was able to work closely with a development team, which was a new experience for me and something that I found to be very rewarding.
And finally, a big shoutout to my beach volleyball team, you guys are the best! :)
