ux case study 2
NZ Airforce - Seasprite Heli App
Many years ago, we developed a website created in Adobe Flash for the New Zealand Airforce to help train their helicopter technicians and to help them learn various aspects of maintenance for their Seasprite helicopter fleet.
Since Adobe Flash was being faced out due to their ActionScript security issues, the client needed to update it and also include additional modules in order to make it a more efficient learning experience.
Most of the learning content from the old website was still relevant but it could not be accessed because it was created in Flash. We needed to deliver a solution for the Airforce that was not only easy to access, but also more intuitive and easier to use for both students and instructors.
The website was scalable, interactive, and accessible, but originally it was only designed for their training desktop computers we came up with a solution to include both phones and tablets, even though. The phone version had limited functionality and served more as a reference as opposed to a full training platform.
Roles & Responsibilities
Role: UX Designer, UI and Graphics
My role was not only to refine the information architecture, but also introduce the visual elements and often redraw or redesign them and test rough prototypes to see if they were viable.
My role was to understand the needs, areas of importance, and relevance, and how to make the content more accessible to both the students and instructors.
I was tasked to come up with low-fidelity prototypes showing how the app was going to work on mobile, tablet, and desktop breakpoints.
I also created a journey map for the students, their timelines, relevant tasks, events, and personas as well as created user flows.
Also, some information architecture, creation, and curation of visual elements such as diagrams, graphics, and other digital assets are to be used across the project, for example, some graphics were used on print media or blended learning.
I also helped with some Learning Experience as I am versed in mechanical engineering, I helped with some trade advice and making the new chapters of the NZ Air force Seasprite heli app flow and mesh well with the existing chapters from the Flash presentation.
Branding and visual layout were also important aspects of the NZ Air Force Seasprite Heli App because it needed to retain its military feel and remain faithful to other previously designed training material so the students had that continuity of training while having extra resources and features included in it, e.g. links to pdf training materials or maintenance manuals.
The purpose of the project was to upgrade the older Flash training websites by combining a few different Flash apps that needed to be consolidated into a single point of learning for both the students and instructors.
Another goal of the project was to redraw the graphics, diagrams, and other interactive elements due to Flash’s image rendering limitations because during the rollout some of the images looked dated, and a lot of the detail was lost.
There were lots of hyperlinks to other pdf manuals, and documents that needed to be included and that proved challenging but in the greater scheme of things, they assisted and enhanced the learning experience for the students, even someone who is not fully versed with the helicopter could see the benefit of their inclusion.
There were some documents our authors re-wrote, and the same graphics included in the presentation were used for the print and online (intranet) platforms.
Our client wanted all the different visual elements brought together in a central hub which in turn helped them save a significant amount of time saved because everything including files, etc. would be at hand.
User & Audience
The NZ Air Force Seasprite Heli app was designed to help helicopter technicians learn the content in a more fluid and intuitive manner, thus helping the instructor to focus on other important aspects of the training delivery strategy.
This app also helped centralised resources, which became an archive making it easier to find relevant information for the students and instructors alike.
The helicopter technicians were mostly non-commissioned officers from private to sergeant, and they were already familiar with mechanical concepts so the training had to be designed for that particular knowledge and experience level, with less fluff and more intentional.
Part of the requirements for this course was to have a ‘trade’ certificate in mechanical engineering, avionics, or any other trade, and if transferring from another category, they had to fulfill other training requirements in order to perform mechanical duties, such as hydraulics on the aircraft.
The instructors had to be experienced in aircraft maintenance, also be experienced in relevant aspects of the Seasprite helicopter, be instructor trained in order to be able to deliver the subject, meaning our subject writing, graphical content and information architecture had to be pretty tight, we were dealing with SMEs (subject matter experts) so we had to be pretty accurate.
Helping him learn
A qualified tradesman like Jim Dux, is a corporal and he has already finished his basic training and some other advanced training in order to do this course, so the structure, language, and course content have to match his experience, and he is a junior non-commissioned officer, so more senior members also were to do this training course.
Learning the content
This is a quick journey map, and there are more parts to it, but this one will give you an idea of how we map out how the structure of the course was structured.
Scope & Constraints
The scope of the project was to replicate the Flash version of the website into an HTML5 web-based app hosted on their own local intranet, however, as more material was added to the course, we needed to include it into the NZ Air Force Seasprite Heli App and make it all tie in, not only in terms of how it worked but also how it looked.
We also needed to re-create all the digital assets and presentations but this specific one was the first one to be developed.
In terms of constraints, different time zones, waiting for source material, asking questions about specific issues we had and at the beginning the lack of direction this project had initially.
Not all was bad, the slow start was just understanding how to efficiently work with our client in order to produce the work and deliverables they required and at the right time because once we found what worked in terms of dealing with source data, its delivery, it's delivery timing and whom to go to ask questions if unsure, it went pretty well.
We had difficulty running the old Flash version of the presentation and we had to get a ‘stand-alone’ computer to run the presentation that was put on a compact disc (CD) the computer was a bit slow at times but, once we got all the information we needed it, we saved it and manage to access it whenever we needed it.
We were given a copy of the Flash presentation on disk, and a reference manual and were told to replicate the presentation on a web-based platform, but eventually more topics were added and it went on from there.
We were asked to keep the lesson structure similar to the workbook, the training manuals, and the flash app, which was well organised so that was not a problem, all we had to do was to add extra topics.
We had an extra challenge, to incorporate 3D modeling into the app, so coding had to work on all levels, it had to be exported to a reasonable level of fidelity without the app blowing up in size.
My research method was a combination of behavioral (from low fidelity to high fidelity prototyping), qualitative (usability testing and how it works also look and feel), and attitudinal (User interviews, what is important) are some of the points we considered designing this app.
Once we mapped out the old Flash version of this app, like a tree, we added new ‘branches’ or topics to it and we kept the same navigation style with an up-to-date interface.
We added a quick navigation feature and showcased some of the most important topics, ones the instructors recommended due to their relevance and some due to the difficulty some students were having learning and grasping them.
It was encouraged that we kept the navigation structure the same or similar in order to remain true to other existing blended learning materials that eventually would be re-designed.
We used Adobe Photoshop, Illustrator, Balsamiq, Invision, and Microsoft Word for the prototypes, and any of the written content we needed to fix, or copy and paste from the existing learning material. As for the content within Flash, I manually typed out all the text we used for the prototypes to make sure all content was accounted for.
Some of the existing learning material was old and dated so I had to collaborate with tech writers and source some photographs from the military photographer and from an existing library which was a bit limited.
The SMEs provided some written material which proved to be helpful and it helped me understand how they write the content, military acronyms, and other vital bits of info to be included in the prototypes, like ‘tone of voice’, ranks, etc.
The old Flash had a ‘clickable’ model for the main parts of the Seasprite, and we were going to use a 3D model which was being developed and that required a bit of effort to bring into the app, we could not get it to work for a reason, not sure why, but eventually it became functional.
The added content linked by hyperlinks was a bit confusing, you’d think we would get an excel sheet with the name of the document and a hyperlink, but we had to find them as we went along if they were not provided by the SMEs, and we got it wrong a few times but with the help of instructors and even students we learned what was what and where things went.
Presenting prototypes to the stakeholders was done remotely and sharing screens was a bit of a challenge, some things are best done in person but it worked.
Freehand Sketches - Ideation
Why did I do it?
I took part in this project in order to help the New Zealand Airforce upgrade its training platforms and bring in new training content to an HTML5 platform the devs designed.
Outcomes & Results
Most of the time, things went well, but there were a lot of areas where I feel we could have done better had we taken the time to listen a bit more but, we eventually got it done.
My research method was a combination of Behavioral (A/B testing, what you do not what you say), Qualitative (Usability testing, most used subjects), and Attitudinal (User interviews and guerrilla testing).
I never knew Adobe Acrobat can be used to show 3D models, and it was great during the time it was prototyped, and the feedback was positive, and all we had to do was to fix little things here and there.
Low-fidelity prototyping was a bit hard to understand for the stakeholder, but once the concepts were understood, they were received well. High-fidelity prototypes got the stakeholders excited and they showed how the New Zealand Air Force Seasprite Helicopter app was likely to work.
We had to keep in mind that the NZ Air Force Seasprite Heli App, the printed (blended) material, and PowerPoints matched not only in terms of look and feel but updated content, such as the new graphics, diagrams, 3D models, or anything related to this particular training program.
The testing helped me and the team understand which areas of the app needed to be iterated upon and a leaner and more efficient manner. Understanding the context of where the app would be used was important for the scalability of the app and again, how it would complement existing training material.
I was also involved with the visual and digital elements for the app, I redrew a lot of their existing diagrams, graphics, and other visual communication and training material and that helped m to keep everything uniform, especially the digital library where elements were used for both print and digital.
The high-fidelity prototype was well received and it was 80% MVP and ready to be rolled out, as there were only a few small changes to be made, e.g. new teaching material to be included, and updated technical information on repair/maintenance so we had to incorporate all that.
I had to hand it over, as I was moved to another project but I am satisfied I left it in great hands.
UX was a challenging part of the process, however, as the deliverables came and went, my confidence grew, because not only was I doing what was expected of me but the level of satisfaction showed also how to refine my process a little bit at a time; it helped us understand how to improve an existing project, transition it from an old technology platform to the latest, identify pain points, but it was a wholistic project, usability, information architecture, digital and print assets, journey mapping, stakeholder management, etc. were other areas I delved into.
My communication skills grew because usually I deal with people face to face but a lot of this was done online, via platforms like teams, and I had to stick to the time and get as much done during the meetings as possible.
Some of the feedback was in writing and at times a bit ‘cryptic’. I had to be a bit more proactive in seeking clarification in order to save time on the project, hence meeting all of the requirements on time.
I had to go back and ask for more info a few times concerning different issues, however, SMEs were happy to provide me with an explanation or clarification.
UX is never a linear path, and there are lots of changes of direction, especially when I thought I was going to see through the whole project, and then I was assigned to do something else.
The handover was not hard as all the resources were easily found and accessible on the server, it pays to be organised no matter what we do, our role or capacity, we had to put all the assets in either print or digital and then create different folders describing what each was, I know it seems trivial but many designers just handover the project files without making a distinction where is what or under which folder, etc.
Later, there were times when I had to direct people where to find the files as they did not remember where I told them they were, but I was expecting it, sometimes no matter how well you think you explain things, people are bound to miss a step or two, communication, clarity, and understanding is something we will keep working on for a very long time.
Thanks for reading my case.