Streamlining Staff Travel Safety

Ensuring staff safety during international travel poses significant challenges when managing a global workforce. This case study explores how a collaborative effort transformed a cumbersome travel form process into an accessible, efficient app that reduced submission time by 50% while prioritising staff safety.

I sold the concept to the business, secured development resources and coordinated the business change.

Macbook Pro1

Overview

The Foreign, Commonwealth
& Development Office (FCDO) is the UK’s diplomatic, development and consular work worldwide, with 17,000 employees.

Keeping staff safe while they travel overseas when an incident (natural or otherwise) happens, was not an easy task. Reviewing the old methods and behaviours of staff, I made it simpler to submit travel information and make it available to the right people at the right time.

Key takeaways

  • Convinced business process owners to buy into the concept.  
  • Brought senior software management around to see the benefits of working on the app.
  • Secured 15 developers full-time for two weeks of dedicated work.
  • Integrated services were created, which had been previously de-prioritised in the backlog.
  • Time to submit a Travel Form was reduced from 15 minutes to seven.

The problem

Imagine this. You have a workforce worldwide, and you are responsible for their safety. People travel to new positions in other countries for work, visit overseas organisations or government departments, or simply take a well-earned holiday.

If an incident happens, how do you know who is where? Who do you contact first? How do you track who you contacted and what they said?

I noticed that Staff weren't filling in the forms when travelling and wondered why. Spotting issues in the process, I saw that it could be improved. I challenged the business to see how we could change the current process.

A quick note

To comply with my non-disclosure agreement, I have omitted information in this case study. All information is my own and does not necessarily reflect the office's views.

The goals

To be able to measure if I was moving in the right direction, I set out the below:

  • Increase adoption of the Travel Form.
  • Increase submissions of the Travel Form with completed and up to date personal information.
  • Decrease the time for completing the Travel Form.
  • Stop Travel Forms being sent by email.
  • Have one source of truth for the Travel Forms.
  • Work with engineers to scope out the work involved to pitch to senior leadership.
  • Pitch the concept and business case to senior leadership to replace the Travel Form.

I started with the question of "How might we make this process less complicated?".

With the upcoming products in the road map, I saw benefits to doing this work, from differing points of view. These included:

  • Enabling the data collected to be interoperable between different systems. 
  • A simplified process for Travellers.
  • A more straightforward way to manage who is visiting the Office for Overseas Office Managers. 
  • One source of truth for Duty Officers.

As this work was not requested for by the business, I knew this self-started idea would be a challenge. Mainly to change a well-established business process, though one that was not adhered to.

The idea became a commissioned piece of work and is in development.

My role

I led the app's product design. From finding process owners, stakeholders and software management buy-in. I collaborated with the Product Owner, designers in the team and software developers.

My main tasks were:

  • Stakeholder engagement and management.
  • Researching the process and user insights.
  • Pitching for two weeks of a cross cutting team of developers.
  • Collaboratively designing the app.
  • User tester with the user groups.

The process

Discovery

I coaxed some help from my colleagues in the design team to research with me. This consisted of facilitating user-centric research workshops, 1:1 interviews, analytics analysis, watching how people complete and use the Travel Forms. We considered three user groups:

Picture-1

Travellers

Staff travelling for personal or business reasons.

Picture-2

Overseas Offices Managers

Staff who see everyone coming to their country. If a Traveller is coming to the overseas office or needs visits arranged to overseas organisations, the Overseas Office Manager is responsible for organising and booking in the Traveller.

Picture-3-e1596276350210

The Duty Officers

A 24/7 staff member who ensures staff safety if an incident occurs.

Compiled with the team, there were several assets created based on the research:

  • Empathy maps.
  • Personas.
  • ‘As is’ journey maps.
  • User needs statements.

Two personas and brief journies of these personas experiences. 

Design

Drawing out the flow for the app, I asked the team for their feedback. Everyone had differing ideas of what would work best. To get to the bottom of it, we had a session to work through the flow of the app. Numerous sketches and scribbles later, we came out with how all the users could flow through the app easily.

Notes of journeys and documented versions of parts of the journey

I pushed on to do an ideation workshop with the team, doing the sketch, elaborate, and voting on the concepts. This ensured that we were designing for accessibility and usability from the start.

Sketches for mobile and desktop views.

User testing was conducted with the three user groups to ensure it would work for them. This method also has the added benefit of preventing development time from being wasted on reengineering later.

The user testing highlighted language-related issues and areas where features could be added to make the app more usable. 

This was mainly around the Overseas Office Manager view. It allows you to see a snapshot of this week's and next week's Travellers, along with who needs to have actions carried out for them.

A brief demo of the Overseas Office Managers view of Travlers upcoming journies.

The wireframes went through iterations with the product owner, which were released to the developers once signed off. A set of wireframes per user group were introduced to the development team, stepping them through and fielding their questions.

A brief demo of the adding travel to the app.

A developer handoff guide was created to bring people up to speed. This included the research, flows through the app, colours, typography, iconography and links to all the assets.

Accessibility documentation and visual style guide.

Working alongside the development team, I encouraged them to understand why a design decision had been made. Teaching accessibility and usability standards along the way.

A brief demo of the Duty Officers view of an incident.

Outcome

Overall this piece of work was a challenge, here are the highlights:

  • Assumptions and hypothesis were tested:
    • Time to submit a Travel Form was reduced from 15 minutes to seven.
    • One single source of truth was created for the Duty Officers.
  • Convinced business process owners to buy into the concept.  
  • Brought senior software management around to seeing the benefits of working on the app.
  • Secured 15 developers full time for two weeks of dedicated work.
  • Integrated services were created, which had been previously de-prioritised in the backlog.

Challenges

Commitment

I anticipated that showing there was an issue that could be solved simply, the office would work with me to do it. I hadn't anticipated doing as much selling the idea and benefits to achieve buy-in from business process owners, convincing and coaxing senior software management, to have access to developers.

Learning: To understand if there is a desire and appetite from the business, before investing time, that could have been used elsewhere.

 

Communication 

This app was not part of a formal project and didn’t have a Project Manager. It was carried out more slowly with little to no resources until securing developer time. As there were only small updates each week, I didn't want to add another email to an already overburdened inbox of the stakeholders.

Learning: Keep stakeholders involved and informed of the status and progress being made, even if they’re only small updates. Stakeholders, especially those with owning many products, need to be reminded and given regular updates.

Chris Steel | Senior Product Designer