Forward Observer Training -
New Features
The forward observer training features were an internally funded project that was connected to a contracted project. Since these feature were IRAD, we had control of the requirements and direction but we were limited on development time which resulted in having to approach the implementation with options that would cause the least amount of technical impediments.
Forward Observer Training: Project Overview
My Role:
Senior UX Designer
Team:
Team Size: 9
PO
3-6 BE Developers
FE Developers
2 Technical Designers
2 QA
UX designer
Duration:
4 months
Deliverables:
I was responsible for Stakeholder, SME & User interviews, Use Cases, Flow Diagram, Personas, Wireframes, Prototypes, UI Kit and Style Guide, Usability Testing, Iconography,, and Final UI design.
Process:
Discovery
Research
Interviews
Existing user issues
Company expectations
Define
Use cases
Users
Flow diagram
Personas
Ideate
Sketches
Wireframes
Brainstorming
Prototypes
User testing
Design
Final Design & Launch
Mock ups
Visual Design
UI Kit / Style Guide
User testing
Final design docs
UX/UI Review
Tools:
Accomplishments:
Challenges:
While at ITSEC I was lucky enough to be able to meet with the company who was contracting us to do the work for their client. In this meeting I was shown the typical set up for the training scenario and was able to ask questions about the set up and the training use case.
The streamlined design, simplicity and functionality of the final implementation was well received and used as an example for other teams to refer to.
Lessons learned:
With each project I learned to be more flexible with direction changes, scope limitations and discovering “why.” The reasons behind the requests will sometimes yield actual motives and allow for a more unified direction that coincides with what is already developed with minimal changes. Asking why every step of the way and not just during the research and user testing process results in a more well rounded bucket of knowledge to design from.
What didn't work:
The PO on the project worked with me as a separate asset on the team even though I kept pressing him for more inclusion. I wasn’t invited to team meetings that he though I would be wasting my time on if I attended, but as part of the team I should not have been omitted. This created a gap between myself and the rest of the team. Even with this, I was still able to be successful in my role.
A challenge faced by the team related to the time the contract was signed and when they were available to actually start on it which ended up being a few months. Due to the delayed start, the aspects of the contract that we were assigned too develop had to be split between 2 teams with one PO in order to be completed on time. To prevent this from becoming a potential problem, the 2 teams were treated as one.
Since this part of the contract was an IRAD tied to a paid contract, the company didn’t want to spend too much of their own money so we were under financial constraints that limited our options. This also increased the stakeholders to impress their opinions more forcefully into the process.
Figuring out where the best locations within the product that the new features could be placed, that worked with user expectations and were technically feasible presented as an interesting task. I worked with technical designers and the PO to come up with various options to explore and user test. The path with the least amount of development work was the goal and once that was determined we had to make it work.
Another aspect of this (and actually many projects) was the conflicting directions from stakeholders. Sometimes we would have stakeholder who were outside the project attended the sprint demos. When this occurred, there would be mixed messages, time spend on justifications for a direction, and possible reworking of a feature. Some stakeholders would miss a demo, then interject at a later date to oppose a design direction decided in the demo they were not present in.
Forward Observer Training: Research & Discovery
Research:
After reading through the requirements most of the research seen below was focused on questions about how these 4 different features would be used in the forward observer training, how they related to each other and if they were connected to each other in anyway. I also researched how the forward observer training was created and conducted, how the training rooms were set up and what the environment was like for both the creation of the missions and the training sessions.
Since access to customers is limited in the military simulation space, I was able to gather a large amount of these answers during the ITSEC convention. The customer was there with a typical set up for forward observer training and was able to demo the training and answer questions.
Interviews with SMEs:
I had various interviews and conversations with the SMEs. These included the PO, 2 upper level managers and the BD.
During the interviews I gathered information on the what the business requirements were, who the users were, how they envisioned the features working, the competition and other general questions.
The biggest piece of information gathered was that this project was tied to a paying contract, but was being funded internally. This meant we had an even tighter budget, but had more control over how it would be designed and implemented. This also meant that the stakeholders were going to be even more invested in its development.
Interviews with users:
We also didn’t have access to the end users. The contract was with another military simulations company who had a contract with the end users. This set up didn’t allow for direct contact or communication with the end users. So any interviews for customer input was substituted out with the company holding the contract and the BD’s knowledge of the users.
Forward Observer Training: Define
Research:
After reading through the requirements most of the research seen below was focused on questions about how these 4 different features would be used in the forward observer training, how they related to each other and if they were connected to each other in anyway. I also researched how the forward observer training was created and conducted, how the training rooms were set up and what the environment was like for both the creation of the missions and the training sessions.
Since access to customers is limited in the military simulation space, I was able to gather a large amount of these answers during the ITSEC convention. The customer was there with a typical set up for forward observer training and was able to demo the training and answer questions.
Use Cases:
The use cases lined up with the 4 different features that were being developed. Of the 5 listed below 2 of them were considered one feature with 2 different functionalities. When ideation started they were designed together as one feature.
Flow Chart:
Each feature was charted out separately since their use was not interdependent. The charts were updated if workflows were revised due to technical limitations.
Forward Observer Training: Define
Sketches:
After discussion about each feature from the PO and the stakeholders, sketches were created to start brainstorming requirements and functionality.
Digital exploration:
Since this project was going into an existing product we had to determine the best access points based off of user expectations. Once they were located, user testing was conducted to see where users expected to access the features. Then all successful options to access the features were presented to the development team to determine the time cost to implement each option.
After location was determined, I began to explore layout options for each feature. From their a final direction was decided on to move forward with.
Wireframes Prototypes:
To do some quick testing of how the features would flow, I set up wireframe prototypes to run through myself and then I tested them on the QA department. (since I didn’t have access to the users)
The workflow adjustments were made based on re-occurring user issues. From their full color prototypes could then be made for more user verification.
Forward Observer Training: Prototype & User Testing
Prototype - High fidelity:
A full color prototype was created so each of the four features to be tested. It was set up so the users could access each feature within one prototype. This was necessary so we could have the entire workflow functioning to evaluate if users could navigate through the entire application.
Once the prototype was completed, test scenarios were created to focus the users on specific tasks. The users would then need to navigate through the application to complete the tasks successfully.
User Testing:
Since I had to rely heavily on the team and utilizing internal assets to conduct user testing, I was designing towards just a basic understanding of using the features. I wanted to make sure that users could locate the features and use them successfully. Since they were not complicated, this testing was sufficient.
Many different testing sessions were conducted through out the development process. They consisted of:
• A/B testing
• Click testing
• Individual in person testing ( local and remote)
The survey seen below was one such test. This one was used to determine an expected location of the features.
In person user testing was conducted on the XD prototypes and was planned for the beta builds once they were in a testable state. We used the XD prototypes to test the overall approach to the new features of this product first. This was to ensure we had a product that was understood by the users before development started.
Testing insights:
Some bigger revelations that came from the user testing included:
1. We had a toggle that was labeled on/off and it was
utilized in multiple features. This had proven to be unclear
to the users. So other labeling options were explored and
then retested.
2. We were using a eyeball icon as a toggle for the Hidden
Entities feature. Users didn’t know to use it for it’s intended
purpose. They thought it was tied to something else. So
we added a tool tip to try to help clarify its use.
3. We had a cancel button that after user tests presented as
unnecessary and was removed.
Forward Observer Training: Style Guide & UI Kit
Style Guide & UI Kit:
The Style Guide & UI Kit information was gathered from the Master UI Kit for all company products. This Master UI Kit was designed by me with the support of the UX team.
Forward Observer Training: Style Guide & UI Kit
Final Design:
Here is the final design for the Forward Observer Training features. These Features were designed to match the new design style for the main company product. The design and usability of the new features were well received by the customers and the stakeholders.
