Cyber COA
Conceptual design to guide coordination and planning of cyber course of action
Mile Two
Description
Cyber Course of Action (COA) is a research project aiming to understand, model, and simulate cyber technique course of action for a joint all-domain operation. The concept of a Joint-all-domain operational picture is a very new, somewhat ill-defined, but critical innovation needed in military coordination, and cyber operations are one of the newest and fastest evolving parts of it. The goal of this project is to understand what it takes to help distributed team members rapidly assemble, perform a mission, and then disassemble frequently with little to no experience understanding the work of the other members.
My Role: As the UX research lead, I needed to identify the information needs and cognitive challenges of cyber experts as they made plans to coordinate with a joint all-domain team.
My Role: As the UX research lead, I needed to identify the information needs and cognitive challenges of cyber experts as they made plans to coordinate with a joint all-domain team.
Research Questions
What information does a cyber expert need to feel confident in making a recommendation to the leadership of a joint all-domain operation?
Hypotheses and Assumptions
I started with a working hypothesis of how our users worked that was derived from our client’s assumptions. After multiple rounds of interviews and work domain modeling, I was able to reveal a different perspective that the client did not originally understand. This led to a more accurate revision of our working hypotheses and assumptions.
Approach
Literature Reviews & SME Interviews
I began our process by reviewing available literature on cyber security and tactical operations as well as interviewing SMEs in this space.
I began our process by reviewing available literature on cyber security and tactical operations as well as interviewing SMEs in this space.
Work Domain Models
The next step in my design approach was to use various modeling tools to help us see the user and their work domain from different perspectives. Doing so gave me a deep understanding of how the user performs and what impacts their performance.
Below is an example of one such model.
The next step in my design approach was to use various modeling tools to help us see the user and their work domain from different perspectives. Doing so gave me a deep understanding of how the user performs and what impacts their performance.
Below is an example of one such model.
Context Scenarios and Sketching
My first approach to designing concepts was to write the narrative about how we envisioned the optimal user experience in the form of context scenarios—think storyboard without the pictures. I was careful to include all of the learnings from our work domain modeling. These scenarios were key to helping the entire team see and agree on who and what we were actually solving for. From these scenarios, I began sketching ideas for how this might unfold in the UI. I kept track of all assumptions and questions along the way.
My first approach to designing concepts was to write the narrative about how we envisioned the optimal user experience in the form of context scenarios—think storyboard without the pictures. I was careful to include all of the learnings from our work domain modeling. These scenarios were key to helping the entire team see and agree on who and what we were actually solving for. From these scenarios, I began sketching ideas for how this might unfold in the UI. I kept track of all assumptions and questions along the way.
Low-fidelity wireframes & prototype
Since our user is actually actually fictitious, we are going off many assumptions. I turned our assumptions into user goals and from those goals, we decomposed the functions that would support those goals. This created our hypothesis. To test our hypothesis, we build out a low-fidelity design prototype including the functions pulled out of our context scenarios
The images below show some wireframes and some of the screens that I used for the prototype.
Since our user is actually actually fictitious, we are going off many assumptions. I turned our assumptions into user goals and from those goals, we decomposed the functions that would support those goals. This created our hypothesis. To test our hypothesis, we build out a low-fidelity design prototype including the functions pulled out of our context scenarios
The images below show some wireframes and some of the screens that I used for the prototype.
|
|
Study guide and synthesis of an exploratory usability study
With help from our government friends, we recruited participants and traveled out to Pittsburgh to put our prototype in front of some cyber experts and get some feedback. We learned a whole lot and were able to synthesize several common themes to iterate our designs based on our new understanding.
With help from our government friends, we recruited participants and traveled out to Pittsburgh to put our prototype in front of some cyber experts and get some feedback. We learned a whole lot and were able to synthesize several common themes to iterate our designs based on our new understanding.
|
|
Back to the drawing board
Using what we learned from the first round of studies, we redefined our user's goals, and our hypothesis, and I iterated on another round of wireframes.
Using what we learned from the first round of studies, we redefined our user's goals, and our hypothesis, and I iterated on another round of wireframes.
Final Concepts TBD
As I write this, our final concepts are being designed with plans to run another study. The findings from the final study will be published with the intention to inform research on a joint all-domain operational picture.
As I write this, our final concepts are being designed with plans to run another study. The findings from the final study will be published with the intention to inform research on a joint all-domain operational picture.