Goverment

IATMS

An application to assist users and supervisors with process training related administrative tasks

IATMS

quick overview

Scenario Background

The Singapore Air Force sought to digitize and streamline its internal training processes, specifically targeting logistics and workflow management. The goal was to validate the potential for full-scale development (FSD) by launching a pilot project that would test the efficiency gains and collaboration improvements from digitization.

Key Personas

Trainee: Users undergoing training who need access to schedules, assessments, and progress tracking.
Trainer: Facilitators responsible for delivering training, monitoring trainee progress, and providing feedback.
Management: Senior officers overseeing the training program, requiring visibility into overall performance and operational efficiency.

Unique Challenges

Scoping the Pilot Project: While the pilot was limited in scope, the team designed the interface to reflect the full FSD, ensuring it was visually compelling. Only the core pilot flow was functional, while out-of-scope elements remained static for demonstration purposes.
Complex Business Logic: Understanding and integrating the complex scheduling and assessment processes from the operations booklet into the digital platform required extensive research, including interviews and focus groups.

About the client

The Singapore Air Force, as part of a government initiative, embarked on a pilot project to modernize its internal training systems. IBM won the tender bid to execute this pilot, which was designed as a test case to validate the concept and secure approval for full-scale development (FSD). I was actively involved in both the pilot and the subsequent FSD proposal, contributing to the project's success in streamlining and enhancing military training operations.

Stage 1 : Client engagement

"Initiating the journey to modernize and streamline military training operations."

Project briefing

We started with a simple, bare-bones mockup—a basic clickable prototype made up of low-fidelity wireframes, along with a PowerPoint presentation that gave us an overview of IATMS, including the operations, the people involved, and their daily activities.

To kick things off, we mapped out the stakeholders, identifying the key players and those with the biggest influence. We also established some initial success metrics, knowing we’d refine them as we went along. From there, we set up our working process, ensuring we had clear lines of communication and compliance from the start.

Tay Lai Heng, the final decision-maker, held the ultimate authority on project approvals, ensuring our work aligned with the Air Force's strategic goals. Hock Ming, our project management liaison, was our day-to-day contact, helping to bridge communication between our team and the stakeholders, and ensuring everything stayed on track.

Design Delivery Cycle

"Not one shoe fits all" as the saying goes and likewise not every exercise on the design delivery cycle needs to be used. So from the information and with the tight timeline to deliver the project. I marked out the exercises that I felt had the most impact and qualified for this project engagement.

Stage 2: Context Gathering

We kicked off the project with an intensive 2-week discovery workshop.

Discovery Workshop

I curated the itinerary and exercises for a 2 week discovery. We conducted in-depth interviews and focus groups to gather valuable insights directly from the people who would be using the system. We dove deep into understanding the business needs, carefully analyzing the challenges and opportunities. Various artifacts generated from the activity included: detailed problem statements and persona maps and task flow maps.

In-person workshop

After getting a thorough briefing on the project specifications and desired outcomes, we launched right into the discovery phase. The first few days were spent conducting in-person focus group sessions, bringing together various subject matter experts to collaboratively shape the problem statement and map out the current "as-is" scenarios. We sketched out task flows and user journeys, clustering similar ideas into features. Using card sorting, we then prioritized these features based on effort, output, and cost.

The key issues that emerged included:

Limited visibility into training booklet activities.
Challenges in monitoring trainer and trainee progress.
Inefficient manpower reallocation.
Difficulty accessing resources and digital documents.
The need for better tools to generate and manage training materials.

customer journey, task flows and Persona maps

Customer Journey and Task Flows

We quickly realized that the flows for Trainers and Trainees were going to be the heart of the pilot, making up about 80% of our scope. These flows covered everything from daily training activities to resource management, which meant they were crucial to get right. We also recognized the importance of the Management journey. Even though it wasn’t as extensive in the pilot, it was critical for showcasing how the system could integrate with a more comprehensive admin dashboard interface.

Persona Maps

After gathering all the insights, we developed three key persona maps that represented our primary users:

Aiden Tan - Trainee: Focused on tracking his progress and accessing training materials.
Sergeant Jason Koh - Trainer: Needs a robust system to monitor trainees, manage logistics, and streamline reporting.
Alex Lim - Civilian Logistics Officer: Prioritizes tools for analyzing logistics and ensuring operational efficiency.

Service Blueprinting

The service blue print here is the pre-final evolution just note that the main differences were the evidence touch points which were filled in later. But at the start I always like to use service blueprints to help navigate the items we need to always be mindful of.

Stage 3: Ideation

"Straight to mid-fidelity prototyping... thank you, IBM Carbon Design System!"

CARBON - IBM Design system

We laid out all the essential information and got straight to work on the initial design. Given the tight timeline, I decided to skip the low-fidelity phase and jump straight to mid-fidelity wireframes. This was made possible by leveraging IBM's Carbon Design System—a powerful tool that allowed us to move at lightning speed. By doing so, we effectively saved a month of ideation, and the mid-fidelity screens provided our clients with an accurate and visually compelling representation of the product right from the start.

mid-fidelity wireframes

I delineated the screens based on the user journeys of two principal perspectives: the Trainee and the Trainer. It's important to note that this initial iteration did not account for edge cases. Our focus was to align on the core business logic and functionality, prioritizing this over finalizing aesthetics.

Stage 4 : Alpha playback

We presented the client with low-fidelity, clickable prototypes that outlined the user journey. These prototypes were effective in facilitating a shared understanding of the product's flow and functionality.

Playback discussion

The client's satisfaction at this stage allowed us to solidify the scope of the project. The items displayed with transparency were removed from the scope of pilot. We meticulously documented all feedback, setting the stage for the subsequent Beta phase, where we aimed to develop a high-fidelity prototype for more detailed user testing within a select focus group.

High fidelity wireframes

After freezing the scope we are now able to dive in and refine the wireframes from mid to high fidelity. Cleaning up as many lose ends and including edge cases.

Stage 5 : Beta

In the Beta phase, we enhanced the prototypes based on the feedback received during the Alpha phase. Utilizing ProtoPie, we developed high-fidelity prototypes embedded with data to more accurately simulate various edge cases.

Testing

In the Beta phase, we enhanced the prototypes based on the feedback received during the Alpha phase. Utilizing ProtoPie, we developed high-fidelity prototypes embedded with data to more accurately simulate various edge cases. These refined prototypes were then subjected to user testing to validate the underlying business logic.

For the remote testing process, we employed Useberry, which proved to be an invaluable tool. It enabled us to gather extensive user interaction data, including heatmaps and decision trees, and it facilitated the collection of user feedback through integrated forms. These insights were instrumental in confirming the efficacy of the design and functionality before proceeding to the final stages of development.

Beta playback

Having solidified the requirements and scope, and validated the use case, we transitioned into sprint planning. Collaborating closely with developers and the solutions architect, we created detailed user stories. Prior to the commencement of development, we also delineated reusable components, adhering to atomic design methodologies to ensure efficiency and consistency.

For design-to-development handoff, we utilized Zeplin to define the sitemap and detail the CSS styling guidelines. This platform provided the development team with a centralized, accessible repository of the design specifications needed to execute their sprints effectively.

In Zeplin, labeling components with descriptive names and organizing them into categories streamlines communication between designers and developers. Each component's makeup, including its states, variants, and associated assets, is clearly defined. This structured approach not only fosters a shared understanding but also enables developers to swiftly identify and implement these components in the codebase.

The beauty of adopting atomic design lies in the reusability of components across the interface. From basic atoms like buttons and input fields to more complex organisms such as navigation bars and card layouts, each component serves as a building block for creating cohesive user interfaces. By leveraging Zeplin's platform to showcase these components within their respective contexts, developers can easily locate and integrate them into different parts of the interface, saving valuable time and effort in the development phase.

Final Push

Upon successful completion of the development sprints, I developed the User Acceptance Testing (UAT) criteria in collaboration with the client. Following their approval, we conducted the UAT, which we passed to the client's satisfaction.

UAT + DEMO

For the final demonstration, I crafted a comprehensive presentation for the stakeholders and other invited attendees. The live demo highlighted the project's journey, showcasing the functional product. The project concluded successfully with stakeholder approval, and the Final System Design (FSD) was projected to cost between 10 to 15 million over a span of three years.

Closing thoughts

The journey of this project has reinforced the notion that design methodologies serve as flexible guides rather than strict directives, especially when navigating projects with tight deadlines. It's crucial to judiciously select the most appropriate UX methods to meet project demands efficiently.

In my role as Chapter Lead at IBM, I advocated for the shift towards remote testing, utilizing Useberry as an efficient alternative to traditional testing methods. The speed and ease with which we could conduct tests and gather feedback were significantly enhanced, eliminating the cumbersome task of manual data entry into Excel. This change not only saved time but also improved the quality of our insights.

Perhaps the most valuable lesson learned from this endeavor is the importance of fostering a strong, positive relationship with the client. Such a relationship is pivotal for ensuring flexibility and enhancing the collaborative experience. While the focus often remains on tangible deliverables, it's essential to recognize that these outcomes are deeply influenced by the client's expectations and our ability to align with them. Maintaining a healthy client relationship is fundamental to the success of any project, as it facilitates a smoother process and leads to more satisfactory results for all parties involved.