Internal tools — things we’ve learned from building software just for us
As Farewill grows, so does the importance of our internal tooling — the software unseen by customers that helps power our services. We build much of it ourselves, and we take a great deal of care over it.
Why do we build internal tooling?
Our decision to build our operational software was very carefully considered and well researched. It’s now a key part of our product strategy. Why and how we took that view deserves its own blog post! One way to sum it up is that it gives us a level of control over both the experience of our operational teams, and by extension our customers, that we felt we couldn’t achieve by buying off-the-shelf.
Here are a few things we’ve learned, and the impact it has on life at Farewill.
1 . Treat internal users like customers
We design Backstage (the name we give to the tools we build) with the same care as we would any part of our customer-facing product.
That means adhering to our usual high standards of content design, usability and clarity. For example:
- The words we use in our internal tools are consistent with our customer-facing products (e.g. ‘the person who died’ rather than ‘the deceased’)
- We write plainly, but also appropriately for the context (for the parts of the system used solely by legal specialists, it’s ok to use some jargon)
- We use the same components as our customer-facing products (typography, buttons, errors, labels etc)
Our aim is to give new starters a shallow learning curve, and everyone a delightfully fast and accurate experience.
2. Nurture short feedback loops
A short feedback loop means learning and improving things quickly. That’s one of the joys of building Backstage.
Our users are no more than a desk or two away — or in these more complicated times, a Zoom call. Like a driving test, we know almost instantly if we’ve ‘passed’ or ‘failed’ and what to improve on next time.
These loops don’t happen without effort, so we nurture them:
- Users are involved in projects from the start — almost all our probate operations and legal team participated in a recent kick-off, for example
- We run projects openly— written and verbal project updates, one-to-one chats, observation sessions, open design processes, etc
- In probate, a member of our operations team has a specific part of her role dedicated to joining up with the product team — she helps give feedback and produce training materials, among other things
- Similarly, our lead probate solicitor is part of our product team and joins us for rituals and feedback sessions
- Thankfully our users are incredibly engaged with the process and generous with their time and thoughts — we couldn’t do it without them!
These feedback loops are not only beneficial for product outcomes, but also for the wider Farewill team. The Ops team tells us it’s fun to be involved in the product side of a startup, and they’re grateful when their feedback leads directly to outcomes which make their jobs easier.
As our cremation ops team member Catrin said after a recent project:
We can now add three or four new customers in the time it took to add a single customer, the form generation saves hours every day!
3. Relish the wonderfully thorny design challenge
As designers at Farewill we tackle a variety of juicy problems, from conversion rates on a sign-up form to helping customers customise a funeral. I love the challenges that come with internal tooling, including:
- Domain knowledge —getting deeply embedded in a subject (in our case, the legal and operational side of death)
- Operational knowledge — getting to know how the company works and adapting when processes change
- Service design — helping identify, unpick and improve the way the different elements of our services join up
- Usability — making complex tasks quick to complete, even for new starters
Not only is it a fun and challenging area to be involved in, it’s deeply rewarding to be simplifying things for our teammates and indirectly improving customer experience.
4. Understand the ‘why’
There’s an adage in product design that ‘users don’t know what they want’.
I prefer to say that we don’t expect users to be product designers. It’s not their job to think about consistency, usability, scalability or feasibility. So we try not to take all ideas at face value — we dig beneath the ‘what’ and get stuck in to the ‘why’.
That’s particularly true of internal tools. They can be addressing hugely complex processes, and our users are often subject matter experts. They may have years of ideas and expectations from previous jobs.
But we don’t want simply to replicate what’s come before.
So as a product team we try to get to the nub of the problems and work up from there. We do that in a bunch of ways such as observing users, asking a lot of ‘why’ questions, and using wireframes to test and iterate on ideas.
An example
Our probate team had different ways to mark a case as needing attention — placing a card in a certain column, using labels, leaving comments and tagging teammates. We didn’t want to blindly replicate this behaviour in our own tools, so we tried to understand the problems that the team needed solving.
We ended up achieving the same outcome in a simpler way, with a ‘Priority case’ toggle and more powerful filters to hone in on difficult cases.
After all the care and effort, it’s wonderful to get feedback like this from an ops team member:
What you’ve done is amazing. The burden has been lifted!
A few failures
If it sounds like we’ve got this nailed, we haven’t. Alongside many successes, we’ve launched features that have flopped. For a feature about logging particular complexities with a case, we rushed into it because we thought we knew the answers, but we hadn’t made the most of those wonderfully short feedback loops I mentioned earlier. It turned out we’d got it wrong. We’re still learning!
Final thoughts
- We regularly bring in-progress designs for Backstage to our design crit
- We need to get better at making Backstage more accessible — for example, I worry that we’d struggle to accommodate visually impaired team members
- Our internal team all use large screens, so we don’t need to design Backstage to be responsive (thank goodness — that’s a daunting prospect!)
- Measuring the success of projects for internal tools can be difficult, but it’s doable — something for another blog post
Join the team!
Keep a look out for product jobs at Farewill and help us build our internal tools. Or become a sales, ops or legal team member and enjoy using them! Current openings are on our careers page.
