Hong Kong Emergency Dispatch System

DESIGN PROCESS

PRINCIPLE

4GMS is a mission-critical mobilizing and communications system for emergencies. The system is designed for HKFSD’s internal use; at the same time, HKFSD is a public servant, so the system should also be able to respond to public expectations. Based on the product’s nature, I figured out the main principles to follow throughout the design decision as shown below.

TAKEAWAY

Worth taking the time to dig into the product

Over two years, I have participated in dozens of feature designs. I will not go through them one by one here. Instead, I will pick a few features that are worth sharing and write in separate articles in the future. Below is the overview of my deliverables for the 4GMS project.

DELIVERABLES

UI Submission Schedule

Provided advice on design team workload estimation. Received the latest UI requests and updated them on the schedule. Reported design process to the system architect directly.

UI Pattern Library

Built a master library that consists of color, typeface, icons, and components which apply to 8 software sub-systems and 10 devices. Each element comes with detailed descriptions, variations, and application examples.

User Story

Wrote user stories for sub-systems as a medium to communicate with superusers and help them better understand the features.

Screen Flow

Delivered the main screen flow and alternatives that followed all possible operational workflow for each feature. It helps accelerate the discussion and reduce the development team's workload.

Prototype

Built an interactive prototype on an actual console to demo the main operational flow from receiving a call and deploying resources to inputting incident report data.

Walk Through Video

Created an overview video with a voice-over explaining the 4GMS design, including the console workstations, station and depot hardware, and on-scene operation support devices.

System Specifications

Wrote detailed program specifications for the development team to build the product. I mainly contributed to the UI-related sections across software sub-systems.

Test Specifications

Wrote test cases under different scenarios for the testers to perform testing and record results. I mainly contributed to the sections that involved sub-system integration.

Efficient

When life comes to a critical moment, every second matters. HKFSD has pledged to build fire calls within 6 minutes and emergency ambulance calls within 12 minutes. The pledge is also the primary mission for 4GMS, achieving it by enhancing support for console operators and on-scene operational personnel.

Upgradable

Learning from history, the 4GMS design needs to be flexible and scalable to accommodate future changes, and better meet the international standards on emergency management.

Secure

This system has to work. Life depends on it. Sometimes there is a more innovative way to fulfill requirements, but we have to choose security over convenience to reduce the chances of malfunction.

Study

The initial stage of the design involved a lot of study time. In the first few months, I read hundreds of pages of documents and tried on the actual console with a null account. But nothing is more efficient than learning from a “Living Wikipedia.” Some engineers have worked in TGMS for nearly a decade. I appreciate their patience in answering all my questions.

Consolidation

Besides product-related knowledge, I also consolidated the system-level business requirements from the system architect, the sub-system level concerns from different sub-system managers, and the superusers’ expectations of the product. I started to understand how complex this system is, the user’s pain points, and the culture of HKFSD.

Plan

After acquiring the essential knowledge, I started to give advice on the design submission schedule, workload estimation, and design team resource allocation.

UI Design

The team uses an Agile approach in the design and development stage. At the beginning of the sprint, I will first consolidate the information from different parties and then communicate with the development manager on the technical limitations. I will then design the UIs and screen flows to help the team in confirming system logic and details.

Prototype

After the team is on the same page, I create high-fidelity prototypes and walk through the pros and cons of each design with superusers. Although it is not efficient to create high-fidelity prototypes in the initial stage, it helped to accelerate the discussion that involved superusers.

Development

Once we have the users’ confirmation of the design, I will deliver the UIs to the development team. When I became more familiar with the system, I helped to write user stories and system specifications.

Testing

The development team delivers work at the end of every sprint, where I help with testing, collecting feedback from the team and superusers, and proposing alternative solutions. I also write test cases and deliver test results to the development team.

Iteration

Together the team iterates from UI design to testing until the next stage - the user acceptance test. Meanwhile, I will work on the next feature in parallel and continue to study the remaining parts of the system.

I remember meeting with superusers for the first time and was overwhelmed by the terms and code names constantly heard in every conversation. I tried to understand more about TGMS myself but could only find outdated documents and screenshots. Since there were only engineers on the team, they could only introduce TGMS to me with system logic diagrams and databases. Going to work for the first few months was like attending intensive courses in high school. I once doubted that it was worth spending 90% of my time studying the arduous data and backend logic with no time to deliver any outputs.

Fortunately, the hard work and patience paid off very soon. Once I understand the terms and system structure, I can instantly give practical advice in meetings. As a new member, I dare to ask questions and sometimes find out the team may have different interpretations of the same terms. Also, I was the only one working for various sub-systems, so I could provide constructive advice on integrated sub-system issues.

To be more open-minded

While digging into system features, I neglected the mobilizing system's nature. The previous projects I worked on were fast-paced commercial products aiming to do the MVP. I am used to following the 80-20 rule when the workload gets heavier. It turns out I forgot that the 20% is also significant in this project. Major critical incidents would not happen every day, but HKFSD still needs to prepare well for those unfortunate incidents. I realized I have to be more open-minded when starting a new project. Even if it is a golden rule, it must be dropped off in order to understand the product and its nature thoroughly.

It has been a fantastic journey

This is the first time I have participated in a massive government project. I appreciate the opportunity to be part of the 4GMS team and contribute to the emergency service for Hong Kong - the city where I was born and grew up in. I have learned so much in this journey.

In the end, I wanted to thank all 4GMS members, especially the CAD system specialist Kelvin Chan who taught me so much from day one, and my design teammate Jasmine Xie who is always very supportive and thoughtful. Also very grateful to have superusers on the team who work hard to keep up the emergency service standards, including all fire and ambulance officers, and technicians from EMSD and the lands department.

During the first month on board, I was squeezing time to study in between meetings while the superusers were standing next to me and discussing topics I did not yet understand. (Left) A small pile of my self-made study notes. (Right)

Part of geographic information system UI design. (Left) Part of the interactive prototype built in Figma. (Right)

As we were about to hit 777 comments, I decided to give this honor to my favorite teammate.

"Empty your cup so that it may be filled; become devoid to gain totality." - Bruce Lee

BACKGROUND

The Hong Kong Fire Service Department (HKFSD) has been using the Third Generation Mobilising System (TGMS) at Fire Services Communication Centre (FSCC) to deploy resources for fires and emergencies since 2005. In 2017, They decided to develop a new system to handle the upward trend of emergency services.

OBJECTIVES

This is a government contract project, meaning the tender's objectives, requirements, and development milestones are already settled. The main goal of the working team is to deliver the required documents and products on schedule. My responsibility is to provide resilient and applicable UX solutions that tackle system issues and maintain user interface consistency across different sub-systems and devices.

Learning about TGMS wasn’t only hard for the newcomers, and it was a challenge for the intermediate users as well. Although the TGMS is in use on a 24/7 basis, there is still a considerable part of the system shrouded in mystery to many of the console operators, system managers, and even the engineer who is maintaining it. I figured the three main reasons.

CHALLENGES

PROBLEMS

The system cannot keep up with evolving user needs

There are known issues in TGMS that haven't been fixed in years for different reasons. The most common cause is that the original system design cannot support evolving user needs.

A steep learning curve for everyone

BEFORE WE START

To comply with my non-disclosure agreement, I have omitted confidential information in this case study. All information is my own or can be found online and does not necessarily reflect the actual situation in the 4GMS project.

Replacement of dispatch system

To build an efficient, upgradable, and secure system

The Fourth Generation Mobilising System (4GMS) project started in August 2019. HKFSD plans to use it for at least 15 years before the next major upgrade. 4GMS consists of 24 sub-systems, 8 of which are software-based, where I play the role of a product designer.

For example, there are technical limitations on data synchronization across sub-systems, which resulted in users going through redundant steps to ensure that data is correctly generated on different reports. Despite the engineers’ continuous efforts to improve the software, they can only make small changes. It is like stacking multiple decks on a moving bus. Over time, the users and engineers must spend extra effort to maintain the system's stability to ensure it works properly.

In TGMS, sometimes operators are required to use both hands on mouses to control different sub-systems. Photo by HONG KONG ENGINEERING ARCHIVE

HKFSD pledged to achieve fire service (left) and emergency ambulance service (right) quickly and efficiently. Photo by HONG KONG FIRE SERVICE DEPARTMENT

Loss of information

Most of the founding team members of TGMS are no longer working in the same company or HKFSD, and the original system manual is outdated.

System complexity

This is a highly sophisticated system. However, engineers are only familiar with the parts directly related to the sub-systems they are responsible for.

Only some functions are frequently used

HKFSD has many procedures for operators to handle various emergency cases. Yet most daily circumstances only require a few common procedures and dedicated system functions.

Highly sophisticated system

Although my responsibility in 4GMS is to design, I still dedicate portions of my time to understanding how the TGMS works. The core concept of the mobilizing system is the same in both generations, and more importantly, the primary users will migrate from the current system (TGMS). By studying the TGMS, I can learn about the user’s pain points and speak their language.

As mentioned before, this mobilizing system is highly sophisticated. TGMS adopts various advanced information communications technologies in its 21 sub-systems. Everything under HKFSD regulation is included, for example, the officer duty roster, district water restriction, emergency resource deployment, etc. At the same time, I must also learn the 4GMS requirements to know what has changed. Up till the day I exited this project, I was still learning new things. Moreover, I have to keep my ears open to the hardware, network, and installation discussions, because one minor adjustment may affect the design decision.

Work with the "Superusers"

This is an internal system designed for HKFSD console operators. Unlike commerce projects, we do not need to recruit target users to conduct user research. Instead, our only potential users sit next to us, and they cannot wait to tell us what they want. They may not know anything about system design, but their experience could provide tremendous value to 4GMS, which we should pay attention to. Basically, they are part of the working team. So I called them "Superusers."

There are advantages and disadvantages to having superusers on the team. Superusers came from different HKFSD departments and could provide various aspects of information. We turned their valuable experience to use cases in advance to reduce development iteration. Yet, many of them have strong opinions on specific features that contradicted one another or violated other confirmed sub-system logics. It has cost the team valuable time to go back and forth on the same topic.

Designer is a new role in the team

The company I work for is a traditional IT solutions company. The team did not have a designer role before I joined. User-centered thinking is not at all part of the development cycle. Developers only aimed to fulfill all requirements and make the software work, so they packed everything on the screen without considering visual hierarchy and user behavior.

Designer wasn’t the only new concept for the team, and user experience was also foreign to them. As the first designer joining the team, I wanted to enhance UX awareness and establish user-centric design routines to increase UX maturity.

Only after I began working in 4GMS did I realize many different types of fire and ambulance appliances exist. Photo by HONG KONG FIRE SERVICE DEPARTMENT