Strategy can be an overused word. Too often it becomes shorthand for long documents, ambitious roadmaps, or lists of initiatives that sound impressive but lack real focus.

At FreeAgent, we take a different approach.

Our strategy is designed to be clear, coherent, and actionable from company level, through departments, and right down to individual teams. To do this, we use the framework from Richard Rumelt’s Good Strategy/Bad Strategy, which gives us a shared language for what good strategy actually looks like.

As we close out the year having completed our team strategy reviews, it’s been genuinely inspiring to see just how aligned and focused each team is on the impact they want to make and how clearly that impact connects back to our overarching company strategy.

This post explains how we do it.

What good strategy really is

One of Rumelt’s most important insights is that strategy is not a vision, a goal, or a plan.

Good strategy has a clear foundation, made up of three essential components:

1. Diagnosis — a clear, honest understanding of the challenge we are facing.
2. Guiding Policy — the approach we choose to address that challenge.
3. Coherent Actions — a coordinated set of actions that bring the policy to life.

We use this framework as a quick gut check. If it doesn’t fit the three parts, or the story doesn’t quite add up, then it’s not really strategy.

This shared understanding allows us to move away from vague aspirations and towards deliberate, focused choices.

Company strategy: setting direction with clarity

At company level, strategy begins with a shared diagnosis of our environment:

• What’s changing in the market?
• Where are customers struggling most?
• What opportunities and constraints do we face as a business?

From this diagnosis, leadership defines a small number of guiding policies as the strategic choices that focus the organisation. These policies are intentionally opinionated. They clarify where we will invest, what we will prioritise, and just as importantly, what we will not do.

Only then do we define coherent actions, the outcomes and initiatives that move the business forward in a joined up way.

This company strategy becomes the anchor point for every department and team.

Department strategy: translating direction into focus

Each department then creates its strategy by asking a critical question:

“Given the company’s strategy, what is the most important challenge we must solve to contribute meaningfully to it?”

Departments don’t restate the company strategy. Instead, they interpret it through their own lens, creating:

• a department-specific diagnosis
• a clear guiding policy that explains how they will support the company direction
• a small number of coherent actions that teams can align behind

This ensures departments aren’t operating in silos or running parallel strategies. Instead, each department plays a clearly defined role in delivering the overall company strategy.

Strategy as an enabler of empowered, purpose-driven teams

One of the reasons we use Rumelt’s framework so deliberately is that it doesn’t just create alignment, it enables empowerment.

Clear strategy creates freedom, not constraint.

By being explicit about the diagnosis and guiding policy at company and department level, we give teams clarity on:

• the problem that really matters
• why it matters now
• the strategic choices that have already been made

This clarity allows teams to focus their energy on how best to create impact, rather than second guessing direction or optimising for local priorities that don’t move the business forward.

Teams are not handed a fixed list of solutions. Instead, they are trusted to:

• define the most meaningful challenge within their remit
• make informed trade-offs
• choose the right actions to deliver outcomes

This is what we mean by purpose-driven teams. Teams don’t just know what they’re working on, they understand why their work exists and how it contributes to FreeAgent’s wider mission. Each team will demonstrate this by answering five questions as they build their strategy card.

Team strategy: turning strategy into real impact

Team strategy is where strategy becomes tangible.

Each team creates its strategy by clearly connecting three things:

1. The company strategy.
2. The department strategy.
3. The specific impact the team exists to make.

Teams define their own diagnosis, identifying the most important problem they need to solve and articulating a guiding policy that explains how they will approach it. Their coherent actions then become the outcomes, bets, and priorities that guide their work.

This approach gives teams:

• clear ownership of impact
• autonomy in how they deliver
• confidence that their work matters beyond their immediate backlog

Autonomy with alignment

Empowerment without alignment leads to fragmentation. Alignment without empowerment leads to disengagement.

Using a shared strategic framework allows us to balance both.

Because every team strategy clearly connects back to the company diagnosis and guiding policies, teams have autonomy within clear boundaries. They can adapt, experiment and respond to learning, while staying aligned to the broader direction of travel.

The result is teams that are more engaged, more accountable and more confident in the impact they’re driving.

Reflecting on our team strategy reviews

As we close the year, we’ve completed our team strategy reviews — and the results have been genuinely energising.

Across FreeAgent, teams are:

• sharply focused on the problems that matter most
• clear on how their work contributes to company goals
• making deliberate trade-offs rather than trying to do everything
• using a shared strategic language that enables better conversations

The alignment we’re seeing isn’t accidental. It’s the result of consistently applying a clear framework and giving teams the space and trust to think strategically and not just execute.

Why alignment matters

Alignment isn’t about control. It’s about coherence.

When company, department, and team strategies are aligned:

• decisions are faster and more confident
• trade-offs are easier to make
• teams understand why their work matters
• the organisation moves forward together, not in fragments

Good strategy doesn’t eliminate complexity but it gives people clarity within it.

As we head into the next year, this alignment gives us confidence that FreeAgent is not just busy, but purposefully focused on delivering meaningful impact for our customers and the business.

Inspired by Richard Rumelt’s Good Strategy/Bad Strategy and brought to life by the incredible teams at FreeAgent — Angela Fleming, VP Product

Wings and things
FreeAgent has three internal teams that employees can join. Fungineers live the company value of “enjoy it”, FreeAngels volunteer and help others by leading charity initiatives and organising volunteering opportunities, and GreenAngels make the world greener. They each had a logo — but that was in years-old FreeAgent branding and didn’t really reflect the teams.

I got to work on exploring options to refresh these identities — the kind of project where you’re balancing brand consistency with letting different teams express their own personality.

The brief was to refresh some long-standing internal team identities and bring them more in line with the external brand. After a lot of design concepts (and I mean A LOT), I discovered something: if you take the FreeAgent wing, rotate and mirror it, you can create some genuinely interesting shapes.

From there, the icons practically designed themselves. Working within FreeAgent’s existing colour palette meant looking at which colours worked best with each concept rather than starting from scratch.

I brought a few colour options to a crit (a group feedback session where designers review and discuss work), where I got to walk the Design team through my thinking. Hearing their perspectives not only helped me sense-check my design decisions, but also gave me a better understanding of how people respond to colour emotionally. In the end, we landed on the right direction — and I got a better sense of how to balance instinct with input.

Then came the fun part: rolling it out. Stickers, presentation templates and some foolproof brand guidelines that even the most design-averse team member could follow.

Campaign time
I’d never really worked on campaigns before. Most of my experience has been with branding and design itself. There are a lot of crossovers, but also a lot to learn.

I joined early concept sessions to help shape ideas that were smart, funny, and flexible enough to stretch across different formats. We explored tone, came up with headlines, and stress-tested them to see if they really said what we meant. There were whiteboards. There were slides. Some ideas got a bit ridiculous.

The real challenge wasn’t generating ideas — it was making sure those ideas worked hard, without working too hard. Simple enough to read in a second. Strong enough to carry a message. And not too clever for their own good.

Each concept had merit, each could work. But picking which direction to go in wasn’t down to me — and that’s just how the process works. My job was to help shape the options, not make the final call.

To HMRC with love
I’ll be the first to admit that I am not much of an illustrator. I can convey a concept, but that’s about it. So when I got a brief through to create an illustration, I panicked. Fortunately, my task was to come up with the concept and then brief a freelance illustrator. Phew.

The illustration was for a guide titled “What do I have to report and pay to HMRC and when?” We wanted the audience to feel confident in understanding the timeline around payroll — therefore trusting FreeAgent to break down barriers for them and make payroll easier.

The process of prepping for HMRC is pretty complicated (shocker), there are things you have to do monthly, others that you do yearly. But our customers don’t have to worry so much about that, as the software handles the bulk of the stress.

My first concept was elaborate: a conveyor belt system where the customer inputs data and various machines automatically process everything along the way. Smart metaphor, clear process, totally overcomplicated.

Round two: one machine instead of five. Customer inputs data, everything comes out ready. Still too complex.

Back to the brief. I ran through rapid concept generation — designers call it “crazy eights”, sketching eight ideas in eight minutes to push past the obvious ones, though mine turned into “anxious twenty-fours” — until I hit the right idea: a beautifully wrapped present with a bow and a gift tag reading “To HMRC with love.”

Simple. Funny. Very FreeAgent.

The team loved the concept. Nailed it!

I sketched it out, wrote a brief for the illustrator, and after a few rounds of revisions, we had our hero image. A cheeky, lighthearted way to show just how easy HMRC submissions could be with FreeAgent, which fits the guide perfectly.

Top 5 things I learned:

1. Sometimes the best solutions hide in plain sight.
2. Good campaigns start with a real problem, not a creative brief.
3. When in doubt, make stickers — people love stickers.
4. The most obvious joke might be the best one.
5. You might not get it right the first time (or second), but you will get there.

Reflection
Before this internship, most of my design work lived in uni projects or agency work. So jumping into an in-house team for the first time was a bit of a learning curve. I’ve learned how to get to the point quicker, how to simplify my ideas, and discovered that your first idea is rarely your best — and that’s a good thing.

Finn McEwan is a design intern at FreeAgent, the UK online accounting software for small business owners and their accountants and bookkeepers.

At FreeAgent, beta testing is more than a final checklist item. It’s a way of building with our customers, not just for them.

As a product manager working on features for accountancy practices, I’ve seen how powerful a well-run beta can be. It’s not just about spotting bugs or measuring performance. It’s about learning whether what we’ve built actually works in context; in the messy, real-world workflows of accountants doing their jobs.

In this blog, I’ll walk through how we run beta tests at FreeAgent, using the launch of our new Management Reports feature as a case study. Whether you’re in product, design, engineering, or accountancy, we hope this case study will demonstrate to you how we use early releases to shape stronger launches.

Why we run betas

No amount of internal testing can fully replicate what happens when real users interact with a new feature.

People use software in ways you don’t expect. They overlook the things you thought were obvious and focus on things you didn’t prioritise. Beta testing gives us a crucial opportunity to observe this; to catch gaps, understand friction points, and confirm whether the problem we set out to solve is actually being solved.

Beta tests aren’t just about validation; they’re about adaptation. Done well, they shape what we release, when we release it, and how we improve it afterward.

Our beta testing process at FreeAgent

Beta testing at FreeAgent follows the same six-step process we use for any structured research. These steps ensure we’re clear on what we’re testing, why we’re testing it, and how we’ll use the feedback.

We also work closely with our dedicated user research team, who support the beta test with everything from planning and recruitment to feedback analysis.

1. Define the problem

Before we start a beta, we clearly articulate what we want to learn. In the case of Management Reports, we wanted to know whether the Minimum Viable Product (MVP) we’d built met the core needs of accountants preparing client reports, as well as what was missing.

We also set outcome-oriented goals. For example, we aimed for at least 70% of testers to say they could see themselves using the new functionality in their regular workflow.

2. Select the approach

Betas can be open or closed, public or private. We usually run closed betas for new product features, especially when we’re seeking focused feedback from a particular user group.

For Management Reports, we invited a small number of accountancy practices that varied in size, structure, and use of client reporting tools. This gave us a rich mix of perspectives without overwhelming our team.

We also timed the beta to coincide with a period where year-end or quarterly reviews would naturally occur, ensuring the feature was tested in real workflows.

3. Prepare thoroughly

Good betas start long before the first participant gets their hands on the feature. We spent time getting clear on:

• What functionality was in scope for the MVP
• How we would onboard participants
• What research questions we needed to answer
• What feedback methods we would use

We created an onboarding guide, FAQs and a feedback survey. Internally, we made sure that Support, Sales, and Engineering teams knew who was in the beta, what was being tested, and how to help if issues arose.

4. Collect feedback from multiple sources

During the beta, we collected both quantitative and qualitative feedback.

For Management Reports, this included:

• A structured survey with a Likert scale and open-ended questions
• In-product usage tracking
• One-to-one exit interviews with participants after release

This mix helped us validate usability, capture first impressions, and explore what participants valued or found frustrating. For example, we discovered that while many practices liked the overall direction of the feature, they had different expectations about how certain elements (like notes or exports) should work in context.

5. Analyse and prioritise

We then worked with the User Research team to analyse what we’d heard and seen. We looked for recurring themes, strong opinions, usability blockers, and unexpected behaviours.

In the case of Management Reports, feedback helped us:

• Prioritise features like a spreadsheet export and per-report Notes
• Identify usability issues with the current Notes placement
• Understand different views on visualisation tools
• Spot gaps in the way we framed the MVP’s limitations

Rather than treating the feedback as a long wishlist, we aligned it with our roadmap and objectives, then focused on what would add the most value in the short and medium term.

6. Share findings and close the loop

Beta testing is a team sport. Once the data is in, we make sure to share key insights across product, design, engineering, and customer-facing teams. This keeps everyone aligned and builds a shared understanding of user needs.

We also follow up with participants to thank them, let them know what we’ve acted on, and continue the conversation. For us, a beta is often the beginning of an ongoing feedback loop and not a one-time event. Building this kind of relationship helps us stay closely attuned to evolving customer needs and often turns early testers into long-term champions of the product.

A few lessons from the Management Reports beta

Although every beta is different, here are a few takeaways we’ll carry forward:

Framing matters. A couple of participants described the MVP as basic; not because it didn’t meet their needs, but because it didn’t do everything they’d hoped it might. It was a reminder that even in a closed beta, we need to set expectations clearly. If development will continue post-launch, we need to say that explicitly.

Small samples can deliver big insight. Our beta group for Management Reports was fewer than a dozen practices, but their feedback helped shape the next six to 12 months of development. You don’t always need large numbers to find clear patterns.

Feedback is only useful if you act on it. Running a beta creates an implicit promise: that you’re listening. We made sure to follow through by prioritising the most common requests and improving weaker areas of the MVP quickly after launch.

Final thoughts

Running a beta test takes time. It requires cross-team coordination, thoughtful planning, and willingness to hear things you might not like. But for us, the return is always worth the effort.

Betas help us validate product decisions, uncover unexpected friction, and build with real confidence. More importantly, they help us stay connected to the people we’re building for.

A beta test isn’t just a box to tick; it’s a vital stage in product development that helps ensure you’re building something meaningful, useful, and grounded in the realities of the people you’re building for.

Stu McEwan is a Staff Product Manager at FreeAgent, the UK online accounting software for small business owners and their accountants and bookkeepers.

Firstly, what is Product Operations?

The discipline of Product Operations is currently trending in Product Management, and is already adopted by companies like Google, Amazon, Uber and Open AI.

But what is Product Operations? Melissa Perri and Denise Tilles (who became the unofficial Queens of Product Ops after publishing the first book on the topic) describe it as follows:

“Product Operations surrounds the team with all essential inputs to set strategy, prioritise and streamline ways of working.”

In short, Product Ops aims to be a force multiplier for Product Managers. We focus on improving data-driven decision making and enhancing ways of working to help Product Managers ship more of what our customers love.

In other words, Product Ops is to Product Managers what DevOps is to Software Engineers. More on what we do shortly, but before that…

Why did we create a Product Ops team at FreeAgent?

FreeAgent already had a strong Product Management function made up of world-class Product Managers regularly shipping great product. But as with most teams, we have many more ideas than we have capacity to build. This means, to create the best product possible, we need to be extremely efficient when deciding what to build, and extremely efficient when building it.

Just before we created the Product Ops team at FreeAgent, we had four Business Analysts who were supporting our eight Product Managers in getting product to market. They would rotate round Product Managers as and when needed. Over time however, the Business Analysts had started acting as extra capacity for Product Managers; they would do bits of work the Product Managers didn’t have time to do; such as writing up requirements and specifications.

This was hugely valuable work, but one day our VP Product, Angela Fleming, took a step back and asked this key question:

“Instead of providing individual Product Managers with overflow capacity on an ad hoc basis, why don’t we focus more on the systems and ways of working that could save all Product Managers time?”

When assessing it, we found there were many things that could be made more efficient to free up Product Manager time including reducing the time taken to:

• access and draw insights from data (for roadmap decision-making)
• report outwards and upwards about roadmaps and results
• prioritise backlogs
• generate innovative new ideas

By improving underlying systems, tools and ways of working, we could help all the PMs ship more product, at scale, and on an ongoing basis.

The plan was that we would redirect Product Manager capacity from doing everything Product Manager-related:

To a world where Product Managers focused on what they do best (deciding what to build, getting it built and evaluating whether it worked) and Product Ops help them do more of it.

So, our VP Product made the call and we changed from this structure:

To this new structure, where we had a dedicated Product Ops team supporting Product Management and Product Leadership:

What we’re trying to achieve

At FreeAgent, the Product Ops Team mission is to:

Enable the Product function to make good decisions and deliver what our customers want at pace

What does this mean?

It means we aim to add value in the following two ways:

1. Helping Product teams quickly find the biggest opportunities by surrounding them with essential data for decision making

In FreeAgent we have many sources of raw and processed data from online analytics to support feedback, to user research (see image below). Product Ops aims to take this data and increase its usability and meaning, as well as analysing the data to increase the opportunity space (i.e. find new ideas).

For example, we currently have several Product teams working on our Payments offering. The teams often pull from different data sources for the reporting (depending on what part of the product they are working on). How can we make sure all those data sources are aligned and accurate, such that all teams are telling a consistent story to the business?

As another example, the world is rapidly changing as a result of generative AI. How can we use the latest AI technology developments to help our customers achieve their jobs to be done? Product Ops would do market analysis here and make recommendations to PMs.

2. Improving the Product Operating model

The second way Product Ops adds value at FreeAgent is by reducing friction across planning, reporting and the product life cycle, so Product teams can move quickly in delivering product our customers love.

For example, there can be duplication between reports that Product Managers create for different stakeholders. How could we streamline reporting so Product Managers save time by creating a report only once, but with automated, differing levels of fidelity for different stakeholders?

We try to help other departments too, like Marketing and Sales. How can we make sure those departments are constantly aware of product releases and plans, so they can talk to customers about them?

Another example is that it currently takes Product Managers several hours to pull together the monthly KPI report for their team. How could we automate this so it takes minutes instead of hours?

What’s next for Product Operations at FreeAgent?

It’s still early days but there is a huge opportunity for us to help our Product Managers at FreeAgent. Watch this space for more updates and case studies as our Product Operations team gets down to business!

Last but not least, a shout out to the FreeAgent Product Operations Analysts actually doing all this work; Jack Easton, Kirsten Zammit, Oluchi Abazie and Hammed Akinyemi.

Thanks for reading, I hope you found it useful.

Lucy Pitticas-Rothwell is Head of Product Operations at FreeAgent, the UK online accounting software for small business owners and their accountants and bookkeepers.

The ‘World Wide Web’ had just been invented. I got my first ever email address in first year. We used a way of connecting devices called ‘telnet’ to speak to students in other universities. It was an exciting time. But, I just felt like I didn’t quite fit in.

When I graduated, I got an IT graduate position working in London. As an IT graduate, we worked in lots of different areas of the business. Working in support was my first love. Helping people to get things working on their computers gave me a bit of a thrill. At the end of the graduate program, I was promoted to lead the email team at the age of 26.

Throughout my time at this job, I never really needed to do any coding. So, my coding skills disappeared pretty quickly.

Very long story short, I ended up going to Australia on a one-year working visa and retrained as an accountant. After 15 years, I moved back to Scotland, with my husband and two small kids in tow. I’d always hankered after working back in tech in some form or another. FreeAgent accounting software, which is based in Edinburgh, sounded like the perfect fit. I gained a position in the support team and loved helping people to use FreeAgent to look after their business’s finances and taxes. Yet I always yearned to work more on the IT side of the firm. A position as a business analyst fitted the bill. Still working in FreeAgent, but working on longer-term projects and building new features with a team of great people.

Again, I felt like I wanted to do more technical work, but my skills were so outdated. It felt like an impossible task. Some external companies ran coding courses, but they were all huge commitments, both in time and money.

Code First Girls

Then along came Code First Girls. An organisation that runs courses to get women and non-binary people into tech as well as help IT professionals to gain new skills and improve their chances of promotion.

They run a range of courses, from four-week MOOCs (Massive Open Online Courses) and kick-starter night classes to degree-level courses. All are free due to businesses sponsoring the courses. This enables people who might not be able to afford this specialist training to upskill and move forward in their careers and helps ‘level the playing field’ in the IT industry.

Code First Girls are also ambassadors for helping employers to hire more women and non-binary people. Code First Girls have helped “150,000 women learn to code and delivered over £75 million worth of free technology education — teaching three times as many women to code as the entire UK university undergraduate system!”

Code First Girls work with companies around the world to help their graduates find jobs. They have ambitious goals for the future, including providing one million opportunities for women in tech in the next five years and becoming the world’s first EdTech unicorn dedicated to women in tech.

On course for a kickstart

Due to work commitments, time with the kids (taxiing them to and from sports mainly!) and my voluntary work with the local basketball club, I don’t have a lot of spare time to be learning a new skill outside work hours.

However, the Kickstarter courses run by Code First Girls seemed to fit the bill. Two hours of tuition a week for eight weeks. It felt manageable, and it was. There was a bit of homework set each week and a project at the end of the course, and it took roughly four hours of my time on average per week.

To be eligible for these courses, you need to identify as a woman or non-binary and you need to be over 18 years of age, and that’s all. No experience needed.

The courses are run online, so starting at 6.30pm was doable even on days when I was in the office. The tutors were friendly and approachable and the course was set at a pace that I was able to keep up with. The course was delivered via a web video system, so we could follow along with examples and chat to other people in the class as well as the tutors. We had a course Slack channel for any queries or issues that we had and the tutors were prompt to reply. This meant that we didn’t feel alone, even though the course was 100% remote.

Did this dog learn new tricks?

As I worked as a business analyst at the time, the Data and SQL course appealed to me most and it felt like it would be useful in my day-to-day job.

On the course, we learned about how databases are set up, how to code in SQL, carry out data analysis, how to manipulate data and how to visualise that data using Tableau and Power BI.

The course did not include an exam. Instead, we had to create a project which brought everything we learned together. We had a couple of weeks to put this together and then we all presented our projects via slideshows and some brave souls even did live demonstrations.

My project involved creating a small database from scratch, adding data, producing an entity relationship diagram and showing that I could query the database using various commands via subqueries, creating views, stored functions and procedures. We were able to base the database on anything that interested us. Mine was (loosely) based on basketball.

Our work and presentations were reviewed by some representatives from Discover, who sponsored the course. They provided us with feedback, which was really useful.

The class and the tutors were all very inclusive and it felt easy to ask questions and discuss issues without feeling like you were wasting everyone’s time. People came from all walks of life; some were starting out their careers, some were movers from other industries and some were just keen to learn something new. It was really refreshing and great to know that I can still learn new skills!

I’m now working as a Product Analyst within our newly formed Product Operations team here at FreeAgent. Since completing the SQL course, I’ve used my new skills helping colleagues with queries in Looker (our platform for data visualisation), as well as accessing and manipulating data to extract valuable insights that our Product Managers can use to inform their decision making.

I’d definitely recommend that you take a look if you fit the criteria and are interested in learning some new skills in a way that will fit around other commitments.

Find out more at Code First Girls.

Kirsten Zammit is a Senior Product Analyst at FreeAgent — the UK online accounting software for small business owners and their accountants and bookkeepers.

In the last year, we decided to create a combobox component for our product to aid customers with their larger datasets like names, invoices and bills. This component took several months to fully create because at FreeAgent we err on the side of caution when creating and implementing complex components. We always try to ensure an equitable experience for all of our customers, regardless of their accessibility needs, so we toiled over this component for a while before we were entirely happy with it.

Over the years, before there was a design system team, FreeAgent created and implemented multiple combobox form fields to help customers through their journeys. The problem we found was that the combobox was never componentised, which meant teams were designing and building their own versions of a very similar thing. This inevitably caused inconsistencies in the FreeAgent product.

To understand the problem, we conducted an audit of all the areas where comboboxes had been implemented.

Research and discovery

We found there were 19 different instances of comboboxes to review and replace.

Some had separators:

While others didn’t:

Some had a grey fill, while others didn’t:

Our design system and front-end architecture teams looked to consolidate all the combobox form fields in an effort to achieve two goals:

• provide one reusable combobox component that would provide a consistent experience for our customers, and
• update and condense the JavaScript used, to make the codebase easier to maintain.

The teams researched other examples of combobox fields to find the best solution for FreeAgent, ensuring it would be as accessible as possible.

Form guru and interaction designer Adam Silver created a step-by-step guide suggesting how to build a best practice combobox component using an HTML <select> tag.

Whilst this felt like the most appropriate version of a combobox component, it didn’t fully meet our required purposes. Adam’s version relied on a <select> tag, which would only allow customers to select from a set list of items. For certain scenarios, we need to allow customers to add in their own inputs or select from a list of items. Large data sets would also cause performance issues when using a <select>.

After conducting the audit and research, it was clear we would need two versions of the combobox component. One version would only allow customers to make a selection from a predefined list, while the other would provide suggestions.

Design and speccing

When it came to designing the combobox form field, we wanted the default state of the field to look identical to our other input, select and text area fields so that we would have a consistent-looking set of form elements. We also wanted our customers to understand the field functioned in a similar fashion to the generic form field — either the customer could enter what they knew they were looking for or they would have to choose a single option from a list of items. This meant the styling of the different states of the field also aligned to their generic counterparts.

The more challenging part was creating the nested dropdown that would show when the customer interacted with the input. As highlighted in the audit, the different previous versions of the dropdowns had inconsistent styling and content.

By locking down the base styling of the dropdown but allowing customers to display data in different formats, we allow the component to be generic and reusable while providing a designer the flexibility to add a variety of data types. We can also maintain a level of consistency and familiarity for the customer.

Alongside visual consistency, we also placed a large focus on accessibility and providing consistency with the current controls of native form fields.

We added keyboard controls to the combobox that acted in a similar fashion to a native HTML <select> element. This allows customers to navigate options with their arrow keys; select options with spacebar, return or enter keys; hit escape to close the dropdown list; and hit the tab key to exit the component.

After a few feedback reviews with product designers and the design system team, we created a design spec. The design spec is the handoff we provide to our engineers before they build the coded component and contains the component anatomy, behaviours, interactions and general best practices. We start the speccing process by using the EightShapes Spec plugin for Figma and making relevant adjustments to add interaction and accessibility notes to the spec.

Building the component in Figma

After the design was finalised, we made it into a Figma component. To help with the admin around component designing and updating, we used our component contribution checklist.

This checklist serves as general acceptance criteria for any new components or updates to existing components, to ensure the appropriate items have been completed before moving forward with a review. The guideline allows us to clearly communicate what is required and discuss any changes that may be needed.

When creating a specific component in Figma we aim to provide the same options between the coded and Figma versions. This helps provide consistency with the coded component library and the UI Kit and restricts the options of the Figma component so it provides the same options as its coded counterpart. We make them as similar as possible because we want to ensure there is no miscommunication between design and engineering.

In code, an API is used to provide the options that can be selected for a component. In Figma, we use properties and variants to produce the desired result. When using the Figma combobox component it will initially display eight properties and variants that will change the look and feel of the Figma component: Type, State, Label, Label Text, Required, Populated, Show Helper Text and Show List.

• Type changes the input field to various form types: Select, Input or Text area.
• State applies the state that the field should be displayed in: Default, Hover, Disabled, Focus, Error.
• Label determines whether there is a label and its position: Top, Left, None.
• Label Text lets the customer change the label text.
• Required is a Boolean that displays an asterisk to indicate the field is mandatory.
• Populated enters text into the field.
• Show Helper Text adds additional text beneath the field.
• Show List displays the list of options that will be displayed when the customer types in the field.

By modifying these properties, a designer can create any visual variant or state of the combobox for their designs or testing purposes. It also allows the engineer to recreate the design in code with minimal effort.

It’s worth noting that Figma is a prototyping tool, so we ended up providing options to aid designers like “Populated” and “Show List”. While these options are not in the API because they are either user-driven or automatically triggered by the component, they provide a more fluid experience for the product designers.

Usage guidelines

The main purpose of these guidelines is to help align both design and engineering’s understanding of why, when and how you would use a particular component. Providing this guidance ensures that the usage of a component remains consistent throughout the product, which is the goal we are trying to achieve within the FreeAgent design system team.

When the combobox was completed we provided a set of usage guidelines for our designers and engineers. These guidelines were split up into a number of categories to make it easier to digest.

• Purpose: What does the component do and what problem does it address?
• Dos and Don’ts: What limitations are placed on how you should use the component?
• Variants: Are there versions of the component that can be used in different situations?
• Accessibility: How does this component work for customers with accessibility needs?

Once these guidelines were created, they were reviewed by the entire design system team to ensure they are accurate and appropriate. When the entire team was happy with the guideline documentation it was marked as completed and added to our reference website. The guide was released alongside the combobox.

Testing

After the component was built we also wanted to test it thoroughly. The combobox was implemented into a solitary demo environment where we could view the component in isolation with placeholder data. This gave designers and engineers the ability to interact and test the components against all of the acceptance criteria provided in the documentation.

The coded component and the Figma UI kit component were also compared to one another. This is to ensure any options and variants available in the coded component are present in the Figma.

For the accessibility portion of testing, luckily the design system team had just attended the GOV.UK’s workshop on component testing which provided a checklist to test against. This was very helpful because, while the design system team cares a lot about accessibility, we are not experts in this field. This document gave us a guideline to follow. The document contained a large criteria of browsers and accessibility tools, allowing us to ensure any component meets an acceptable standard.

Multiple designers and engineers tested the component, giving us the confidence to release this to the wider company.

Release

Once we had our Figma component, coded component, and documentation, we released it. We have since let our designers and engineers know that the combobox component is available, by announcing this news in some of our Slack channels, in our Figma release notes, and in different team ceremonies. We’ve also provided training to product designers on how to configure the component.

The combobox component has been implemented in several areas of the product and we are continuing to roll it out across the desktop version of FreeAgent. Replacing the old versions with our new and improved component will create the consistency, reusability and accessibility we are looking for from our design system at FreeAgent.

Suneil Rakhra is a Product Designer in the Design System team at FreeAgent — the UK online accounting software for small business owners and their accountants and bookkeepers.

The larger and more complex businesses and accountancy practices become, the more functionality they require within accounting software, and the more flexible and robust that functionality needs to be. That’s why we’ve taken something that’s great for some and good for others, and turned it into something great for everyone; our support for capital assets and depreciation.

Gearing up for change

Capital assets for businesses come in all shapes and sizes - from cars and furniture to land or a business patent. Depreciation is the mechanism that’s used to spread the value of a capital asset over the years that it’ll be useful to the business. It reduces the value of the asset on the business’s balance sheet, because if you sold the asset later on, you wouldn’t be able to sell it for as much as you bought it for.

We’ve always been an excellent solution for micro-businesses and freelancers and the accountancy practices that work with them. Speak to these folks and they’ll tell you the reasons why we’re voted the UK’s #1 bookkeeping software for small businesses. FreeAgent is far more than only a micro-business solution however; we’re also great within the small business market, for larger accountancy practices, and those looking to grow. The latest updates to capital asset and depreciation are a testament to that.

Shifting assets up another gear

Before March 2024, FreeAgent’s support of depreciation worked well for simple businesses but the functionality had limitations that created friction for the larger businesses and their accountants that wanted to handle things in their own way.

More specifically, the support meant:

• one depreciation method for assets: straight line depreciation
• assets could only be depreciated on a once-per-year basis
• each asset had to have a useful life between two years and seven years

For each asset that didn’t meet the requirements of the three bullet points above, manual journal entries were required to adjust the asset’s value through depreciation. his was time consuming and confusing across multiple assets, and for practices across multiple clients.

The new live functionality enables the following value:

For individual assets:

• The reducing balance method of depreciation
• Assets that don’t depreciate at all (such as land and investments)
• Assets depreciating every month
• Asset lifetimes of up to 25 years when depreciating using the straight line method
• A running balance showing the value of the asset at any point

Across all assets:

• A notably more detailed capital asset report that captures all the new functionality as well as elements like purchase price
• The ability to export the capital asset report in csv and pdf
• A new capital asset type for land and property included in all new FreeAgent accounts
• Default depreciation methods to be set per capital asset
• Default tax treatments to be set per capital asset type

These elements provide the increased flexibility to make FreeAgent work better for each small business and accountancy practice, whilst also saving countless hours in finance admin.

The supercharging of our capital asset and depreciation support is the latest example of our ambition to achieve greatness and not settle for good. It’s just one of the many exciting enhancements that we’re launching in the pursuit of making businesses happy and more successful by putting them in control of their finances, whether you’re a solo contractor or a small business with aspirations of rapid growth.

“Good is the enemy of great.” At FreeAgent we aim for great and our Net Promoter Score (NPS) of 78 across more than 150,000 small business customers would indicate that we rarely fall short.

Stu McEwan is a Senior Product Manager at FreeAgent — the UK online accounting software for small business owners and their accountants and bookkeepers.

FreeAgent introduced machine learning-driven transaction categorisation in 2019, and we’ve developed it into a situation today where we categorise over 60% of all imported transactions whilst maintaining an accounting-grade accuracy of over 93%. Here’s how we’ve achieved this.

The red wall for new customers

One of the core jobs-to-be-done for all FreeAgent customers is to file accurate taxes on time. To do this, users need to first assign bank transactions to an accounting category, a process often referred to as reconciliation. Doing this correctly is important as it allows business owners and their accountants to establish precisely how much money the business has, and to accurately report the figures to HMRC. There are about 70 categories to choose from in our standard chart of accounts, so this task may appear daunting to new users.

We set ourselves a vision of ‘ensuring every business can build accurate accounts from day one’ and within this a mission of ‘leading on automation’ by automating transaction categorisation, thereby providing a continuous source of accurate data that lifts the daily admin burden from our users.

Customers typically import transactions automatically into their FreeAgent accounts using a bank feed, after which they must be categorised. Our rules-based system ‘Guess’ learns from behaviour over time to automatically categorise transactions. There is, however, a gap in our automation coverage for new customers with no data in their accounts. When these customers first start using FreeAgent and sync transactions with their bank, they will be confronted with a lot of transactions to categorise; a situation we refer to internally as ‘the red wall’.

There was a huge opportunity for us to utilise machine learning to address this coverage gap, helping new customers stay on top of a time-consuming admin task right from the start. In order to do this we needed a system that could categorise transactions without requiring additional data at the point of transaction import, which is what we set about designing and building.

Red wall wrecking ball: version 1

Initial experimentation

Product Engineering and Data Science came together with the goal of building a machine-learning model that could categorise bank transactions for new customers. Over the years we have accumulated an amazing dataset of hundreds of millions of user-categorised transactions, covering a long time period and for a diverse set of business industries. We can approach this then as a supervised-learning problem, where we use information from historical bank transactions to learn the categorisation patterns typically used across our customer base.

Research into this approach started in early 2019, focusing mainly on experimenting with different types of model and the combination of bank transaction attributes to use as model inputs. Experiments showed a group of four accounting categories our models were performing better across, we think due to the clear relationship between the bank transaction descriptions and the category names. These were ‘Travel’, ‘Bank Fees’, ‘Insurance’ and ‘Accommodation and Meals’. We settled on using a Support Vector Machine to model the relationship between bank transaction description and accounting category, accepting predictions into the four categories mentioned above.

Building the system and beta launching to customers

After the concept of a machine-learning driven categorisation approach had been proven in our experiments, the build of a production system began. The components of this system are as follows:

1. Client code in the FreeAgent application for extracting the required bank transaction attributes and sending these for categorisation
2. An AWS SageMaker endpoint to host our model, which receives bank transaction inputs from FreeAgent and responds with confidence scores for each of the modelled accounting categories. We call this cloud machine-learning categorisation service ‘Banquo’
3. More FreeAgent client code to process the model responses and determine which bank transactions should be categorised
4. Front-end code to display automatically categorised transactions to users in an orange ‘marked for review’ state, so they can be easily reviewed and approved
5. Performance tracking based on events published from the application, allowing us to interrogate how users interact with Banquo-provided categorisations

All of the above must run synchronously when transactions are imported so that results are returned to customers in real time. The components were built towards the end of 2019, culminating in a beta launch to a small number of customers at the start of 2020. For the first time we were collecting both qualitative and quantitative customer feedback on our system, including the model performance and frontend design aspects.

The scale at this point was small (at most dozens of Banquo categorisations per day), but patterns in model and customer behaviour were becoming apparent, giving us ideas for how we could improve what we had built.

Liftoff

This system launched to all customers in June 2020, with a strict confidence threshold for accepting model predictions. Importantly, Banquo runs as a final step in the Guess process, meaning that if we can categorise the transaction with rules and existing data in the specific customer’s account, we favour doing this.

As a consequence of launching Banquo, new customers will experience banking automation from the very start of their FreeAgent journey. This automation will improve in scope and accuracy as data accumulates, with Banquo gradually handing over to the more customer-specific matching approach baked into Guess.

We started small though! The above category and confidence constraints meant that we were initially only categorising a small fraction (around 2%) of imported transactions with the Banquo service. The methodology was in place though, and we had plenty of ideas for how to improve the impact we could have. We were starting to chip away at the red wall.

Red wall wrecking ball: version 2

Post-launch period

Continuous experimentation and updates characterised this post-launch period, with the goal of increasing automation ‘coverage’, which is the fraction of imported transactions automatically categorised. Specifically, we concentrated on adding more accounting categories to our model and improving the way we extract model inputs from bank transactions. This gave us some success and coming to the end of 2021 we were automatically categorising around 5% of all imported transactions and about 10% of those imported by new customers with Banquo.

Ultimately though we were hitting a bit of a dead end and our experiments were not giving us the performance gains we were hoping and expecting to see. This was mainly down to us being restricted by the original choice of model architecture, particularly issues with scaling up to the ambitious goals we’d set ourselves for automation coverage. It was clear that to get to the next level we had to rethink our model architecture, which is where we focused our efforts next.

Transformers, robots in disguise!

The transformer model caught our eyes at the time by achieving state-of-the-art performance across a range of natural language processing problems. As described in our engineering blog post, this approach enabled us to model all the categories in our standard chart of accounts. Initial prototyping with this architecture was really positive, showing us that we could maintain the accuracy of our system whilst making big gains in coverage.

Once we were sold on the approach, we again turned to the production build. We had learned some lessons over the course of running the previous system, and were able to be more thoughtful about the design second time round. Our main goal was to have as little of our own custom code to maintain as possible, which we achieved by using Docker containers provided by Hugging Face for model training and inference. We ended up with a simple, stable solution we felt confident making changes to. We launched this model architecture update in February 2022 and immediately started seeing the impact on automation coverage.

Approaching the Coverage Ceiling

In some cases the confidence of our model predictions is too low to categorise a transaction. There are also cases unrelated to model performance where automatic categorisation isn’t an option, leading to the concept of the automation ‘coverage ceiling’. One such case is when additional information must be provided to FreeAgent that isn’t available to Banquo or Guess, for example a sales tax rate for VAT-registered companies or a user to include against a salary payment. Taking these transactions into account, we estimated our coverage ceiling to be around 80%.

The transformer model architecture laid the foundation for some significant changes that accelerated our progress towards this ceiling and improved the user experience of categorising transactions. Firstly, we changed from thresholding against the confidence score of the single highest category to the combined confidence of the top three categories. This was an acknowledgement that the model confidence scores reflect a distribution of categorisation behaviours across our customer base.

As well as categorising the transaction using the highest scoring model output, we now show ‘Suggested Categories’ to customers, composed of the three highest-scoring categories. This allows customers to quickly change to a probable alternative if required and demonstrates the model’s knowledge of the alternatives. Figure 1 gives an example of how this looks to customers.

Throughout 2022 and 2023 we worked on continually improving the performance of the transformer model and the FreeAgent client code processing the model outputs. We mostly did this by running production A/B tests, including experiments on merging accounting categories, decreasing the confidence threshold, pattern matching in the bank transaction narratives and starting to make sales predictions for VAT-registered companies. In parallel to these transformer developments we made improvements to some of the Guess rules utilising existing data. One example was improving the pattern matching in our ‘Similarly Categorised Transaction’ rule, which led to an absolute increase of 4% automation coverage.

Finally, as well as these model improvements we expanded on the breadth of value for our customers by implementing some additional features including:

• Automating the opening bank balance whenever a bank feed is connected
• Automatically matching uploaded receipts from the Files area to the correct bank transaction purchase
• Revamping the Banking dashboard to better highlight the core categorisation actions customers need to take
• Grouping the automated bank transactions that are ready for approval by category in order to streamline the review and approval process

Summary

Over the past four years we’ve committed to our vision of ‘ensuring every business can build accurate accounts from day one’ by focusing like a laser beam on automating bank transaction categorisation. We’ve introduced our first ML-powered service, Banquo, into the application, reduced the time-to-wow for new customers by enabling automation from day one, and made significant progress towards our coverage ceiling goal. Figure 3 (above) shows how we’ve doubled the percentage of imported transactions automatically categorised as a result of these changes, helping our customers nail the daily admin with each step along the way.

Owen Turner is a Staff Data Scientist and Stu McEwan is a Senior Product Manager at FreeAgent — the UK online accounting software for small business owners and their accountants and bookkeepers.

FreeAgent’s Product Design and Engineering teams found themselves exploring questions like these often and we quickly realised that a design system could be a game-changer in tackling the growing complexity of our product.

We wanted to create a set of design guidelines and components that would help us create a consistent and delightful experience for our users. The FreeAgent application was 15 years old and growing quickly. We found ourselves facing a common product challenge: how to maintain design consistency as we scaled. We needed a solution that would help us design and develop faster, whilst also ensuring that we were delivering a great experience for our users.

I’ve had an obsession with design systems for years, so I was very happy about starting a new role in a dedicated design system team. The feeling of making a big difference across the business and the anticipation of what could be achieved felt exciting.

But why did I see this as such a big deal? In short, it’s because a design system is a collection of team knowledge in a shared set of tools and guidelines that help designers and engineers create beautiful, consistent, and usable UI for end users of a product.

To summarise, a multi-skilled team with different strengths and knowledge could impact several areas of the business:

• Our company. Our team could create a consistent user experience that would align with business objectives and help increase revenue and reduce churn (i.e. people leaving the product).
• Our colleagues. We could create the tools and guidelines that would help our teammates deliver their work more effectively and efficiently.
• Our customers. Through all our effort and hard work, we’d create an experience our customers could trust and love.

In the beginning, there was a peak of excitement about the idea of a shiny brand-new website and improving our components, but the nature of our work proved to be more than that.

Topics such as strategy, metrics, prioritisation, governance, contributions, processes, design tokens, and communications weren’t the first things that came to mind when I originally started as a DS designer. However, they are all important to the success of a design system.

One of the very first design system tasks we worked on was our tooling and the migration of our component library from Sketch to Figma. This included identifying the best overall structure in Figma, creating and testing robust components, and training our designers so they knew how to use our library. This is known today as our FreeStyle UI kit.

After our UI kit was established, we started to think about where our usage guidelines, coded components and technical guidelines could live. As a result, the Design System team designed and developed the first version of our FreeStyle reference website. We spent some time designing the information architecture, component page hierarchy and how the UI would look. This now houses our existing styles and some of our components and guidelines, and we’ve been working hard to scale and improve this in future, which is exciting.

As we transitioned from some of the infrastructure work, our focus shifted towards foundational design system tasks, primarily centred around the creation and enhancement of our design language and some important components.

Our design language (also known as design tokens) and components serve as the backbone of any design system, and we dedicated effort to enhancing visual appeal, usability, and accessibility. The iterative process involved continuous refinement, specifications, clear guidelines and collaborating closely with design system engineers to ensure practicality and integration into our codebase.

Working as a service layer for teams, we’ve also been thoughtful about the needs of those who use the system. Over the past few years, we’ve conducted internal research to better understand the needs of our users. Methods such as user interviews, usability testing and surveys have helped inform our strategies and tactics within the team. We’ve also looked at best practices from other companies, which have supported and strengthened some of our own guidelines and ways of working.

These are just a few things the team has been working on. Behind our design system is a team of passionate and dedicated designers and engineers who are making a big impact. Our colleagues can now work faster and more efficiently thanks to the reusable components we created and the guidelines we documented to support them.

Design systems are never ‘done’ and we continue to iterate and improve, incorporating feedback from our users and stakeholders. Over time, we will continue to expand our library of components and patterns and develop our resources and guidelines to support designers and engineers at FreeAgent. Our design system is now an essential part of the infrastructure that will evolve alongside our products and teams.

I’m extremely proud of what we’ve achieved as a team so far, and all the hard work and passion that has gone into the design system. It’s been fun and all of us in the team are looking forward to delivering on our future goals and vision together.

Colin Summers is a Design Manager in the Design System team at FreeAgent, the UK online accounting software for small business owners and their accountants and bookkeepers.

A big focus for us in 2023 was improving engagement with in-app notifications by making sure we’re effectively delivering information that users truly care about. We explored a variety of potential changes we hoped would have a positive impact, one of which I’ll chat you through in this post!

Pro Tip notifications

‘Pro Tips’ are a type of notification we generate for customers. Their purpose is to nudge users towards deeper adoption of the FreeAgent features we believe they’ll find valuable. Typically, we’ll generate these when customers have just engaged with a similar feature. For example, if a user has created an invoice, we may generate a Pro Tip suggesting they upload their business logo so that we can automatically personalise all documents they create.

We might also generate a Pro Tip if a customer has shown explicit interest in achieving a particular Job-to-be-done (JTBD) during setup. If they tell us they want to file taxes in FreeAgent, we’ll generate Pro Tips to guide them through that process. So Pro Tips are all about helping our customers get the full value out of FreeAgent, based on their individual needs and behaviours.

Because Pro Tips are highly relevant to what the customer is currently doing, or wants to do, we want the customer to become aware of them ASAP. We believe this will be the point at which they’re most likely to engage, as the content is most useful to them then and there.

We thought the existing behaviour could be a little too subtle. Upon generating a notification, the Radar bell ‘rings’ and a yellow dot appears to indicate an unseen notification. So we wondered if there was a way to make Pro Tips more noticeable as soon as they were generated.

This led us towards an idea we called ‘PUPTs’ (Pop-up Pro Tips)!

The idea: Pop-up Pro Tips

Our idea with PUPTs was that, upon generation, the notification would ‘pop-up’ under the Radar bell, showing its full content. The thinking was that this would put the notification content right in the user’s eyeline at the optimum time, maximising the chance they would engage. To mitigate the potential intrusiveness of the pop-up behaviour (which we knew was a risk), we also wanted them to be dismissible and disappear automatically after 10 seconds.

One factor in the decision to pursue PUPTs was that we’d previously tested the format with users via a prototype and received positive feedback. Another was the strong engagement we see when we show the user’s most recent notification on their Overview page (the page they see first after logging in).

PUPTs felt like a natural way to build upon this kind of mechanism. And lastly, the pop-up format is a relatively common UX pattern when onboarding a new customer, implying it’s been successful in some apps.

Setting up the experiment

Due to the number of notifications we send out, this was the perfect candidate for an A/B test. And thankfully so, because engagement with our notifications naturally varies significantly from month to month! This means a ‘before-and-after’ comparison wouldn’t give us a clear indication of whether PUPTs had any impact.

The metric we wanted to change was the percentage of companies clicking the Pro Tip notification CTAs.

Working with the Analytics team to design the experiment, we separated all companies on FreeAgent between ‘control’ and ‘test’ cohorts:

• The control cohort would see Pro Tip notifications generated in the existing way: the Radar bell would ring to indicate a new notification and they would click the bell to see the Pro Tip
• The test cohort would see Pro Tip notifications generated in the PUPT format

Once we reached the required sample size, we also knew we’d have to apply a time lag before assessing the final result, due to the delay we see in user engagement with Pro Tips generated in the existing way. While the Radar bell may ring to indicate a new notification, we know it can take companies some time to actually interact with it. We didn’t want this known behaviour to wrongly impact the result.

The result

Unfortunately, not all experiments succeed, and this was one of those times! We found that generating Pro Tips using the PUPT format was less likely to lead to CTA clicks than the existing approach, at a confidence level of 95%. Looking more closely at the individual Pro Tips involved, we saw that they each either performed the same as a PUPT, or worse. But they never performed notably better as PUPTs.

Why could this be? Even with some positive indications pre-build that PUPTs may catch people’s attention more than the ringing Radar bell, we knew there was also a chance that this wouldn’t necessarily follow through to greater engagement. And we knew there was a risk that users might dismiss them off the bat due to the more ‘intrusive’ format.

With the data not stacking up, we made the decision to disable PUPTs on production and remove them from the codebase. Without an indication that the format was benefitting our customers by delivering Pro Tips in a more timely and actionable way, there was no reason to keep them in place.

A reminder to test

While, of course, every team wants to constantly release changes that make a big impact, this example underlines how important it is to test what you build. Doing so prevents you from committing to maintain something that doesn’t actually contribute, increasing both technical and product complexity with no reward. It’s best to make the decision and move on to the next thing, applying the learnings to future ideas and experiments.

In this case, we could’ve assumed a positive result was likely based on the user feedback on the prototype and the engagement with the most recent notification mechanism on the Overview page. It’s a reminder that what you find out in user testing won’t necessarily follow through to the ‘real world’, especially in an example like this. Definitely try it out, but remain sceptical and test, rather than assume!

Paige Barclay is a Senior Product Manager in the Radar team at FreeAgent, the UK online accounting software for small business owners and their accountants and bookkeepers.