Providing space effects to warfighters around the world

Team: Design-PM-Dev team of 8

Duration: Nov 2019 - Present

Focus: Research, Web Design

Screen Shot 2021-01-22 at 10.24.17 PM.png

Overview

Space Support Requests (SSRs) are the avenue through which warfighters around the world request support from space assets (satellites, rockets, etc). These requests are processed through the CSpOC, who then task them out to the units that operate those assets.

The SpaceForce collaborated with Pivotal Labs to ship a product for warfighters to easily request support from space assets.

Problem Discovery

USER NEEDS

Screen Shot 2021-01-22 at 11.31.43 PM.png

CURRENT PROCESS & SERVICE BLUEPRINT

Warfighters submit a word doc form to coordinators via email. Coordinators receive these emailed requests and track in excel, then task out requests via email to assignees. Below is the output of a service blueprint workshop I facilitated with our team to map out the process:

Screen Shot 2021-01-22 at 11.38.44 PM.png

PAIN POINTS

Error-prone, time-consuming, and manual process
Lack of request status visibility
Form is hard to read and fill out
Incorrect/missing form fields necessitate back and forth communication across different time zones
Lots of “tribal knowledge”
Coordinators often need to dig up old requests via email to know which assignees to task

Solution Refining

CARD LAYOUT

I chose cards to represent each request because I had to visually show a lot of information, while still making it scannable for coordinators. Over the course of a year, I iterated on this card layout and hierarchy - getting feedback from users every step of the way.

Past iterations

Screen Shot 2021-01-23 at 9.52.31 AM.png

Current card design

Screen Shot 2021-01-23 at 10.07.47 AM.png

Screen Shot 2021-01-23 at 10.07.41 AM.png

KANBAN STYLE WORKFLOW

I had to create a simple, but effective workflow for each request that came through, taking into account all the various states a request could be in. Originally I tested a kanban style workflow but that proved to be too rigid for users. Users needed more flexibility to do what they needed with each request but still maintain enough structure to make it clear what request had been assigned (in execution) or not (needs action).

ACTION SIDE BAR

All actions related to a request would be visible in the details page in a side bar. Each action follows the same interaction pattern - leading to a modal. This design and interaction pattern ended up being easily scalable as we built more features (adding files, commenting, extending requests, etc.)

Screen Shot 2021-01-23 at 10.46.01 AM.png

Outcomes

Reduced SSR processing time from 3 days to 10min
All activity related to an SSR is an a centralized location, instead of dispersed across many emails and documents (both written and digital)
Requesters are able to see the most up to date status of their SSR and know exactly what is happening with it