At FreeAgent we’re building a new platform to allow our teams to explore their data and glean new insights from it. The platform is built using Looker on top of Amazon Redshift, and so far it’s been enthusiastically received by the teams that use it. However, the process of building up the platform and driving adoption hasn’t been entirely straightforward. There has been a recurring issue that we’ve have had to deal with: when the report in our legacy system has different values to the new Looker report.
In this situation, the user’s initial reaction is to want everything to match, and they often assume the old numbers are “right” and the new numbers are “wrong”. I believe that this is similar to the known phenomenon, where research shows information presented with an accompanying chart or scientific formula is more likely to be trusted. So in this instance, the old report is trusted because it was already in place.
The reasons for differences
In most cases, the differences I encountered in the data were due to a bug in the legacy system or a new bug introduced when building the LookML model. However, sometimes the differences weren’t due to a bug. So what was going on?
To solve the problem and explain the differences I needed to understand what I was counting. In many cases, the assumptions and decisions made in calculating the values presented in the old reports weren’t fully understood or explained. For instance, in a report that counts the number of customers using a product feature, it could be assumed that it simply counts customer IDs. However, considering how answers to the following questions may impact on the values presented in the report:
Do we include customers that have cancelled but still have access to their data?
How about prospective customers on free trials?
If a customer uses the feature twice, do we want to count that as one customer usage, or two? (i.e. the difference between a count and a count distinct).
You can see there’s work required to define exactly what we should be counting. It’s important to do that work and bring transparency to the data. It’ll enable you to understand and discuss the variations between reports with the people that actually use them. It was during discussions I had on this topic that it became apparent there were two recurring themes in our data discrepancies:
Users didn’t understand what we were counting, which meant they had been consuming data without truly appreciating how the values have been calculated, or what they represented.
Users didn’t have access to the numbers that actually mattered to them because the values most useful to them had evolved over time, but the reporting hadn’t evolved with their requirements.
By determining which numbers are the most valuable to the users – and helping them understand what each value means – I was able to define and implement a reporting layer in Looker that applies measures consistently across the entire platform, so that all users can work off the same foundation of consistent data.
Conclusion
Our team will love the ability to explore data and build new reports in Looker – provided they can trust the numbers. To gain their trust, it was important to help them truly comprehend the values presented to them. Of course, it’s not always that easy and can take time to do it well. It can be hard to work out why there are discrepancies when matching numbers between reports, but it is crucial that you do. It’s also beneficial to build an understanding early on in the process to establish confidence in the data platform, encourage usage, and prevent confusion amongst your users.
On 16th May it’s Global Accessibility Awareness Day, a day to “get everyone talking, thinking and learning about digital access/inclusion and people with different disabilities”.
At FreeAgent, our mission is to make small businesses happier and more successful by putting them in control of their finances. A big part of that mission is building software that is accessible and inclusive, so that we can help as many people as possible, regardless of their situation.
But our app is now over 12 years old, and we haven’t always been that focused on accessibility. It’s taken a relatively recent push for us to reach a place where we feel accessibility is front and centre of our design process.
How we started our accessibility group
Paddy, one of our product designers, attended the 2017 Accessibility Scotland conference and came back with a few ideas to improve the accessibility of our product as well as awareness throughout the company.
There were a few accessible components in the app already, but they were scattered and untested. What we didn’t have was a clear strategy for approaching accessibility. The first step to rectifying that was to start talking more and raising awareness about accessibility and inclusive design.
We set up a fortnightly Accessibility Forum to discuss the current state of the application, solicit feedback on new components, share interesting stories and articles, and mostly give us a place to ask a lot of questions.
A range of discussion topics on our Trello board
Getting together regularly was a huge boost in confidence: we realised we were mostly doing the right things so far, if a little haphazardly. Very quickly we realised that we probably didn’t need a very formal plan to start making decent improvements.
As part of our Making Tax Digital work with HMRC, we also performed our own impromptu accessibility audit for our MTD journey. We used the axe tool to identify places that didn’t meet the Web Content & Accessibility Guidelines (WCAG) 2.0 standard, and recorded all the issues in a big spreadsheet. By the end, we had a pretty good overview of how well FreeAgent measured up.
It was an eye opening experience and it got us talking more about accessibility, to the point where we have Key Performance Indicators around increasing the accessibility of our application and we’ve also started using accessibility exit criteria for our user stories!
Practically applying our new accessibility knowledge
Since we’ve started the forum and built up more confidence around this area, we’ve also started applying our new accessibility knowledge to improve our application.
We address a bunch of accessibility concerns in FreeAgent, based around the four aspects covered by the WCAG: visual, auditory, cognitive, and motor.
Visual
We make sure our app has enough contrast and accessible colours. We always ensure that the colours pass the WCAG minimum colour contrast ratio. Our designers use the Stark Sketch plugin to test the contrast ratio of text to its background colour. We also use labels or distinctive icons in combination with colour to convey meaning.
Using colour and labels to convey meaning
Auditory
We make sure all of our knowledge base instructional videos are closed captioned. We use a couple of services for this – Rev and Wistia. On top of that, our award winning support team is reachable by email or chat, which benefits not only our users with hearing problems, but all kinds of customers that are not comfortable with using a phone.
Cognitive
We put a lot of effort to make sure the terms we use throughout the application and our knowledge base are easy to understand and avoid accounting jargon as much as possible. We keep the content easily scannable and use short, easy to follow sentences. We also ensure consistency in colours, fonts, and locations of the elements in the page.
Motor
We try to make sure our app is fully navigable with a keyboard, as well as a mouse or touch screen. We don’t mess with tab order or move things around with JS or CSS, and we use native, semantic HTML elements instead of custom components as much as possible (this also helps with the visual and cognitive aspects).
What we’re doing for Global Accessibility Awareness Day
This accessibility awareness day, we will try a couple of things to help raise awareness throughout the company. We’ll be running a “no mouse challenge” where people will try and use their computer without a mouse for a day (or however long they last). We will also be delivering screen reader demos of our app.
Introducing a component level and end to end automated accessibility testing tool such as tenon.io
Raising awareness internally
We know it’s not right yet, but once we’re confident about the accessibility level of our application, bringing in a 3rd party company to do an audit
Promoting accessibility in your own workplace
You may be in a similar position to the one we were in a little over a year ago: you’re excited to improve your product’s accessibility, and there’s no outright objections from the rest of the business, but there’s no plan in place yet either. It can seem like an intimidating task to take on, but it’s probably not as daunting as it first appears.
Here are a few tips, based on our experience, for promoting accessibility in your own workplace:
Talk about it – set yourself a goal to learn a little bit about a given topic, and then share it with your team or a wider audience (we do this by presenting a short segment in our regular forum, or through town hall talks to the whole business)
Start a forum of interested folks – accessibility is a topic a lot of people are aware of, but they may not have the confidence to take on by themselves. Search out co-workers who feel similarly to you and start meeting regularly to discuss your concerns.
Ask around the company for people who have experienced accessibility issues (there’s probably more than you think) and ask them if they would like to talk about their experiences – this doesn’t need to be in a public forum. Just chatting one-to-one can help you learn about their difficulties, and you can always share this with others later, anonymously if need be.
Solicit accessibility feedback from your customers – if they’re anything like our customers, they’re probably telling you anyway, but you’d be surprised how many people are battling through inaccessible software because there’s no good accessible alternative.
Try using accessibility exit criteria for user stories – these can start really simple, and focus on just one or two areas to begin with, such as “search suggestions can be read and selected while using a screen reader”.
If you’re in a position to influence the company’s hiring strategy, look for candidates with accessibility experience – if you manage to hire them, try and get them to bring their expertise into your working group. They may also have past experience of promoting accessibility in other companies.
Find a way to measure your progress and momentum – this is so that you can see the positive changes you are making even when the whole thing isn’t “fixed” yet. For example, we used the output from our first internal audit as a baseline. We then went back to it as we fixed known issues to track how much we were improving.
It might not be a very smooth ride at all times, but try to keep up your momentum, even if it’s just in small ways. Soon enough you and your users will start to see the benefits. As you get more confident about making small changes and measuring their impact, the benefits will start to become visible to the rest of your team. And remember, when you make your software accessible, everybody wins!
Anda Popovici is a software engineer on FreeAgent’s product team and Paddy Duke is a product designer for FreeAgent
