Progressive Web App
B2B2C & B2B2B
Background –
This CAFM (Computer Aided Facilities Management) company had a complex technical eco-sphere. They had various systems that spoke to one another and none that were a source of truth. The particular idea the company wanted to validate was one for An App. An App that was build inhouse & captured information that otherwise customers had to go to their call-centres for.
I had fun with this client. They were a facilities management company that were technology advanced. They were data-led and had a firm understanding of staying futureproof. They had built a relationship with my employer at the time but was the first time we’d worked together.
Problem that needed to be solved –
A User-friendly application for clients that can be used to raise and monitor tickets. It needs to also fit within the existing eco-sphere and we should be able to leverage the data collated from it.
Solution –
After a lot of dicussions with the client, tech teams and Ux team we settled that we would create a Progressive web app. This would be able to satisfy the need of desktop site and the “app” feel on a mobile.
Next it was was a matter of budget. When working for an agency you pay for every person’s time by the minute. Naturally for clients they need to be financially aware of the spend so the client had a few quotes to choose from. Ultimately we went with an options to have an hybrid approach where the back-end would be done with the brainy data-scientists at another agency and we (my team and I) would work on FE. There absoutely was the need to work together because lets be honest we’ve all seen shiny websites that drive us mad when they cant perform simple functions.
So it began.
PROJECT START.
Workshop with the entire team. We needed to get to the route of problem and define what it is we were going to solve.
The workshop consisted of – Head’s of departments, CTO, Help desk leads, Team lead, engineers – the whole lot! My goal was to understand the journey of the user at the moment.
-> How are tickets logged at the moment?
-> What are the common mistakes found in tickets?
-> How long does a help desk spend on a ticket being created?
-> What is the journey of the ticket from open to close? The different statuses.
To list a few. We spent half a day delving into these type of question to form a basic “good” journey without the obstacles and then focused on the technical (integrations) in the afternoon. The app needed to speak to all the different systems and collate information to keep our users aware.
Post the workshop we had a lot of scoping discusions to talk about the details of each stage of the userjourney.
-> 6 step end to end journey can we cut that down?
-> What data points would be good for us to capture?
-> Narrow down the different statuses
-> how tickets are Raised and narrowing down the categories to make it easier for normal users.
In the end we had a detailed scoping document and a user journey that was ready to be passed on the very capable hands of our designers. I envy designers. They have such magical capabilities of making things pretty I wish I had.
SO we have discovered the problem, Defined the problem, hell we have even designed the solution, what next?
Delivery!
Well, plan for delivery anyway. By now the clients and us (the Product team) had so many calls that I was hoping the planning stage would be relatively simple… When has anything in product or consulting ever been simple!?
Remember our genius friends from earlier that were going to help build the backend? – They now made an re-appearance!
Turns out they had been smashing through their activities while we were finalisings designs and flows on our end. The system built was not quite as per the flows so we had to adapt. (Agile after all..hint hint)
Adapt we did. A week of spike from our very talented lead dev and we know had an idea on how to technically deliver this new shiny app. (There were LOADS of neogiations taking place too but this is about showing products and features and not other business skills). We had a team day for kick-off where the team dev, ux and I met. We walked and talked through the flows, what we are trying to achieve, how long we have to do so and what “good” will be in X time.
We broke down the work into epics (ergh jira term, THEMES for us normal folk). Mainly Integration and functional. We got group chats setup for open comms in between the two agencies working on the app and weekly progress calls (ofcourse) for reassuring the client. We broken the theme into little tasks.
E.g. epic – Integration
e.g. As a user I need an email and password to sign in to the app.
subtask 1 – Setup user
Subtask 2- Validate once user is setup
Sub task 3 – Error if email and password are incorrect
sub task 4 – Ability to “reset” password
All with additional authentication at each step because we live in a cirtual world and need to keep security in mind.
We did this at EVERY step of the way for our user journey. Articulating clear acceptance criterias [things that will basically satisfy us that yes it works as expected] at EACH step.
Once we had our epics and stories, the team comfortable that we could start “building” it was time to start! We planned our first sprint based on the items that the lead dev said we need to do first. Setup infrastructue for the app. So, we will start our sprints and the software delivery cycle.
Projects at this stage are usually self sufficient (if the team is right and the project is setup properly). This is when I float off the spend time with my other clients because at any given time I’m never on “one” product/project. I check in with the team if they need anything unblocked or clarity around any functionality.
We ended the project cycle with LOADS of User testing. Our client had chosen a client of their’s to trial the app with. We spent 2 whole sprints on testing and collecting feedback which will shape phase 2.
Sadly I have already left the company I work for so will not see the outcome of phase 2 but I was happy to be a part of this journey!
The adventures of a charming potato. 