Baldur is a Geospatial Tool used to support Intelligence Analysts.

OVERVIEW

The Air Force Intelligence Community needed re-envisioned workflows and tools for processing, exploiting, and sharing collected data

My team consisted of designers, developers, cognitive systems engineers, and a project manager. We met multiple times weekly to collaborate, create artifacts, and critique our work.

Some of the details of this project were classified and required a clearance to view. I was not cleared at the time so I had minimal contact with the end users and details of the project, requiring some workarounds.

PROBLEM

Intelligence Analysts create reports that provide critical information for mission planning and targeting specialists. Generating this intelligence is difficult for analyst teams because it entails:

01.

Frequent updates to maintain a fresh understanding of Order-of-Battle (OB)

02.

Costly workarounds to synthesize OB data into actionable insights

03.

The need to work across multiple tools

04.

Diminished sense-making and shared situational awareness

PROJECT GOALS

01.

Refine Current Prototype

The primary goal of this project was to update pieces already developed. The tool had a lot of flaws that needed refinement, including the data table and map.

02.

Explore Alternative Designs

The secondary goal was to develop new ideas for visualizing the data.

Design Process

STEP 1

Research & Understanding

The first step of the design process was to research the end users and gain an understanding by creating the following artifacts:

  • Scenario timelines

  • Competitive Analysis

  • Goal-Means Decomposition

  • Heuristic Evaluation of the old Prototype

  • Swim Lane Diagram

Scenario Timelines

To understand the work of the Analysts, we reviewed scenarios from past events, which helped us create timelines for their process. Since we were limited in meeting with the user, this allowed us to understand their goals promptly.

Competitive Analysis:

I researched applications with similar features to discover new trends and ideas.

Goal-Means Decomposition

The Goal-Means Decomposition helped us identify all of the goals and sub-goals for the tool. Starting with the highest level goal and moving down to feature-specific.

Swim Lane Diagram

As a team, I led a group activity to identify all the different users, data sources, and other tools involved in Baldur. We gave each role a lane and showed their workflow from left to right.

Heuristic Evaluation

Using Jakob Nielsons 10 Heuristics, I critiqued the old prototype to identify usability issues, flaws, and possible feature improvements.

  • The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.

  • The design should speak the users' language. Use words, phrases, and concepts familiar to the user, rather than internal jargon. Follow real-world conventions, making information appear in a natural and logical order.

  • Users often perform actions by mistake. They need a clearly marked "emergency exit" to leave the unwanted action without having to go through an extended process.

  • Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions.

  • Good error messages are important, but the best designs carefully prevent problems from occurring in the first place. Either eliminate error-prone conditions, or check for them and present users with a confirmation option before they commit to the action.

  • Minimize the user's memory load by making elements, actions, and options visible. The user should not have to remember information from one part of the interface to another. Information required to use the design (e.g. field labels or menu items) should be visible or easily retrievable when needed.

  • Shortcuts — hidden from novice users — may speed up the interaction for the expert user so that the design can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

  • Interfaces should not contain information that is irrelevant or rarely needed. Every extra unit of information in an interface competes with the relevant units of information and diminishes their relative visibility.

  • Error messages should be expressed in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution.

  • It’s best if the system doesn’t need any additional explanation. However, it may be necessary to provide documentation to help users understand how to complete their tasks.

STEP 2

Sketches & Wireframes

Due to limited communication with the end users, we had to get creative with tasking. After the initial research, I began sketching out my understanding and developing rough ideas for the tool. This was complicated because we had little direction and were unaware at the time of the constraints and scope of the project. However, sketching at a low fidelity helped me get feedback without spending too much time on ideas that might not work out.

STEP 3

Feedback & Ideation

After getting feedback on my sketches, we realized they were out of scope for version 1. Instead of focusing on a complete redesign, we shifted gears to update specific features. The data table was first on that list due to its confusion. I began identifying all of the components in the table and how they should function. Once I understood how it currently worked, I started redesigning it in Adobe XD.

Before

After

Table & Map Interactions

After getting positive feedback on the table redesign, we moved on to showing the interactions between the table and map. This was done in Mid-fidelity without a design system in place.

NEXT STEPS

 

Unfortunately, I could not see this project to completion due to being needed elsewhere. If I were able to continue, my next steps would have been the following:

  1. Create a clickable prototype of my wireframes and conduct some user testing.

  2. Make adjustments to the wireframes based on user testing and create a design system.

  3. Create a high-fidelity prototype and hand it off to the developers for production.

Thank you for reading my case study!

Check out some of my other work below

Fight Tonight
Planning Tool

Tech Scout
Social Network