Enterprise Web App
A internal web-based system to manage operations and accounts.
What’s the Enterprise Web App all about?
It is a comprehensive web-based application to manage all areas of Homage’s caregiving operations:
create and update accounts for individual users and organisations
schedule, cancel, update visits
match and assign suitable caregivers to visits in the right priority
monitor incidents and caregiver deployment levels in real-time
publish reports and advisories
view, filter, export data in tables for more detailed analysis
Who is the user?
The primary user of the web app is the internal Operations team, which looks after all aspects of the on-ground visits taking place every day.
As the startup grew, other business units also used the internal app:
In-house Nurse Specialists
Care Professional Operations (handling caregiver recruitment and engagement)
Sales and Customer Service
Finance
Marketing
Product & Engineering
My Role
The enterprise web app was bare bones when I joined Homage, basically a handful of data tables but no functionality to create or update events. From then on, my role was to ship new features to Smiley Admin pretty much every month to support the backend operations of features that we were releasing for the mobile apps.
My first milestone on the web app was to ship and design a flow to create care recipient profiles, and schedule a home assessment for them. Thereafter, I worked on all manner of projects including adding new flows to create visits, assign a caregiver to a visit, approve visit reports… the list goes on. Also, countless data tables!
Similar to the reporting line for the Homage and Care Professional mobile apps, I worked directly with the CEO and subsequently CPO.
Initially, the team handling the enterprise tool numbered 3 backend engineers and eventually grew to 5.
Takeaways & Learnings
I loved working on the Enterprise web app! While it was awesome to work on B2C mobile features for families and caregivers, I really enjoyed the challenge of working on a totally different form factor (desktop web), and the satisfaction of solving different business needs with each feature I designed and shipped.
I made lot of friends in the process. I learned so much about other business units, their function within the company, their challenges and goals, and it was deeply satisfying to be able to solve some of their problems together with my own team.
Learning #1 : Change Management is crucial
Building new product features for the internal system often meant defining new workflows. This was because the product was aimed at improving the business, and not merely duplicating what was happening offline.
For example, new product features would sometimes add steps or require more information to be collected for the sake of business intelligence insights and long-term growth. This could have seemed like extra work to the Operations team had it not been handled well.
Due to the process changes, change management was a critical part of product launches and the efforts began early on, way before any code was written.
The goal was to share an understanding about how the product should work for growth and also to get buy-in from the Operations team.
Essentially, it boils down to communication (the more, the merrier!) and establishing a shared goal.
During initial requirements gathering, I would have a deep dive with the Operations team lead about the goal for the feature, listen to her inputs.
In the design phase, I would incorporate her inputs while synthesise other requirements coming from elsewhere. Wherever possible I would check in with the Operations lead and run through the final design with her before getting my CEO or CPO’s approval.
Once the feature was in build, I would run a training session for the internal Operations team and recap the background and context. I would share the reasons behind certain decisions to be as transparent and open.
It was also key for the Operations lead to “back me up” and sell the changes to her own team. While Product was leading the charge, so to speak, her support was crucial in making sure the features were actually adopted and useful to the business.
Finally after the feature was launched, I would check in with the team members and get their feedback, observe how they were using the new feature. I would note any improvements that we could make on the Product & Engineering side.
Takeaway #2: Adopt a design system as early as possible
As the enterprise web app is an internal tool, our approach was geared toward speed rather than beauty. When we built new features, we tended to go with whatever worked for that particular use case or scenario.
This still makes sense to a certain extent, but in hindsight, I would probably enforce more discipline on sticking to a design system simplify the engineering effort by potentially reusing components. Not to mention, to avoid unnecessary variations and reduce decision fatigue on the part of the design team.
Since the enterprise web app was an internal tool, even within the Product & Engineering team we had an attitude of ‘it’s okay if it’s not beautiful’. Looking back, I think if the system was more consistent, it would have been even easier to ‘sell’ to our internal users during change management and transitions!
Takeaway #3: Make the most of proximity to users
Since the users were all internal (e.g. the Operations team sitting across the room from me) I really enjoyed the ability to just walk over and do impromptu user testing and research. The feedback loop was quick and direct. It was a great opportunity to listen and learn more about the rest of the company and their respective work areas which we were trying to improve.