Orka Works Client Platform
👨‍💼

Orka Works Client Platform

Problem Statement:

Broadstone operates as a two sided marketplace connecting security officers with security roles. A product was needed to allow security companies to easily post and fill shifts to provide our security officers with a high volume of job opportunities.

We decided on a client portal, allowing security companies to post and interact with the whole Broadstone ecosystem. From posting shifts, to choosing which applicants to schedule in, to handling timesheets and invoices.

A web based portal had already been built that our internal community team was already using to post jobs and schedule applicants, this was the next step.

Scope and Constraints

The company had a 3 person product team:

👨‍💻
‍Front-end Engineer x1
👨‍💻
Back-end Engineer x2

Since building the app the product team has grown to a 13 person team made up predominately of engineers plus an additional designer I recruited for my team.

Various team members would work on the app depending on where priorities sat in the product roadmap. On reflection this has been the biggest constraint.

Process

For this project I worked alongside our community team who had been the power users of the platform up to now, to overhaul the UX, the design and introduce new features.

I followed a Design Thinking process as best as I could given the resource and time-constraints. As we know, design is messy, and I would often jump in and out of different parts of the process that I believed I needed to spend more time on and revisit. A circular approach rather than a linear one.

image

A circular design thinking approach

The method of research chosen was to conduct user interviews and contextual inquiries on the community team as they were the ones receiving the client requests and doing the posting and scheduling on their behalf. I would have liked to have involved the clients more at this stage but at the time had barriers with client relationships. The community team were doing the work that ideally our clients would have been doing themselves, this provided much research material as we could see how our clients received requests to provide security officers and how they would decide which officers to schedule in.

As the community team regularly on-boarded new clients and received emails we would have weekly meetings to go through all the feedback gathered during that week and make improvements to the product.

Where possible I also conducted user testing with our clients. Below is an example of me conducting remote user interviews and usability tests with a Contract Manager for one of our clients, who eventually ended up joining our team.

User Interview and Usability Testing on a Contract Manager
User Interview and Usability Testing on a Contract Manager

Conducting Contextual Inquiry on our own Community Team
Conducting Contextual Inquiry on our own Community Team

Notes taken during User Interview sessions
Notes taken during User Interview sessions

Using Affinity Mapping to organise the feedback
Using Affinity Mapping to organise the feedback

Define

The next step was to define what we are trying to achieve. As the business is a two-sided marketplace, we had to take a step back and look at the whole picture. We focused on both parties goals as well as their pain points.

Group "How Might We" workshop
Group "How Might We" workshop

What was we trying to solve? What were the pain points?
What was we trying to solve? What were the pain points?

"We wanted to design a new client portal that reduces the work load of our clients. The challenge was to streamline the entire process from the speed of posting a shift, to choosing how to schedule officers, to approving timesheets and settling invoices. The clients current process was to juggle various spreadsheets and call poor quality agencies to fill last minute vacancies. We wanted to make it as easy as possible for clients to fill shifts by providing a full end-to-end solution"

Ideate

Before diving into Figma, I would first create a variety of ideas through low fidelity sketching using a trusty notepad and pencil. This is my favoured method of ideating, as the speed makes it easier to quickly iterate based on feedback and not get too attached to one idea. I would take the chosen idea to a higher fidelity design and create a prototype of the flow. This would then be shared across the business for feedback and to conduct usability tests. Where possible I would conduct user testing on our clients. Friends and family would also get cornered for some on the spot testing too! One thing I wish I did in hindsight was to document all the findings in a central place, as I was the only designer, the majority of the findings lived in my notebooks. This would have made on-boarding future designers much easier and increased the collective business intelligence.

UI Design

I designed the company platform as clean and light as possible so that the information they really cared about could stand out. With lots of moving parts and complex screens like the schedular and shift manager, it could soon get noisy on a page and lead to elements competing for attention. The designs tried to avoid this from happening. If I could spend more time on it now I would simplify certain screens and focus on how we can best alert companies about things that need their attention across the platform. I would also have liked to have spent more time implementing the design system so learned behaviours could be repeated across the platform.

image
image
image
image
image

One of the user flows created when we were opening up into a new sector

Prototype

After the concepts passed the ideation phase I would turn it into a prototype which would highlight any areas I overlooked and help me spot any potential issues sooner. Taking this prototype I could then repeat what I did in the ideation phase, getting as many stakeholders as possible to test the prototype themselves and provide feedback.

Example of prototyping the "Post a Shift Pattern" feature which was shared with various stakeholders

Outcomes

Since making the changes to the client platform the total number of shifts posted has grown from around 8,827 hours to around 215,000 hours with 14,000 shifts completed. The average number of shifts posted per day sits at 200 with an average of 1000 applications per day. We have a fulfilment rate of 93%, meaning of all the shifts posted on the platform, 93% get filled. The number of shifts posted effectively doubled from an average of 1600 hours a month to 4040 hours the next month to 7322 the following month. Of course these numbers don't tell the whole story as there were many great efforts happening around the business at the same time. We also now work with some of the biggest names in the security industry such as G4S.

One of the main learning from this was how our typical user has changed and how we have had to adapt to handle large volumes of information. At the start we was working with smaller businesses that typically had one staff member responsible for all areas on the platform, now we are working with much larger clients each new staff member we onboard onto the platform has their own "view of the world" and wants to be able to filter the information they see accordingly. How we chose to display a list of active job sites worked perfectly for the smaller clients who who only had to manage 20 or so job sites, things had to change when clients now had to manage 100's of job sites.

At the same time the number of jobs posted was increasing, so was the corresponding applications from our users on the Worker App. Our current challenge is how to distill thousands of applications on a single job posting to only show the client the most suitable applicants and avoiding information overload and the paradox of choice. To achieve this we have started building out a rating system based on the performance and other data points captured on our workers.

Discussing the rating system with our Data Scientist
Discussing the rating system with our Data Scientist

I would have liked to have stayed with the product for longer and been able to focus on reviewing qualitative and quantitative data that would have allowed us to keep iterating on the product. Competing business priorities and lack of resources made it difficult to do this and follow a true "Lean UX" approach.

image

From 2019-2 is when the Client Portal updates started rolling out

image

KPIs emails were automated daily. There's a lot more to these dashboard and reports but unfortunately cannot share as it contains sensitive data.

image
User session recording captured in Hotjar
User session recording captured in Hotjar