top of page

Service Health Platform for In Flight WiFi Network

Product Context

Our client was launching an in-flight connectivity service which would be served through a network of ground sites and received by the plane via antenna.

 

The Service Health Platform would act as a central location for all metrics across the systems supporting the service. It would aggregate and analyse data to provide a view of service health to a range of users

Service Health and Data

There were many different aspects that would contribute to the quality of connectivity experienced by passengers. Including, but not limited to, the weather, the position of the plane, the plane's altitude, the terrain on the ground, the hardware on the ground sites and the health of the data centres.

 

Each of the myriad of components that made up the system had corresponding data metrics for it's health. All of these health metrics would be aggregated in the Service Health Platform.

Potential user groups of the Service Health Platform

There were a wide range of potential end users of the Service Health Platform, each with their own needs, consequently requiring different things of the data.

​

The primary user groups specified by our client for the initial rollout of the Service Health Platform, were those users responsible for the delivery and support of the in-flight connectivity service. Within that, Technical Support were our initial focus, as on initial rollout they were to act across all the Primary user group roles.

User problems

In early research the needs of Technical Support were categorised into three key themes or problem areas. They were, Proactive Monitoring, Reactive Support and Root Cause Diagnostics. Understanding these themes, designing and delivering a platform for each of them formed the basis of our work.

My Process Overview

My role and work

  • One of two designers

  • Moved into Lead Designer role mid-way on project

  • Concurrent understanding of technical domain and user needs gathered

  • Translation of user needs into concepts for data visualisation 

  • Communication of concepts to both technical and non-technical audiences

  • Facilitation of co-creation workshops

  • Running user testing sessions

  • Close collaboration with development teams throughout all stages of the process

  • Domain and system understanding gained in order to translate user needs into informative 

  • Worked closely with the Product Manager to prioritise user stories​

Domain understanding

An understanding of the network, domain, terminology and the multiple systems at play was crucial in ensuring we had a deep knowledge of their service. Considerable time was spent early on with all levels of the client’s organisation, from the VP of Technology to the Technical Support users, as we worked with them to get in-depth explanations of the network structure and maturity. Key activities included:


• Defining consistent terminology 
• Immersion in domain 
• Diagram creation for communication of domain 
• On-boarding new team members
• Mapping where different data was coming from
• Collaborating on ways to aggregate data into meaningful insights

Research & Initial Concepts

There were several stakeholders and many possible users of the system. Understanding who they were, how they interacted and their needs of the Platform was vital.  Research into these users included visits, interviews and journey maps. Technical Support users were identified by the client as the first target user of the platform and so further research centred around their needs. Key activities included:


• Stakeholder mapping & workshops
• User observation & interviews
• Workflow analysis & user journey maps
• Wireframes 
• Data visualisation concepts 
• User & stakeholder workshops
• Test flight observation 
• Co- creation with development team

Group 5231.png

Design, prototyping, testing & implementation

A key feature of the Platform was the ability to view historical and current service information. How these views were shown in the UI not only had an impact to the user interaction but also how the data was stored. It was important to get the right answers to these questions to avoid costly architectural re-work. Key activities included:

​

• Utilisation of Material design patterns
• Prototyping to communicate and test concepts 
• Testing of prototypes with users 
• Working alongside dev team to implement 
• Iteration of designs 
• Collaboration and consideration of end-end design

Group 5232.png

Final Solution

The initial deployment of the Service Health Platform compiled the different data metrics into a number of different formats that helped Technical Support in their role of monitoring and troubleshooting the service.

 

The first view was of Service Health, viewed geographically and summed up into 50kmx50km boxes. This abstraction of the beam patterning model was the core principle that allowed users to the explore "squares" of service health and understand the contributing components for that area of service. The three dimensional Service Health data was "sliced" into three most common altitudes for business jets, which the user could then select between. Different filters, such as terrain, were available to provide context to the service health information.

Tobago Non-branded service health.png

A second view allowed the Technical Support users to simply view the health of all of their Ground Sites in one comprehensive view.

Tobago Ground site list.png

A third page let Technical Support users see a single flight's data and this was broken into a number of views to allow for easy analysis. The top showed the overall KPI's for the flight, below which a chart showed the cross-section of the flight, allowing for altitude to be displayed against the ground sites that served the flight. Other charts visualised data centre metrics and plane telemetry. All charts were time aligned, allowing the user to scrub to a specific time and view all contributing metrics via a tooltip.

Flight View.png

Summary

What I was proud of:
• Taking a leading role in a multi-disciplinary team
• Creating simple visualisations for complex data
• Successfully managing communication
• Fostering a spirit of openness and honesty
• Delivering a platform that allowed Technical Support to see and easily understand their network metrics and implications on service health

​

What I learnt:
• User story mapping for research & backlog creation
• Agile methodologies and benefits.
• Power of GitHub for complete workflow 

© 2021 by Sophia Godfrey

Follow

  • Linkedin
bottom of page