Broadstone operates as a two sided marketplace connecting security officers with security roles. A product was needed to target security officers to build up an on demand labour pool.
The decision was made to create a mobile app, allowing security officers to control and interact with the whole Broadstone ecosystem. From applying for jobs to managing their pay.
An app had already been built to establish product-market fit, this was the next step.
Some of it was fundamentally redesigning what we already had with UX improvements. Some of it was introducing new features.
I joined the team as the first designer to improve upon an existing product that was put together for product-market fit using generic framework components. The project was both to redesign and improve the UX of the existing product and establish a look and feel to Broadstone as a brand.
I followed a Design Thinking process as best as I could given the resource and time-constraints.
We have a dedicated community team who are in regular contact with the security officers through the app and at the point of me joining, the team had built up quite a research bank of messages and notes from our users. From all this information that had been gathered and talking to our users we created user personas that would heavily guide the design decisions that were made going forward.
1. Users have different goals
Some want to pick up ad hoc work around their current employment, others are looking to be taken on permanently for the security it provides.
2. Keep it simple
Through looking at our data we could see that our user base came from a wide variety of backgrounds all around the world. Some users were comfortable with technology, others struggled. Some users were native English speakers, the majority were not. With this at the forefront of our mind it made design decisions much clearer: do we go for the subtly shaded button that hits all the design aesthetic sensibilities or the large colourful button when we want our users to perform a specific action? The answer: the simple large colourful one.
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.
"We wanted to design an app that allows security officers to find work that suits them, on their schedule, and have the whole process from applying to being paid handled through the app. We wanted to make it as easy as possible for security officers to effectively be their own boss by providing a full end-to-end solution"
At the start of every new design project I like to kick off the ideation phase by sketching ideas. My favoured approach is the good old notebook and pencil. I would take the existing designs and look at the corresponding user feedback and pain points to figure out potential ways of improving on what was currently live. I could take my notebook and pencil and sit at the side of any of the business stakeholders to get timely feedback and perform quick usability tests.
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. For this I would send a link to a Marvel Prototype to everyone to take a look at as well as showing the prototype during the weekly showcase. As we were all working around the same product, this was quite a fast and focused process with no surprises at the point of handing over to engineering.
As well as testing on internal stakeholders I would also perform usability tests on anyone from our active users, to people walking around the shared office building, to the reception security staff of our building!
These could be new features, improvements, or just concepts.
Based on the feedback I could then iterate on new designs and work alongside engineering to make tweaks on existing designs for the next release.
One concept that was tested was an "Instant Pay" feature which was a section in the app that allowed users to withdraw their pay instantly into their bank account instead of having to wait until the end of the month. There were complexities around displaying the fees that were taken, maintaining multiple account balances, and drawdown limits to handle things like taxes. After going through the ideation -> prototype -> guerrilla usability testing process we landed on a feature that was built out in around ~3 weeks and now gets used by 50% of our user base which equates to around ~£150,000 in withdrawals each month. It has been spun off into a standalone product called Orka Pay
We hit the project goals of creating an app that was simple for security officers to use, allowing them to interact with the whole Broadstone ecosystem. From applying for jobs to managing their pay and a few great additional features along the way. We have around 40,000 security officers using the app and over 4/5 star rating on the App Store. We have also recently opened it up to the cleaning sector so are expecting a surge in our user base!
With lots of new products introduced into the product roadmap and competing priorities it has been difficult to analyse the data and continually iterate on what we have built. Although we have grown as a team the number of products has also grown dramatically which has put a strain on resources.
I would have liked to have continued working on the product and have the resources available for us to properly measure and iterate on everything we release through a combination of quantitative and qualitative data. We send out regular surveys and have UXCam set up in the app to allow us to record user sessions and capture quantitative data. As a fast growing startup who are not yet structured into product teams this has proven challenging.