
### Introduction

BHP is an Australian mining company with recognition across the globe. On an active mine site, drivers rely on radio communications to move around the site safely. There’s often some back and forth on these calls so all related calls are referred to as an interaction (or conversation if you like). These interactions must be assessed for compliance which involves manual identification, transcription and scoring in Excel.

To simplify this process, I was tasked with transforming it into an intuitive web application.

### Design Process

Prior to joining, AWS spent a good chunk of time developing a bare-bones version of the website. This allowed them to focus on getting the functionality up and running. An interesting aspect to this was the use of machine learning which meant identification and transcription could be automated. While their focus wasn’t on the user experience, this gave me a great starting point!

I began by exploring the currently system (Excel spreadsheets), and the first version of the website. It gave me a good sense of which areas could use some improvement. Based on this, plus discussions with the rest of the project team, I was able to make a detailed plan of attack for the next 6 months of design. Creating this plan not only kept me on track, but also kept the rest of the team informed about what to expect. We worked as a team to nut out the epics that all of our stories would live under, and then we each added in our tickets, along with estimates.

![](/BHP/AWS%20-%20clips.png)

![](/BHP/AWS%20-%20verify%20interaction.png)

First up was a heuristic evaluation of the website, utilising a curated list of heuristics. Some common themes for the issues found were confusing/conflicting terminology, poor error handling, cluttered UI and accessibility issues. This gave me a few key design goals to work towards.

Now the users weren’t using this new website just yet as it was still being developed, however, they had been able to have a play around with it. They’d spent enough time with it to point out what’s working for them, and what’s not. I conducted several user interviews and task-based usability testing sessions with them, one-on-one, to gather their feedback. To keep track of all of my findings, I logged everything within Confluence. I synthesised my findings and boiled it down into a summary of actionable items at the end. One of my biggest findings was that the overall process flow was unclear within the website, meaning the navigation wasn’t quite right.

I worked closely with the end users to map out what their ideal workflow is for assessing radio communications. Based on this, I was able to boil it down and determine a simplified IA (or site structure).

![](/BHP/AWS%20-%20Site%20map%20exploration.png)

From here, I was able to get stuck into the UI side of things. To streamline the process, I utilised an existing design system so I could spend more time focusing on the UX rather than low-level component building. With a few minor tweaks to things like the font and colour scheme to match their branding. Screen-by-screen, I would build a rough design in Figma, share this with the internal project team to make sure it was feasible, and then share it with the end users to get their feedback. I would iterate on these designs based on feedback until we were in a good spot.

As these designs started to wrap up, I shifted focus to testing the new designs that had been implemented within the website. Essentially, making sure what was designed matches what’s been developed, but also to make sure the design still makes sense in action. Any issues that came up were added to Jira after a quick chat with the developers.


Improve mine site safety by uplifting a key tool used to assess on-site communication.


## Introduction

In an emergency situation, a call is made to ESTA (000) and an incident is created. CFA is notified and responds as quickly as possible. After the incident, it’s important that each brigade captures what happened. That’s where the FIRS comes in.

FIRS is a desktop application that was built in the 90’s and is utilised by multiple emergency services and states across Australia to record what happened at an incident. Safe to say it was due for an overhaul.  
FIRS was redesigned to allow brigades to complete their own incident reports online—wherever and whenever they like. Solving major accessibility and usability issues, ultimately saving time, improving report visibility and data integrity.

## Design Process

During exploration, I learnt the ins and outs of the existing application by experimenting in a training database and working closely with the business analyst to understand the business rules. I then undertook a usability evaluation with the goal of identifying any issues that should be resolved in the new design.

We conducted user interviews to gain a deeper understanding of the current process, pain points and needs / wants of SDRC and brigade members. After completing the interviews, we identified various personas and created an affinity map to make sense of all the findings.

To understand the interviews in a meaningful way, we created an affinity map. This slowly revealed key themes such as personas, needs / wants, current process and pain points. Perfect!

![Affinity map {width:600}{height:300}](/images/firs/affinity-map.png)

We got some really great insight from these interviews, like most brigades would call SDRC on a Sunday, resulting in wait times over an hour, terminology didn’t match the real world, a heap of accessibility issues, poor error handling/prevention and no sense of progress. After this, I had in-depth discussions with SDRC and brigade members about the specifics of each screen before getting stuck into the UI design.

My general process was to start with a bare bones sketch, iterating until I found a few that would make the cut. Next, I brought the sketches to life in Figma, designing with a mobile-first approach. Finally I uploaded to Miro, ready for design review and developer handover.  
Here’s a sneak peak at what some of the legacy screens looked like:

![Old FIRS Reporting Screen {width:400}{height:300}](/images/firs/reporting-old.png)

![Old Callout Screen {width:400}{height:300}](/images/firs/callout-old.png)

Here’s a couple of problem areas that were addressed with the redesign:

- Removed unnecessary / harmful filters
- Simplified filters by only showing the most used and hiding all other filters in a “more filters” section to reduce clutter
- Removed unused features and information like “save filters” and replaced with accurate defaults
- Added handy features like a keyword search, help text for tricky fields, inline error validation and clear indications for required fields
- Used accordions and vertical tabs to chunk information into logical groups
- Simplified navigation by providing a clear sense of progress with a green tick and progress bar
- Revised terminology to ensure it matched the Brigade members’ expectations

Next up was a design review with SDRC to make sure they were happy with everything and if any changes were required. If all went well, then it was onto the developer handover meeting which consisted of a Miro walkthrough and discussing any technical constraints. If there were still some things that needed revision then I’d take it back to design and iterate.


Bring a legacy system into the 21st century; Empower firefighters to efficiently and independently record emergency incidents.

### Introduction

In Victoria, there’s lots of different ways to get around. Whether you’re driving to the beach, catching the train into the city, or zipping around on an electric scooter. Questions often pop up like how do I perform one of those pesky hook turns, what time does the train leave, and how do I pay for an electric scooter? Users often find themselves jumping between different platforms and organisations to find these answers.

To help address these concerns, we designed a scalable CMS-based website that brought together two major brands within the Victorian Transport industry: VicRoads and PTV. Scalability was a key focus for this piece as the aim was to integrate more brands later down the track.

### Design Process

I joined this project shortly after it began. A bespoke design system was in the works but still in its infancy. Building upon this design system was one of my main focuses on this project.

The team and I were able to design in a consistent and scalable way thanks to the atomic design methodology and usage of documentation. An interesting aspect of this was the importance of variable names and values within components. As the components would be dragged-and-dropped onto the page by content authors, these had to be in plain english. No design lingo!

Quite often changes would come up while working on the design system, whether it be from accessibility testing, changes in developer requirements or simply enhancing visual impact. Of course this was to be expected! A design system is a product that will continually evolve. We tracked these changes with the help of a change log, which was shared with the rest of the team. This kept everything crystal clear both within and between disciplines.

Once the design system was in a good spot, I switched my focus to designing reusable CMS-based templates and custom pages that would later be used by content authors. These were reviewed by the rest of the team in terms of ticket writing, development effort, user experience, etc., so it was definitely a team effort. To ensure these designs were more than just a pretty picture, I planned and conducted user tests, including tree testing and prototype testing, with the tool UX Tweak. I worked closely with the UX designers to synthesise and integrate any changes required.

Now I know I’ve made this sound like everything went smoothly, but of course, it wasn’t without its challenges! The biggest challenge for myself and the team being the scope changes along the way. This meant quickly switching focus and updating previous designs to fit the new scope (as well as going through review processes again). Granted, it wasn’t quite as bad as it sounds thanks to the component-based designs. A simple change in one place would update all instances.


Streamline the digital experience for Victorians trying to find transport information online.


## Introduction

Snowy Hydro is a NSW-based electricity company, generating power from water and snow melt to create renewable energy for over 1 million homes and businesses. One of the most important aspects for them is managing risk information and complex data sets to support critical operations and regulatory compliance. That’s where the Daily Water Balance (DWB) comes in.To help improve this process for Snowy Hydro, I was tasked with designing a desktop-only, web-based version of the DWB.

## Design Process

As hydro-electricity was a new domain for me, I wanted to get a basic understanding before jumping into designs. After a couple of chat with the SME’s (end users), and many questions later, I felt like I had it down pat (albeit, at a very high level).

Next up was unpacking the chunky 160-page requirements document. Working closely with the BA, I clarified any uncertainties and started condensing the detailed requirements into a simple UI feature list. At the same time, I was reviewing the existing application to identify any issues and understand current workings (check it out below).

![](/Old%20excel%20system%20-%20redacted.jpg)

I then began making a really bare bones structure within Figma to outline the main screens and what would be required within each.

An interesting aspect of this project was that not everything could be designed within this iteration due to budget constraints. Based on this, they requested low-fidelity, partial designs that the development team could build upon later, during the development phase. What does partial mean? Essentially, rather than catering to every requirement and designing every screen, I would design the main screens and patterns. The developers would then use these pre-existing designs to fill in the gaps.

Snowy Hydro was quite new to the software development world, having only worked on one project prior to this. Fortunately, they had a basic design system I was able to leverage. This allowed me to provide high-fidelity designs, in a low-fidelity time frame. With one key difference being the level of detail. I also set up a group chat to ensure everyone in the project, including the SME’s, had an easy way to reach out and provide feedback.

Working screen by screen, I gradually built out the required UI features. Often creating multiple variants for a given problem to provide options to the SME’s as well as development. I had regular sessions with the project team and SME’s to workshop the designs together, making sure they were comfortable with what was being proposed. I also shared designs with the broader stakeholder group to keep them informed and provide a forum for questions.

I followed a similar style to the previous web app that was developed to ensure users didn’t need to re-learn key UX patterns. In terms of the navigation, I was able to simplify this down into 3 main pages (it used to be 20+ tabs!). Within each page, I used tabs to further segment and simplify the information being shown at one time. While this was a change from the previous system, the SME’s were confident it would make it easier to use and learn. Finally, I utilised side panels to show the lowest level of detail. This provided the users with necessary context, while allowing them to see necessary information in one view.

Eventually the 6 weeks was up and it was time to bundle everything up, ready for handover. The team was very pleased with my work and asked me to continue working for another 2 weeks. In these 2 weeks, I was able to dive into some more of the detail, replacing placeholder fields with SME-verified fields for example. This helped move the designs towards a more finalised point, and reduce the effort required by development.


Modernise a legacy Excel application that’s crucial to providing millions of Australian’s with renewable energy.

Kate Raupach.

Case Studies

Get in touch

Kate Raupach.

Case Studies

BHP.

Country Fire Authority.

Department of Transport.

Snowy Hydro.

Get in touch